企业官网建设流程全解析

接手过不少刚学完 Java 基础的朋友，他们拿着网上下载的"客户管理系统"源码，第一句基本都是"老师，代码能跑起来，但我不理解为什么要这么写"。说实话，客户管理系统确实是 Java 入门到进阶之间最经典的练手题目之一——业务足够完整、表结构不复杂、涉及的技术点又差不多能把 Servlet、JSP、JDBC、MySQL 这套老牌组合全部串起来。这篇内容我打算直接站在"拿到一份源码后怎么去读、去拆、去改"的角度，把客户管理系统从设计思路到数据库、从登录到增删改查、从部署到排错，一层层剥开来讲，希望能解决"代码能跑但看不透"这个痛点。

先说明一下，下面聊的这套系统以最常见的 SSM 之前那套技术栈为主：JSP + Servlet + JDBC + MySQL + Tomcat。如果你手头的源码是 Spring Boot 版的，阅读思路依然通用，只是在技术细节上对应替换即可。我尽量把每段代码背后的"为什么"讲清楚，而不是单纯把源码复制一遍。

1. 项目整体设计与技术选型思路

1.1 客户管理系统到底在"管"什么

很多初学者拿到项目先急着看代码，其实思路反了。客户管理系统本质上是一个典型的"数据维护类"Web 应用，核心业务就两件事：管用户（谁能用这套系统）和管客户（用户登录后能对客户资料做什么操作）。绝大多数版本的源码，功能拆开无非是这几块：

• 用户登录、注销、会话管理
• 客户信息的增加、查询、修改、删除
• 带条件的分页查询（按姓名模糊搜、按联系方式搜等）
• 管理员对普通账号的管理（有的版本有，有的没有）

弄清楚这个边界特别重要，因为它决定了你看源码时的重心。比如登录模块你就该关注 Session 和过滤器，客户模块就该盯 DAO 层和 SQL 拼接，而不是在 JSP 里的前端样式上花太多时间。我见过有人抱着源码盯了三天前端代码，最后连登录流程都说不清楚，这是典型的抓不住重点。

1.2 为什么用 JSP + Servlet 而不是 Spring Boot

这个问题基本每次带新人都会遇到。现在企业里写接口确实都是 Spring Boot 一把梭，但学习阶段的客户管理系统用 JSP + Servlet，其实是有意为之的"慢"。

JSP + Servlet 这套组合能让你肉眼看到 HTTP 请求的完整生命周期：浏览器地址栏输入 URL -> Tomcat 解析 -> Servlet 的 service 方法被调用 -> 你写的 doGet 或 doPost 执行 -> 跳转到 JSP 渲染成 HTML 返回。这个过程里每一个环节都是"看得见"的，你能清晰地理解 Web 容器、请求、响应、Session 这些最底层概念。

而 Spring Boot 把这些都封装掉了，你写个 @RequestMapping 就能接请求，框架帮你做了参数绑定、视图解析、异常处理，初学阶段反而容易一头雾水。所以如果你手里的源码是基于 Servlet 的，我建议你先不要急着"升级"到 Spring Boot，老老实实把这一版吃透，后面再迁移会轻松很多。

另外从课程设计、毕业设计的角度说，JSP + Servlet 的代码量适中、逻辑直白，导师提问时你也能讲清楚每一步在干什么。用 Spring Boot 动不动自动配置一堆东西，反而容易被问住。

1.3 整体分层与代码结构

规范的客户管理系统一般会遵循页面 -> Servlet -> Service -> DAO -> 数据库的分层。我随手贴一个我帮人重构过的目录结构，你可以对照自己手里的源码找找各层对应的位置：

src/main/java ├── com.crm.entity # 实体类：User、Customer ├── com.crm.dao # 数据访问层：接口 + 实现类 ├── com.crm.service # 业务逻辑层：接口 + 实现类 ├── com.crm.web # Servlet 控制器层 ├── com.crm.util # 工具类：DBUtil、PageBean、MD5Util └── com.crm.filter # 过滤器：登录拦截、编码处理 src/main/webapp ├── jsp/ # 视图层页面 ├── css/ js/ images/ └── WEB-INF/ ├── web.xml └── lib/ # jar 包

注意看，V 是 JSP，C 是 Servlet，M 是实体类 + DAO + Service。这里我特别说一下 Service 存在的意义：很多简单版本的源码会把业务逻辑直接写进 Servlet 里，如果只是做一个课程设计倒也行，但一旦业务复杂起来，Servlet 会膨胀得没法维护。保留 Service 层是为了让 Servlet 只专注于"接收参数、调服务、决定跳转"，而把"校验、计算、业务规则"这些沉淀到 Service 里。看源码时如果发现某人直接把 JDBC 代码写在 Servlet 里，你别学，那是坏味道。

2. 数据库设计与核心表结构拆解

2.1 用户表的设计与字段选择

客户管理系统最常见的是两张表：用户表 t_user 和客户表 t_customer。千万别小看这两张表的设计，很多源码的问题就藏在字段命名和类型选择上。

先看用户表常见的建表语句：

CREATE TABLE t_user ( id INT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(64) NOT NULL, role VARCHAR(10) DEFAULT 'user', create_time DATETIME DEFAULT CURRENT_TIMESTAMP );

这里几个细节我展开说。username 必须加 UNIQUE，因为登录验证靠用户名查记录，如果不唯一，查出来多条结果程序直接报错。password 用 VARCHAR(64)，是因为如果后期做 MD5 加密，32 位十六进制字符串刚好能放下；如果你用明文密码，VARCHAR(20) 够用，但我不建议明文——下面讲登录时再细说。role 字段用于区分管理员和普通用户，默认给 'user' 而不是 NULL，可以避免空指针判断。

关于 create_time，老版本 MySQL 5.5 之前不支持 DATETIME 的 DEFAULT CURRENT_TIMESTAMP，但 MySQL 5.7 和 8.0 没问题，新写代码可以直接这样用，省得在 Java 端手动塞时间。

2.2 客户表的设计与字段细节

客户表是系统的核心数据表，设计时字段不宜太少也不能太多。一份最常见的结构：

CREATE TABLE t_customer ( id INT PRIMARY KEY AUTO_INCREMENT, cname VARCHAR(50) NOT NULL, gender VARCHAR(10), phone VARCHAR(20), email VARCHAR(50), address VARCHAR(100), level INT DEFAULT 0, remark VARCHAR(200), create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP );

说几个常见的坑。第一个是字段命名：很多人习惯直接把字段叫 name，但 name 在部分 SQL 语境和 ORM 映射里容易冲突，加前缀 cname 或 customer_name 更稳妥。第二个是 phone 用 VARCHAR(20) 而不是 BIGINT——电话号码可能包含区号、分机号、+86 这种前缀，用数值类型会存坏，而且以 0 开头的号码会被丢掉前导零。地址用 VARCHAR(100) 足够，不要一上来就 TEXT，TEXT 类型没法直接加默认值、索引效率也差，extra 需求可以放 remark 里。

update_time 加 ON UPDATE CURRENT_TIMESTAMP 是个很实用的技巧，每次记录被修改时 MySQL 会自动更新时间。如果你的 MySQL 版本不支持这个语法，就得在 Java 端更新时手动 set 一下。

2.3 表关系与外键的取舍

客户管理系统里，用户和客户是相对独立的两类数据。严格来说，可以在客户表里加一个 owner_id 字段指向用户表的 id，做成一对多——即每个客户数据记录"是谁录入的"。很多网上的教学源码会省略这个字段，只做全局共享的客户池。

我个人的建议是看源码时注意这个小细节：如果客户表里有 owner_id 或 user_id，说明系统做了数据归属隔离，那你读代码时就要留意每次查询是不是都带上了当前登录用户的条件；如果没有这个字段，说明所有登录用户看到的是同一批客户数据，逻辑更简单，但也更粗暴。课程设计阶段，两种写法都能接受，读懂自己代码里属于哪种即可。我自己做的话会更倾向带归属字段，因为面试被问"如果客户是属于不同销售的呢？"时，你可以顺势讲出一套数据权限方案，属于加分项。

3. 核心模块源码逐段解析

3.1 登录认证与用户会话

登录模块是整份源码的门面，也是理解"会话跟踪"的最佳入口。我们来看逻辑：用户在 login.jsp 输入用户名密码，表单提交到 LoginServlet，Servlet 中做的事情可以拆成三步：

第一步是收参数、简单校验：

String username = request.getParameter("username"); String password = request.getParameter("password"); if (username == null || username.trim().isEmpty() || password == null || password.trim().isEmpty()) { request.setAttribute("msg", "用户名或密码不能为空"); request.getRequestDispatcher("/login.jsp").forward(request, response); return; }

注意这里用了 forward 转发而不是 sendRedirect，因为需要把 msg 错误提示带到 JSP 页面回显。如果用重定向，request 域里的数据会丢失。

第二步是调 Service 做验证。这里请你特别关注：很多拙劣的源码会把数据库查询代码直接写在 Servlet 里，这是大忌。规范做法是：

User user = userService.login(username, md5(password)); if (user == null) { request.setAttribute("msg", "用户名或密码错误"); request.getRequestDispatcher("/login.jsp").forward(request, response); return; } request.getSession().setAttribute("loginUser", user); response.sendRedirect(request.getContextPath() + "/customer/list");

这里最关键的三个点：

• 密码为什么要处理后再比对？明文密码一旦数据库泄露，所有账号全完。教学级项目至少做到 MD5，更严谨要加盐。你可以在 util 包里找到 MD5Util 类，里面通常是一个固定的盐字符串拼在密码后面再加密。
• 登录成功后存 session，key 建议用常量字符串如 "loginUser"，后面过滤器、JSP 页面都要用这个 key 取对象。
• 跳转用重定向到 list 路径，避免用户刷新页面时表单重复提交。这是一个非常多源码踩坑的地方，如果你发现登录成功后刷新浏览器会弹"确认重新提交表单"，那说明作者用了 forward。

第三步是登录拦截。没有过滤器的登录等于不设防——用户直接在浏览器输 /customer/list 就能绕过登录访问页面。标准做法是实现一个 Filter：

@WebFilter("/*") public class LoginFilter implements Filter { public void doFilter(ServletRequest req, ServletResponse resp, FilterChain chain) { HttpServletRequest request = (HttpServletRequest) req; HttpServletResponse response = (HttpServletResponse) resp; String uri = request.getRequestURI(); if (uri.endsWith("/login.jsp") || uri.endsWith("/login") || uri.contains("/css/") || uri.contains("/js/") || uri.endsWith(".jpg") || uri.endsWith(".png")) { chain.doFilter(request, response); return; } if (request.getSession().getAttribute("loginUser") == null) { response.sendRedirect(request.getContextPath() + "/login.jsp"); return; } chain.doFilter(request, response); } }

看这段代码要抓住两个容易被忽略的坑。一个是静态资源放行：不把 css/js/图片放行的话，登录页样式会全部失效，你会觉得莫名其妙。另一个是 session 过期后的处理：Tomcat 默认 session 超时是 30 分钟，用户长时间不操作后再点击页面会跳回登录页，但如果你用了 iframe 之类嵌套，重定向到 login.jsp 可能显示在 iframe 内不占全屏，实际开发中还会用 JS 判断顶层窗口跳转。

3.2 客户列表的分页与条件查询

客户列表基本是所有版本的源码里最复杂的模块，因为要把分页、条件查询、数据展示凑到一起。我先把分页的核心思想说透。

分页需要三个输入量：当前页码 pageNum、每页条数 pageSize、总记录数 total。其中 total 需要单独执行一次 SELECT COUNT(*) FROM t_customer，再按 (pageNum-1)*pageSize 计算 LIMIT 的偏移量，执行第二次查询拿当前页的数据。

为什么必须查两次？因为页面要显示"共 120 条、第 3/12 页"，不知道总数就没法渲染分页条。有的源码会图省事一次性查出所有数据，然后在内存里截取子列表，数据量小看不出问题，客户数据上万条时响应会明显变慢，这是非常典型的"看源码时要挑出来的毛病"。

DAO 层查询代码长这样：

public List<Customer> findByPage(int pageNum, int pageSize, Map<String, String> condition) { StringBuilder sql = new StringBuilder("SELECT * FROM t_customer WHERE 1=1"); List<Object> params = new ArrayList<>(); if (condition.get("cname") != null && !condition.get("cname").trim().isEmpty()) { sql.append(" AND cname LIKE ?"); params.add("%" + condition.get("cname").trim() + "%"); } if (condition.get("phone") != null && !condition.get("phone").trim().isEmpty()) { sql.append(" AND phone LIKE ?"); params.add("%" + condition.get("phone").trim() + "%"); } sql.append(" ORDER BY id DESC LIMIT ?, ?"); params.add((pageNum - 1) * pageSize); params.add(pageSize); return jdbcTemplate.query(sql.toString(), params.toArray(), ...); }

这里有两个核心技巧你必须理解。

第一个是 WHERE 1=1 的妙用：它不是多余的，而是为了后面拼接 AND 条件时不用判断"前面是否已有条件"。如果你不用 1=1，就得维护一个 boolean flag，每加一个条件都要判断是不是第一个，代码丑且容易错。很多新手不理解为什么网上的代码都喜欢写 1=1，原因就在这儿。

第二个是 LIKE 模糊查询的拼接方式：%?% 不能直接在 SQL 里写成 '%?%'，因为 JDBC 的占位符不允许出现在引号里面，必须给参数传 "%" + keyword + "%"。如果你写的查询条件死活匹配不到数据，多半就是这里没处理好。

3.3 新增、修改与删除背后的细节

新增和修改看起来就是 insert 和 update 的简单调用，实际上有几个值得琢磨的点。

新增时要注意 ID 自动生成的问题。如果主键是 AUTO_INCREMENT，插入时不需要传 ID 字段，但有时业务需要拿到刚插入记录的 ID 回显或关联其他操作。这时候需要：

PreparedStatement ps = conn.prepareStatement(sql, Statement.RETURN_GENERATED_KEYS); ps.executeUpdate(); ResultSet rs = ps.getGeneratedKeys(); int id = 0; if (rs.next()) { id = rs.getInt(1); }

记住这个写法，很多版本源码偷懒不处理，直接再查一次。虽然结果一样，但多一次查询就多一次数据库往返，还可能在并发场景下拿到别人的 ID，属于可以改进的点。

修改操作的经典坑是"更新了一条不存在的记录"或"更新时 WHERE 条件没带全"。看源码时重点看 UPDATE 语句后面是不是真的带上了 id 条件。我见过一份源码把更新语句写成了 UPDATE t_customer SET cname=? WHERE id=?，看起来没问题，但调用处取参数时把顺序搞反了，导致永远更新的是 id=1 那条数据。你排查问题时如果发现"改了 A 客户，B 客户也跟着变"，十有八九是参数顺序错了。

删除操作这里我想啰嗦两句。很多教学源码直接 DELETE FROM t_customer WHERE id=?，这在演示逻辑上没问题，但如果是真实的客户系统，我更推荐用"逻辑删除"——给表加一个 status 或 is_deleted 字段，删除时执行 UPDATE 而不是 DELETE。好处是数据可以追溯、误删可以恢复。虽然课堂项目用不上这个，但你在源码解析的文章里提到这个设计，就显得你比单纯抄代码的人理解深一层。

3.4 数据访问层的封装与 JDBC 改进

看客户管理系统的源码，你会发现几乎每个 DAO 类里都在重复做同一件事：加载驱动、获取连接、创建 PreparedStatement、执行、关闭连接。这种重复代码的解决方案是抽取一个 BaseDAO 或通用的 JdbcTemplate 工具类。

一个比较有教学价值的精简版封装长这样：

public class BaseDAO { public <T> List<T> query(String sql, Object[] args, RowMapper<T> mapper) { List<T> list = new ArrayList<>(); try (Connection conn = DBUtil.getConnection(); PreparedStatement ps = conn.prepareStatement(sql)) { for (int i = 0; i < args.length; i++) { ps.setObject(i + 1, args[i]); } try (ResultSet rs = ps.executeQuery()) { while (rs.next()) { list.add(mapper.mapRow(rs)); } } } catch (SQLException e) { throw new RuntimeException(e); } return list; } }

这里用到了 JDK 1.7 的 try-with-resources 语法，可以自动关闭声明在 try 括号里的资源，省去 finally 里手写 close。不过要注意一点：try-with-resources 关闭的顺序是逆序的，所以 ResultSet、PreparedStatement、Connection 会按正确的顺序依次关闭，不会出现"关了连接，结果集还没关"的问题。看到老代码还在 finally 里层层判空关闭，原理也一样，只是代码冗长。

关于连接管理，很多课程设计源码都是每次查询都 DriverManager.getConnection，查询完直接 close。在小项目、低并发下没问题，但你要知道这在真实项目里是不可行的——数据库连接是昂贵资源，频繁创建销毁性能很差。稍微进阶一点的源码会引入连接池（DBCP、C3P0、Druid），在项目启动时预热一批连接复用。你读源码时看一眼它拿连接的方式就能判断这份代码的"含金量"。

4. 环境配置与部署实战记录

4.1 从零跑通项目的环境清单

也许你拿到的源码没有配套的部署文档，这里我列一份普适性较强的环境配置清单，照着操作基本能跑通大部分基于 JSP + Servlet 的客户管理系统：

如果你在 Windows 上跑，记得 MySQL 8.0 默认的认证插件是 caching_sha2_password，老版本的驱动连接时会报"Unable to load authentication plugin"，这一步卡了很多人。

4.2 逐项解读易错的配置文件

跑一个客户管理系统，真正决定成败的配置文件就三个：数据库连接信息、web.xml、JSP 页面头部的编码声明。

数据库连接信息如果是 .properties 文件，内容大概长这样：

jdbc.driver=com.mysql.cj.jdbc.Driver jdbc.url=jdbc:mysql://localhost:3306/crm?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai jdbc.username=root jdbc.password=你的密码

第八版的 MySQL 驱动类名是 com.mysql.cj.jdbc.Driver，5.x 的旧驱动是 com.mysql.jdbc.Driver。如果你源码里是旧驱动名而你的 MySQL 是 8.0，会直接 ClassNotFoundException。连接 URL 里的 serverTimezone 参数也是 MySQL 8.0 才需要强制加的，否则会报时区错误。

web.xml 里主要看这几个节点：servlet 映射、过滤器配置、session 超时。session-timeout 标签值默认给 30，单位是分钟，额外记一下。如果你发现项目里自定义 servlet 用了注解 @WebServlet 而又在 web.xml 里配了一遍，注意别冲突。

JSP 页面的编码是最多人踩的坑：<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%> 这三处要保持一致。再加上让浏览器也按 UTF-8 解析。少任何一个都可能出现中文乱码。

4.3 部署演示的完整步骤

以 IDEA 为例，手动跑通一个项目的流程我按步骤拆开写：

1. 新建数据库并导入 SQL：在 Navicat 或命令行执行源码里的 crm.sql，确认 t_user 和 t_customer 都建好了，然后手动插入一条测试账号。
2. 修改 db.properties 里的数据库名、用户名、密码。这是最容易出错的一步，真见过有人改完还把 MySQL 服务没启动就去跑。
3. 在 IDEA 里配置 Tomcat：Run -> Edit Configurations -> 新增 Tomcat Server -> Local -> 选 Deployment，把项目以 war exploded 方式部署，Application context 改成 /crm 或直接 /。
4. 启动后访问 http://localhost:8080/crm/login.jsp，用刚才插入的账号登录。

这里我额外提醒：如果启动后访问 404，先看控制台有没有报错；没有报错的话，看访问路径是否和 Application context 一致。IDEA 里如果 Deployment 配的是 /，而你访问的是 /crm/login.jsp，就会命中 404。这类低级问题占了部署失败的八成以上。

5. 常见问题与排查技巧实录

5.1 中文乱码的全链路排查

客户管理系统里乱码问题基本能汇总成三种情况，每种的位置不同：

最关键的是理解这个链条：浏览器以 UTF-8 提交 -> Servlet 必须以 UTF-8 解析 -> 数据库连接必须用 UTF-8 存取 -> 数据库表本身必须是 UTF-8。任何一环断开，乱码就出现了。排查时先从数据库表编码查起，再查连接串，最后查代码，别一上来就改代码。

5.2 启动时 ClassNotFoundException 与数据库连接失败

这类错误分两种报错信息，处理完全不同。一种是启动时就抛 ClassNotFoundException: com.mysql.jdbc.Driver，说明 jar 包没放进 WEB-INF/lib。另一种是运行到数据库操作时报 Communications link failure，这基本是 MySQL 服务没启动，或者连接串里的 IP/端口不对。还有一个隐蔽的：防火墙拦截了 3306 端口，虽然少见，但在实验室环境下会遇到。

如果是 MySQL 8.0，还有密码加密插件的问题。老驱动连新数据库会直接拒绝认证。最简单粗暴的解决办法是把数据库用户的加密方式改成 mysql_native_password，但如果你的环境允许升级驱动，优先换新驱动而不是降数据库配置。

5.3 登录成功后跳转却返回 404 或 500

这个问题几乎每个人都会遇到，原因通常有两种。404 多半是"成功跳转的地址写错了"，比如 sendRedirect 里写成了 /customer/list 而实际 mapping 是 /CustomerListServlet。500 则集中在数据库查询异常，最常见的又分两种：SQL 语法错误（比如表名和数据库里不一致）和 ResultSet 取值越界（查到了空结果还强行 rs.getString）。

这里我分享一个排查技巧：看源码时先把所有 Servlet 上的 @WebServlet 注解 URL 列成一张清单，再和页面里所有 form action、response.sendRedirect、超链接 href 对照一遍，凡是路径对不上的先标记出来。做一遍这个核对，你基本能消灭一半以上的 404。

5.4 分页按钮点了没反应或页码丢失

分页链接常见的写法是：

<a href="${pageContext.request.contextPath}/customer/list?pageNum=1">首页</a>

如果你发现点第二页时候 URL 里的查询条件丢了，那是链接拼接时没带上之前的条件参数。正确做法是每次翻页时把 name、phone 这些搜索条件原样拼进 URL，通常源码里会用一个 PageBean 对象把这些参数统一存起来，JSP 输出时循环拼接。翻页丢条件是客户管理系统最典型的逻辑疏漏，读源码时你可以专门检验这一点。

5.5 修改功能提交后数据没变化

能想到的第一个地方是 SQL 的 UPDATE 语句写错了；第二个地方是表单字段的 name 属性和 Servlet 接收的参数名对不上。我自己遇到过最离谱的一次是 JSP 表单里把 phone 的 input name 写成了 tel，Servlet 里 getParameter("phone") 取到 null，然后程序把 null 更新进了数据库。排查时先打印接收到的参数：

Enumeration<String> names = request.getParameterNames(); while (names.hasMoreElements()) { String name = names.nextElement(); System.out.println(name + " = " + request.getParameter(name)); }

这个片段建议截图存下来，排查参数类问题比看半天代码都管用。

6. 读源码时值得留意的设计细节与改进方向

6.1 从源码里能学到的"小聪明"

尽管网上流传的教学源码质量参差不齐，但有几处设计我认为是通用的精华，值得你在自己的项目里借鉴。

第一是 PageBean 的封装。一个设计良好的 PageBean 会包含：当前页码 pageNum、每页条数 pageSize、总记录数 total、总页数 totalPage、查询结果列表 list，以及起止索引计算逻辑。JSP 里渲染分页条时只要循环 totalPage 就能打印出"1 2 3 4 5"的链接。读源码时把 PageBean 类画个结构图，分页这块你就真正吃透了。

第二是 BaseServlet 的抽象。有些版本会做这样一个父类：把 doGet/doPost 合并，根据隐藏参数 method 反射调用子类的具体方法。这样做的好处是减少 Servlet 类数量——一个 CustomerServlet 就能处理 list/add/update/delete 四个动作，而不是建四个 Servlet 类。虽然现在的主流框架早就用了更高级的路由方式，但这个思路本身很体现"减少重复代码"的设计感。

第三是消息提示的统一处理。成熟的代码保存成功后会通过 session 存一个 "msg"，然后重定向回列表页，列表页显示后立即移除。这种"重定向 + Flash 消息"的模式现在很多框架还在用，只是换个名字叫 Flash Attribute。在 Servlet 手写时代就能做出这个效果，说明作者对 Web 交互细节有思考。

6.2 值得动手改一改的扩展方向

源码读懂了以后，最好的巩固方式是动手改。我按难度从低到高给你列几个改造方向，每一个都能让你对系统有新的理解：

1. 给密码加盐：把 MD5Util 改成"随机盐 + 密码 + 固定盐"的加密方式，数据库加一个 salt 字段。改完你会对密码安全有更具体的认识。
2. 引入连接池：把 DBUtil 从 DriverManager 改成 Druid 连接池，注意配置文件的写法差异，再对比一下性能。
3. 增加"软删除"：客户表加 is_deleted 字段，所有查询默认过滤掉已删除数据，删除操作改成 UPDATE。这不难但很实用。
4. 客户导入导出：用 POI 把客户列表导出 Excel，或者从 Excel 批量导入客户数据。这个方向在企业里几乎必考。
5. 前端增强：同上 Bootstrap 或现成的后台模板，把 JSP 的 table 换成带搜索、排序、弹窗确认的组件，体验会有质的飞跃。

每一项都不需要重写整个系统，却能把好几种新技能的坑都踩一遍。而且做完之后你手上就有了一个比原始源码成熟得多的小项目，无论是写简历还是面试讲项目，素材都够用了。

6.3 我踩过几次坑之后的一点体会

客户管理系统这种项目的源码，看一遍和手写一遍是完全不同的体验。我自己带人总结出一个固定的"三步法"：第一步打开源码连上数据库，把所有的表结构和字段先摸一遍；第二步从 web.xml 或注解列表出发，把每个 URL 对应的 Servlet 画出来；第三步沿着一次完整的用户操作链路（比如登录后新增客户）像讲故事一样把代码从 JSP 到 DAO 走一遍。走完这三步，这份源码在你眼里就不再是一堆零散的类，而是一张清晰的地图。

再分享一个很小但每次都用得上的技巧：看别人的源码时，遇到看不懂的方法别硬看，直接搜它的调用处，看它被谁调用了、传入什么值、返回值做了什么。倒着读代码往往比从头往下读更容易理解复杂系统，因为你在意的是逻辑流向，而不是作者写的顺序。如果你想真正吃透 Java Web 这一块，用这个方法拆个三五套客户管理系统源码，配合自己动手改造一两轮，后面的 Spring Boot 学起来会轻松不少。