企业官网建设流程全解析

简介：一套面向计算机相关专业毕业设计的Java校园快递物流管理系统完整项目包，基于SSM（Spring + SpringMVC + MyBatis）框架实现，覆盖用户管理、快递信息录入/查询/更新/删除、身份验证与权限控制等核心模块，适合需要完成系统设计、编码与论文撰写的本科生参考。压缩包共644个文件，约67.57MB，包含143个js、97个png、77个jar、36个css、32个jsp、27个html、24个xml等，js/css/jsp/html负责前端展示与交互，jar为依赖库，java/class为后端源码与编译产物，sql文件为MySQL数据库脚本，另有docx/PDF文档与视频演示，便于搭建运行环境并理解项目结构。已有28人浏览学习，可作为毕业设计选题、功能扩展或技术复习的案例。资源附毕业设计论文、API接口文档和操作手册，配合源码可快速跑通校园快递收发、查询、管理全流程，同时通过加密、事务与异常处理等设计展示了企业级开发思路，具备较强的参考与复用价值。

1. 给校园快递站做一套能答辩的物流系统：这个SSM项目到底在做什么

每天中午，校园快递点门口排起长队，货架上的包裹堆到地上，同学报出手机尾号，工作人员在一堆快递里翻找。错拿、滞留、超期退回全靠人工登记，站长最怕的不是高峰，而是学生投诉「包裹明明到了却找不到，系统里也没有记录」。这个标题下的 SSM 校园快递物流管理系统，做的就是把这套流程搬进系统：包裹入库、取件码通知、签收确认、滞留管理全部线上化。Spring + SpringMVC + MyBatis 的经典三层架构，前台查询、后台管理，角色分学生、快递员、管理员。对做毕设的 Java 方向学生来说，它覆盖了 SSM 框架、数据库设计、权限拦截、分页查询这些必考点，而且自带论文文档和源码，拿到手可以直接照着跑通、对着改。这篇文章会按我做这类项目的顺序，把功能拆解、数据库设计、核心代码、部署排错、答辩演示完整过一遍。

2. 从取件码到签收记录：功能模块拆解与SSM选型理由

2.1 站在快递站长的视角反推：系统至少要有哪几个模块

很多人做毕设习惯从「技术有什么」出发，把网上抄来的功能堆上去，结果论文写需求分析时编不出来。我一般反过来，先把自己想象成快递站站长，问一个问题：如果我是站长，最想让系统替我解决什么？

第一是包裹入库。快递员把包裹送过来，我扫一眼收件人信息，把包裹放到货架某个位置，同时记下「这个包裹在哪、收件人是谁」。第二是通知取件。学生不能一直盯着快递点，系统要在包裹入库后告诉他「你的包裹到了，取件码是 A-3-2152，在 3 号货架」。第三是签收确认。学生拿走包裹前确认身份，避免错拿。第四是逾期管理。包裹放太久没人取，得能筛出来，联系学生或者退回。这四个核心诉求对应下来，系统至少要拆成前台查询、后台管理、系统管理三大块。

前台面向学生，功能不多但使用频率最高：按手机号或取件码查快递、查看当前状态、留存的取件码、确认签收。后台面向快递员和站点工作人员，是工作量最重的地方：快递录入、批量导入、修改错录信息、标记退回、查看滞留列表。系统管理则面向管理员：用户管理、角色分配、站点设置。像我经手过的这类项目，还会额外加一个「操作日志」，不光是应付论文的系统测试，关键是有据可查——学生说没收到，你能看到他什么时候点击了签收。

模块不在多，在于能不能把故事讲圆。你在论文里画用例图的时候会发现，每个用例都必须对应一个真实场景，否则答辩老师问一句「这个功能谁在用、什么时候用」，你答不上来就露馅。所以模块拆解这一步别偷懒，哪怕最后只做了 8 个功能页面，只要是场景推出来的，比 20 个抄来的页面有用得多。

2.2 为什么毕业设计不选Spring Boot而选SSM：三个现实理由

这两年不少学生来问我：老师，Spring Boot 都快成默认框架了，为什么毕设还让我做 SSM？这个问题很实际，我每次都会给三个理由，都是血泪经验换来的。

第一，课程体系衔接。很多高校的 Java 课程还停在 Servlet + JSP + 三层架构这一套，SSM 正好是这个体系的延伸：SpringMVC 替代 Servlet 做控制层，MyBatis 替代 JDBC 做持久层。你用 SSM，论文里的架构图和课程设计能对上，不用重新学一套「约定优于配置」的思路。Spring Boot 当然也可以做毕设，但你会被追问：为什么一个注解就能把项目跑起来？原理是什么？对大多数人来说，这比做系统本身还难讲。

第二，分层清晰，论文有东西写。SSM 的代码结构天然分成 Controller、Service、Mapper 三层，每一层职责单一。写论文时，需求分析、概要设计、详细设计、系统实现、测试，每一章都能找到对应内容。Spring Boot 把很多东西自动装配掉了，你反而要花更多篇幅解释「为什么没写这些配置」，对一个以工程实践为主的本科毕设来说，性价比不高。

第三，手工配置更能暴露问题，也能锻炼排查能力。SSM 的 XML 配置、JAR 包依赖、Tomcat 部署每一步都可能出错，但正因如此，你做完一遍后对「项目是怎么从零跑起来的」有完整认知。Spring Boot 的黑匣子效应太强，出了问题都不知道去哪翻日志。当然，如果你已经工作过、对框架原理有把握，用 Spring Boot 没问题；但如果是第一次完整做个 Web 项目，SSM 是更稳的路。

2.3 SSM常用注解怎么分配职责：Controller、Service、Mapper三层边界

SSM 常用的注解就那么几个，难的是理解它们各自管什么。我见过太多人把 @Controller 和 @Service 混着用，或者干脆所有逻辑都堆在 Controller 里，导致事务失效、后期根本没法维护。

先看一张职责表，这是我做 SSM 项目时基本照抄的心智模型：

实际写代码时，我会额外遵守两条约定。第一，Controller 里只做「参数接收 → 调用 Service → 把结果放进 Model 或返回 JSON」这三件事，任何if判断都不写，一旦发现 Controller 里出现超过三行的逻辑，立刻往下挪到 Service。第二，Service 接口只暴露粗粒度的方法，比如addExpress(Express express)而不是insertExpress(...)、updateExpress(...)分开调用，这样调用方不需要关心内部有几步，事务也容易圈在同一个方法里。

至于 @Autowired 和 @Resource 的区别，面试常问，但对做毕设来说，知道 @Autowired 按类型注入、@Resource 默认按名称注入就够了。真正要注意的是：在spring-mvc.xml里配<context:component-scan>时，Controller 单独扫com.xx.controller包，Service 和 Mapper 由applicationContext.xml扫，两套容器职责分开。如果你把 Controller 放进 Spring 容器而没进 SpringMVC 容器，请求会 404，这个问题我在 5.2 节还会再提。

3. 数据库设计：五张表撑起校园快递的完整流转链路

3.1 用户表和快递单表的字段设计：把身份和包裹先固定下来

数据库设计是 SSM 项目里最不能省的一步，因为表结构一旦定下来，后面改字段的代价远超你想象。我做完第一个毕设后的最大教训就是：建表前先拿纸把「一个包裹从进站到出站要经过哪些人、哪些状态」画出来，再动手写 SQL。

这个系统的核心是两张表：用户表和快递单表。用户表存三类角色，用role字段区分；快递单表存包裹的流转信息。下面是我常用的建表脚本，在 MySQL 5.7 下可直接执行：

CREATE TABLE `tb_user` ( `user_id` INT NOT NULL AUTO_INCREMENT COMMENT '用户ID', `username` VARCHAR(50) NOT NULL COMMENT '登录账号', `password` VARCHAR(100) NOT NULL COMMENT '密码（建议MD5加密存储）', `real_name` VARCHAR(50) DEFAULT NULL COMMENT '真实姓名', `phone` VARCHAR(20) DEFAULT NULL COMMENT '手机号', `role` TINYINT NOT NULL DEFAULT 2 COMMENT '角色：0-管理员，1-快递员，2-学生', `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', PRIMARY KEY (`user_id`), UNIQUE KEY `uk_username` (`username`), KEY `idx_phone` (`phone`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户表'; CREATE TABLE `tb_express` ( `express_id` INT NOT NULL AUTO_INCREMENT COMMENT '快递单ID', `tracking_no` VARCHAR(64) DEFAULT NULL COMMENT '快递公司运单号', `receiver_id` INT NOT NULL COMMENT '收件人ID，关联tb_user.user_id', `receiver_name` VARCHAR(50) NOT NULL COMMENT '收件人姓名（冗余，便于查询）', `receiver_phone` VARCHAR(20) NOT NULL COMMENT '收件人手机号（冗余）', `company` VARCHAR(30) DEFAULT NULL COMMENT '快递公司，如顺丰/圆通', `shelf_no` VARCHAR(20) DEFAULT NULL COMMENT '货架编号，如A-3', `pickup_code` VARCHAR(20) NOT NULL COMMENT '取件码', `status` TINYINT NOT NULL DEFAULT 0 COMMENT '状态：0-已入库待取件，1-已签收，2-滞留退回', `arrival_time` DATETIME DEFAULT NULL COMMENT '入库时间', `pickup_time` DATETIME DEFAULT NULL COMMENT '签收时间', `operator_id` INT DEFAULT NULL COMMENT '入库操作员ID', PRIMARY KEY (`express_id`), UNIQUE KEY `uk_pickup_code` (`pickup_code`), KEY `idx_receiver_phone` (`receiver_phone`), KEY `idx_status` (`status`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='快递单表';

这里有个细节值得展开：receiver_name和receiver_phone在快递单表里冗余了一份。严格按三范式设计，这两列应该去关联tb_user查，但校园快递的场景里，经常出现「帮同学代取」「快递员手工录入时收件人还没注册系统」的情况。冗余字段的取舍标准是：如果查询压力大于写压力、且数据一致性要求没那么极端，冗余就值得。论文里这属于「反范式设计」，可以写进数据库设计章节，但答辩时你要能说清楚为什么。

3.2 取件码生成：货架号加随机码的组合规则与唯一性约束

取件码是整个系统里学生唯一会主动记住的东西。设计得不好，轻则重码取错件，重则学生拿着一个取件码找不到任何包裹。我的做法是把取件码拆成两段：货架号加随机码，例如A-3-2152，表示「A 区 3 号货架，柜位码 2152」。

货架号解决「去哪找」，随机码解决「是哪一件」。生成逻辑不难，但要注意并发。常见的错误做法是先查一次表看有没有重复，没有再插入，这在单用户调试时不会出问题，一旦多个快递员同时入库，两个请求可能查到同一个随机码，然后同时通过检查，插入时被唯一索引拦下来，抛异常。

正确的落地方式是两手抓。第一，pickup_code字段加唯一索引，数据库层面兜底；第二，代码里生成随机码后循环查重：

public String generatePickupCode(String shelfNo) { // 随机码范围：1000-9999，共9000个，加上货架号后足以支撑一个站点日常入库 int randomPart = ThreadLocalRandom.current().nextInt(1000, 10000); String code = shelfNo + "-" + randomPart; // 查重：有唯一索引兜底，这里主要避免无谓的SQL异常 int tryCount = 0; while (expressMapper.countByPickupCode(code) > 0 && tryCount < 10) { randomPart = ThreadLocalRandom.current().nextInt(1000, 10000); code = shelfNo + "-" + randomPart; tryCount++; } return code; }

逻辑说明：expressMapper.countByPickupCode(code)返回该取件码在表中已存在的数量，若大于 0 就重新生成，最多重试 10 次。参数说明：nextInt(1000, 10000)生成左闭右开的四位数，避免出现 0123 这类学生念起来别扭的号码；重试上限 10 次是为了防止极端情况下死循环。

实际运营中，9000 个随机码对校园快递点完全够用，因为快递滞留周期短，取件码随签收释放，同一天活跃的包裹通常不会超过几千个。论文里把这个机制写成「取件码唯一性保证策略」，属于需求分析中一个不错的亮点。

3.3 状态字段与时间字段：一条快递单从入库到签收的流转过程

状态字段我用TINYINT而不是字符串，原因有三：存储空间小、索引效率高、Java 代码里比对方便。代价是可读性差，所以建表注释里必须写清楚每个数字的含义，这也是给论文截图做准备的。

状态流转不复杂，但边界条件要想清楚：

• 0已入库待取件：快递员录完单，系统生成取件码，此时arrival_time写入
• 1已签收：学生验码取件，点确认签收，pickup_time写入
• 2滞留退回：超过预设天数没人取，快递员操作退回

我见过不少项目把状态做成「待入库、已入库、已通知、已签收」，中间多一个「已通知」状态，看起来功能更细，但实际很难触发——短信是入库时自动发的，和入库几乎是同一时刻。多余的中间状态只会让代码里多出无数if (status == 2)的判断，论文测试也说不清。能合并的状态尽量合并，保持单子的流转路径是一条直线。

时间字段上，arrival_time和pickup_time由程序写入，不要依赖数据库的DEFAULT CURRENT_TIMESTAMP，因为业务上你可能要按操作员的实际确认时间来记。另外建议加一个update_time字段，每次更新自动刷新，方便出问题排查。

至于「滞留退回」的判断逻辑，我在项目里用一个定时任务或者干脆在查询时动态算：arrival_time超过 72 小时且状态仍为 0，就显示在「滞留列表」里，让快递员决定是否操作退回。这套方案的优点是省掉了一个常驻任务，缺点是只能被动展示，不能主动推送。对毕设来说，动态查询方案更简单，而且论文里照样能写「基于缓存策略的滞留预警设计」。

4. 核心功能落地：登录拦截、快递入库与MyBatis动态SQL

4.1 登录与权限拦截：基于拦截器校验Session的常见写法

SSM 项目里做登录校验，最常见的做法不是 Spring Security，而是拦截器。原因很现实：Spring Security 学习曲线陡，配置复杂，对一个毕设项目来说属于「杀鸡用牛刀」，而且答辩时解释不清。用拦截器你大概 30 行代码就能搞定，逻辑还非常直观。

先写一个拦截器类：

public class LoginInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 放行登录接口和静态资源 String uri = request.getRequestURI(); if (uri.contains("/login") || uri.contains("/static/") || uri.contains(".css") || uri.contains(".js")) { return true; } // 从Session取登录凭证，取不到就跳转登录页 HttpSession session = request.getSession(); Object loginUser = session.getAttribute("loginUser"); if (loginUser == null) { response.sendRedirect(request.getContextPath() + "/login"); return false; } // 按角色做二次校验：管理员/快递员才允许进后台 User user = (User) loginUser; if (request.getRequestURI().contains("/admin") && user.getRole() == User.ROLE_STUDENT) { response.sendRedirect(request.getContextPath() + "/index"); return false; } return true; } }

逻辑说明：preHandle在所有 Controller 方法执行前被调用，返回true放行、false拦截。第一段用uri.contains做了白名单判断，把登录请求和 CSS、JS 静态资源放过去，避免「登录页加载不出来」的尴尬；第二段从 Session 里取用户，这是 SSM 项目里最常见的会话管理方式，简单够用；第三段做了粗粒度的角色拦截，学生用户禁止访问/admin开头的后台页面。

然后在spring-mvc.xml里注册拦截器，并配置拦截路径：

<mvc:interceptors> <mvc:interceptor> <mvc:mapping path="/**"/> <mvc:exclude-mapping path="/login"/> <mvc:exclude-mapping path="/static/**"/> <bean class="com.kaic.interceptor.LoginInterceptor"/> </mvc:interceptor> </mvc:interceptors>

参数说明：/**表示拦截所有请求；/login和/static/**是排除项，与拦截器里的白名单作用相同，但用在这里更规范。注意拦截器的exclude-mapping优先级高于mapping，两者冲突时以排除为准。

4.2 快递入库的完整链路：Controller、Service、Mapper三层各写什么

快递入库是后台最核心的功能，我用它来演示三层的标准分工。需求一句话：快递员填写收件人姓名、手机号、快递公司、货架号，点保存，系统生成取件码并入库。

Controller 层只负责接收和转发：

@Controller @RequestMapping("/express") public class ExpressController { @Autowired private ExpressService expressService; @PostMapping("/add") public String addExpress(ExpressForm form, HttpSession session) { // 从Session取当前登录的快递员，作为operatorId User operator = (User) session.getAttribute("loginUser"); // 调Service完成入库，同时拿到生成的取件码 String pickupCode = expressService.addExpress(form, operator.getUserId()); // 用RedirectAttributes把取件码带到列表页提示 return "redirect:/express/list?pickupCode=" + pickupCode; } }

Service 层承载业务规则，也是事务边界：

@Service public class ExpressServiceImpl implements ExpressService { @Autowired private ExpressMapper expressMapper; @Override @Transactional(rollbackFor = Exception.class) public String addExpress(ExpressForm form, Integer operatorId) { // 1. 校验手机号格式：11位，1开头 String phone = form.getReceiverPhone(); if (phone == null || !phone.matches("^1\\d{10}$")) { throw new IllegalArgumentException("收件人手机号格式不正确"); } // 2. 生成唯一取件码 String pickupCode = generatePickupCode(form.getShelfNo()); // 3. 组装实体并插入 Express express = new Express(); express.setTrackingNo(form.getTrackingNo()); express.setReceiverName(form.getReceiverName()); express.setReceiverPhone(phone); express.setCompany(form.getCompany()); express.setShelfNo(form.getShelfNo()); express.setPickupCode(pickupCode); express.setStatus(Express.STATUS_PENDING); express.setArrivalTime(new Date()); express.setOperatorId(operatorId); expressMapper.insert(express); return pickupCode; } }

Mapper 层就是接口加 XML：

public interface ExpressMapper { int insert(Express express); Express selectByPickupCode(String pickupCode); List<Express> selectByCondition(ExpressQuery query); }

<insert id="insert" parameterType="com.kaic.entity.Express" useGeneratedKeys="true" keyProperty="expressId"> INSERT INTO tb_express (tracking_no, receiver_id, receiver_name, receiver_phone, company, shelf_no, pickup_code, status, arrival_time, operator_id) VALUES (#{trackingNo}, #{receiverId}, #{receiverName}, #{receiverPhone}, #{company}, #{shelfNo}, #{pickupCode}, #{status}, #{arrivalTime}, #{operatorId}) </insert>

分层逻辑说明：Controller 不直接调 Mapper，而是通过 Service 中转，这样事务注解@Transactional才能真正圈住「生成取件码 + 插入记录」两步操作——如果插库失败，取件码不会残留。useGeneratedKeys="true"让数据库自增主键回填到实体的expressId，后续打印回执或关联操作都能直接用。

4.3 MyBatis动态SQL：多条件组合查询与批量入库

学生查询快递是前台最频繁的操作，条件不固定：有的人输手机号，有的人输取件码，还有人只记得快递公司和大概时间范围。这种需求正是 MyBatis 动态 SQL 的用武之地。

<select id="selectByCondition" parameterType="com.kaic.query.ExpressQuery" resultType="com.kaic.entity.Express"> SELECT * FROM tb_express <where> <if test="receiverPhone != null and receiverPhone != ''"> AND receiver_phone = #{receiverPhone} </if> <if test="pickupCode != null and pickupCode != ''"> AND pickup_code = #{pickupCode} </if> <if test="company != null and company != ''"> AND company = #{company} </if> <if test="status != null"> AND status = #{status} </if> <if test="startTime != null"> AND arrival_time &gt;= #{startTime} </if> <if test="endTime != null"> AND arrival_time &lt;= #{endTime} </if> </where> ORDER BY arrival_time DESC </select>

逻辑说明：<where>标签会自动去掉开头多余的AND；<if>标签逐个判断查询参数是否为空，为空就不拼进 SQL。这样 Java 代码里不用写一堆if-else去拼 SQL 字符串，MyBatis 帮你处理了查询条件的动态组合。>=和<=是 XML 中的转义写法，直接写>=会导致 XML 解析报错，这是新手最容易翻车的地方。

批量入库是快递员高峰期最需要的功能：一次性录入 10 个包裹，不可能循环调insert10 次，那样数据库连接来回消耗太大。MyBatis 的<foreach>批量插入：

<insert id="batchInsert" parameterType="list"> INSERT INTO tb_express (tracking_no, receiver_name, receiver_phone, company, shelf_no, pickup_code, status, arrival_time, operator_id) VALUES <foreach collection="list" item="item" separator=","> (#{item.trackingNo}, #{item.receiverName}, #{item.receiverPhone}, #{item.company}, #{item.shelfNo}, #{item.pickupCode}, #{item.status}, #{item.arrivalTime}, #{item.operatorId}) </foreach> </insert>

参数说明：collection="list"对应 Mapper 接口中传入的List<Express>；item="item"是循环中的别名；separator=","控制每条插入语句之间用逗号分隔。批量插入时pickupCode的生成要在 Java 侧提前完成，不能在 SQL 里动态生成，因为每个包裹的货架号不同。另外注意 MySQL 的连接串要加allowMultiQueries=true才能支持这种批量语法，但如果是用上面这种一条 INSERT 多 VALUES 的写法，不需要开启多查询，这也是它比;拼接多条 SQL 更安全的原因。

动态 SQL 还有个常被忽略的作用：日志调试。把 MyBatis 的log-impl配成StdOutImpl，控制台会打印完整 SQL 和参数，排查「为什么查出来的范围不对」时会省很多力气。我每次调这类多条件查询，都会先看打印出来的 SQL 是不是自己想要的，再去看数据。

5. 本地部署与常见问题排查：从Tomcat启动失败到中文乱码

5.1 把SSM项目在本地跑起来：环境准备与部署步骤

拿到一个 SSM 毕设源码包，第一步不是急着打开 IDEA 写代码，而是先把环境对齐。这类项目最常见的坑就是版本不匹配：JDK 用了 17、Tomcat 用了 10、MySQL 用了 8.0，结果启动报错一堆，你以为是项目的问题，其实是环境的问题。

我的固定组合是：JDK 1.8 + Maven 3.6.x + Tomcat 8.5 + MySQL 5.7，这套组合和绝大多数 SSM 项目兼容，不会有 javax 命名空间被删除的问题。如果你发现项目报NoClassDefFoundError: javax/servlet/...，十有八九是 JDK 版本太高或 Tomcat 版本太新。

部署步骤按下面顺序来，缺一步都可能翻车：

# 1. 先建数据库并执行项目里的sql脚本 mysql -uroot -p123456 < database/express_db.sql # 2. 修改资源文件里的数据库连接配置 # 位置一般为 src/main/resources/jdbc.properties

jdbc.driver=com.mysql.jdbc.Driver jdbc.url=jdbc:mysql://localhost:3306/express_db?useUnicode=true&characterEncoding=utf8&useSSL=false jdbc.username=root jdbc.password=123456

参数说明：useUnicode=true&characterEncoding=utf8是中文不乱码的基础；useSSL=false是关掉 MySQL 8.0 默认的 SSL 握手，减少一条报错。如果你的 mysql-connector-java 是 8.x 版本，driver 类要写成com.mysql.cj.jdbc.Driver，并在 URL 上额外加serverTimezone=Asia/Shanghai，否则会报时区错误。

# 3. 用 Maven 打 war 包 mvn clean package -DskipTests # 4. 把 war 包丢进 Tomcat 的 webapps 目录，启动 cp target/express.war /path/to/tomcat/webapps/ sh /path/to/tomcat/bin/startup.sh # 5. 查看日志确认没有异常 tail -f /path/to/tomcat/logs/catalina.out

在 IDEA 里跑的话，配置一个 Tomcat 8.5 的本地服务器，Deployment 选择express:war exploded，Application context 填/express，启动后访问http://localhost:8080/express/。这里注意context路径一定要和数据库初始化的数据一致，如果项目里写死了某段重定向路径，你改了 context 后所有跳转都会断。

5.2 排坑清单：五个高频问题的现象、原因与解决

我梳理一下 SSM 项目里出现频率最高的五个问题，每一条都是真实环境里踩过、帮别人排查过的，新手的项目卡住基本就这几种原因。

问题一：Tomcat 启动直接报错，页面 404。现象是控制台抛ClassNotFoundException: org.springframework.web.context.ContextLoaderListener。原因多数是spring-web这个 JAR 没有打进 lib。解决方式：检查 pom.xml 里有没有引用 spring-web 相关依赖，mvn dependency:tree看依赖树，确认 Spring 版本统一，最好在 pom 里显式声明版本号，不要依赖传递依赖的随机版本。

问题二：页面中文全部变成问号或乱码。现象是登录页能打开，但所有中文显示为???。原因通常是三处不一致：Tomcat 接收请求的编码、MySQL 存储的编码、JSP 输出编码其中有一个不对。解决方式按顺序排查：Tomcat 的server.xml里给 Connector 加URIEncoding="UTF-8"；jdbc.properties里 URL 带上characterEncoding=utf8；项目的每个 JSP 第一行写<%@ page pageEncoding="UTF-8" %>。这三处统一后，99% 的乱码问题都能解决。

问题三：MyBatis 报BindingException: Invalid bound statement。现象是运行期调用 Mapper 方法时报找不到 SQL 语句，但接口和 XML 看起来都在。原因是 Mapper 的 XML 文件没有被打进target/classes。Maven 默认只把src/main/resources下的文件作为资源，如果你把 XML 放在src/main/java的包目录下，需要在 pom.xml 里补一段资源配置：

<build> <resources> <resource> <directory>src/main/java</directory> <includes> <include>**/*.xml</include> </includes> </resource> <resource> <directory>src/main/resources</directory> </resource> </resources> </build>

这段配置的作用是把src/main/java下的 XML 文件也复制到类输出目录，否则要保留 XML 与 Mapper 接口同包就只能靠这个手段。

问题四：启动时报Cannot load driver class: com.mysql.jdbc.Driver。现象是数据库连接池初始化失败。原因基本是 mysql-connector-java 的版本与 MySQL 服务端版本跨度太大。5.x 驱动用com.mysql.jdbc.Driver，8.x 驱动必须用com.mysql.cj.jdbc.Driver，而且 8.x 对时区敏感，URL 少了serverTimezone就直接拒绝连接。解决方式：直接换一个 5.1.49 版本的驱动，和 MySQL 5.7 配合最稳。

问题五：静态资源 CSS/JS 加载不出来。现象是页面能打开但没有任何样式，F12 看到资源请求全部 404。原因是在 web.xml 里配置了DispatcherServlet映射为/，把 Tomcat 默认的静态资源处理器覆盖了。解决方式是在spring-mvc.xml里放行静态资源：

<mvc:resources mapping="/static/**" location="/static/"/>

这条配置告诉 SpringMVC：所有以/static/开头的请求直接去对应的物理目录找文件，不再经过 Controller。对毕设项目来说，把 CSS、JS、图片统一放在webapp/static/下是最省事的做法，比散落各处的绝对路径好维护得多。

6. 答辩演示的验证方法：用一条快递单的完整生命周期讲清系统

答辩时间有限，与其把十几个功能页面挨个点一遍，不如把一条快递单从头走到尾，让老师看到整个系统是怎么转起来的。我的固定演示路线是：管理员登录 → 创建快递员账号 → 快递员登录 → 录入一个包裹 → 系统自动生成取件码 → 用学生手机号登录查询 → 看到包裹和取件码 → 点击确认签收。整个过程大概 3 分钟，但覆盖了用户管理、权限拦截、快递入库、查询、状态流转五个核心功能，信息密度远高于乱点一通。

演示前一定要做一次「状态重置」。把测试数据清空，让流程从零开始，否则老师看到打开页面就有 30 条记录，会分不清哪些是你现场演示的。另外准备一个「异常演示」：故意输入错误的手机号格式，让系统弹出校验提示。这比流畅走完一遍更能体现你对业务的理解。

论文这边，答辩老师翻阅最多的是需求分析、系统设计、系统测试三章。需求分析要回应第 2 章拆出来的功能模块；系统设计要回应第 3 章的数据库表和第 4 章的分层架构；系统测试要对应第 3 章的状态流转和第 4 章的动态 SQL。写测试用例时不要写「功能正常」这种话，要写「输入手机号 138xxxx0000，点击查询，期望返回该用户所有待取快递」，有输入、有操作、有期望结果，这才叫测试。

最后说一句我做毕设这几年最深的感触：能用「一条快递单的生命周期」讲清楚的系统，远比堆砌了一堆半成品功能却互相孤立的系统更有说服力。如果你时间紧张，优先把主流程打通，再补花哨功能。希望帮到你。

本文还有配套的精品资源，点击获取