简介：面向Java毕业设计或课程设计场景的酒店客房预定管理系统完整项目包，基于SSM框架与JSP技术实现，按管理员、用户两类角色划分权限。管理员可完成客房类型与房态管理、预定单处理、开房记录登记、退房结账及系统公告维护；用户端则支持首页浏览、在线选房、提交预定及个人后台管理。压缩包共1253个文件，约18.15MB，涵盖112个Java源码、103个JSP页面、364个JS脚本以及CSS、PNG等前端静态资源与SQL数据库脚本，并附有说明文档、LW论文和PPT演示文稿，便于直接导入IDEA配置运行。目前已有208人学习下载，适合需要快速搭建完整SSM项目、理解酒店业务表设计与权限流程的毕业生或初学者参考借鉴。

1. 拿到这个压缩包之后，毕业设计就完成一半了

酒店客房预定管理系统，是 Java 毕业设计里出现频率最高的一类题目。原因很直接：业务边界清楚，无非是客房、订单、会员、入住退房这几张核心表；角色划分自然，管理员和前台用户各有一套操作界面；再加上 SSM 是很多高校仍然在用的主流教学框架，答辩时老师容易看懂、愿意提问，学生也容易讲清楚。你手里的这个 zip 包，文件名里明确写了ssm+jsp完整源码+说明文档+LW+PPT，意味着不光代码有，论文和汇报材料也一并配齐了。

但这个包能不能真正变成你答辩时能演示、能讲透的系统，取决于你接下来几小时的动手能力。常见的翻车现场是：解压之后对着源码一脸茫然，IDEA 里导入报错，MySQL 密码不对连不上库，Tomcat 启动直接崩。这篇笔记就按我平时帮同学调毕业设计的顺序，把从解压到跑通、再从跑通到讲明白的完整路线拆给你。适合有 Java 基础但没完整做过 Web 项目的同学，也适合想快速复用这套代码改成自己题目的熟手。

先说结论：这个包的价值不在"代码能跑"，而在"代码结构能讲"。SSM 项目最大的坑不是写不出来，而是环境不一致导致跑不起来。我们往下走每一步，我都会告诉你为什么要这么做，以及出问题时去查哪里。

2. 拆开这套 SSM 项目：技术栈选型和跑起来的最小环境

2.1 SSM 和 JSP 分别扮演什么角色，为什么毕业设计爱用这套

SSM 是 Spring、SpringMVC、MyBatis 三个框架的合称。在这个酒店系统里，它们的分工是：Spring 做 Bean 管理和事务控制，把 Service 层对象管起来；SpringMVC 负责接收浏览器发来的 HTTP 请求，把 URL 映射到 Controller 里的方法；MyBatis 负责数据库访问，把 SQL 写在 mapper 里，返回的对象自动映射成 JavaBean。JSP 则跑在服务端，直接在 HTML 里嵌入 EL 表达式和 JSTL 标签，从 Model 里取数据渲染页面。

这套组合和更现代的 Spring Boot 相比，配置繁琐是出了名的，但它恰恰是毕业设计题目的主流答案。导师熟悉这套楼的每一个角落，网上可查的资料存量极大，遇到问题搜答案基本上是"你踩过的坑，前辈都踩过"。Spring Boot 虽然写起来省事，答辩时老师一句"事务注解底层怎么生效的"就能把你问住，而 SSM 的配置本身就是最好的教案——每个配置文件都对应一个架构问题。

JSP 在现在的商业项目里已经不常见了，但它和 SSM 搭配的好处是门槛低：页面改了不用重启整个应用，重新编译一下 JSP 就能看到效果。对毕设来说，这意味着你演示时可以现场改页面标题、改表格列名，刷新就能生效，给老师的观感是"这系统真是你搭的"。

2.2 搭建环境清单：版本怎么配才不会互相打架

很多同学项目跑不起来，不是因为代码有问题，而是 JDK、Tomcat、Maven 版本不匹配。我直接给出我常用的一套组合，照着装基本不会出大问题：

装完之后先别急着打开项目，在命令行确认环境变量是对的。这一步能筛掉一半的黑匣子问题：

java -version mvn -v mysql --version

三条命令的输出要能看到版本号，而不是"不是内部或外部命令"。注意 MySQL 那条，Windows 下如果没把 mysql 的 bin 目录加进 Path，直接在命令行敲 mysql 是找不到的，去服务列表里确认 MySQL 服务有没有起来更实在。

装完环境，再确认 MySQL 里有 root 用户并且密码是你知道的。SSM 项目的数据库账号密码通常写在jdbc.properties里，默认可能是 root/root 或者 root/123456，如果连接串里写的是 root 密码 123456，你本地 MySQL 的 root 密码就必须是 123456，或者你去改配置文件。这一步不提前对齐，后面启动必报Access denied for user。

2.3 导入 IDEA 和 Maven 依赖下载：两个最容易卡住半小时的环节

解压 zip 后，你会看到一个典型的 Maven 工程目录：src/main/java放 Java 代码，src/main/resources放配置文件，src/main/webapp放 JSP 页面和静态资源，根目录有pom.xml。导入 IDEA 的方式是选择pom.xml作为 Maven 项目导入，而不是直接把文件夹拖进 IDEA 里当普通工程打开——后者经常导致依赖识别不了，代码里夹着大片红色报错。

# 进入项目目录后，先用命令行做一次干净构建 mvn clean package -DskipTests

第一次跑这个命令时会下载大量依赖，速度取决于网络环境。如果几分钟后报下载失败，优先检查 Maven 的镜像源配置。国内访问 Maven 中心仓库经常超时，需要在settings.xml里配置阿里云或其他镜像源。这是 Maven 项目最常见的前置坑，跟你写的代码有没有问题一点关系都没有。

<!-- settings.xml 中的 mirror 配置 --> <mirror> <id>aliyun</id> <mirrorOf>central</mirrorOf> <url>https://maven.aliyun.com/repository/public</url> </mirror>

依赖下载结束后，IDEA 右侧 Maven 面板里应该能看到 dependencies 树形展开不报红。clean package -DskipTests如果 BUILD SUCCESS，说明源码本身没有编译错误。到这个阶段，你的工作已经完成了 40%，剩下的就是启动、连库、看页面。

3. 数据库设计与初始化脚本：看懂五张核心表，论文里就有一整章内容

3.1 酒店预定系统最少需要几张表，字段怎么设计

打开源码里的 SQL 脚本（通常在db/或sql/目录，文件名类似hotel.sql），你大概率会看到这些表：用户表（前台顾客）、管理员表、客房类型表、客房表、订单表。有些项目会多一张留言表或新闻表，那是往"功能丰富度"上加分的扩展表，不是核心。

我在给同学梳理这套表结构时，习惯用一句话概括每张表的职责：用户表管谁能登录前台；管理员表管谁能在后台改房价；客房类型表管"豪华大床房"这类标签属性；客房表管具体的房间号、楼层、可住人数，每一条记录对应酒店里的一间实体房间；订单表是核心中的核心，把用户、客房、入住日期、退房日期、订单状态这些信息串联起来。

-- 核心订单表结构参考 CREATE TABLE `t_order` ( `id` INT(11) NOT NULL AUTO_INCREMENT, `order_no` VARCHAR(32) DEFAULT NULL COMMENT '订单编号，唯一', `user_id` INT(11) DEFAULT NULL COMMENT '下单用户ID', `room_id` INT(11) DEFAULT NULL COMMENT '预定的客房ID', `check_in_date` DATE DEFAULT NULL COMMENT '入住日期', `check_out_date` DATE DEFAULT NULL COMMENT '退房日期', `total_price` DECIMAL(10,2) DEFAULT NULL COMMENT '总价，按天数乘房价算出', `order_status` INT(1) DEFAULT '0' COMMENT '0待确认 1已确认 2已入住 3已退房 4已取消', `create_time` DATETIME DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8;

注意order_status这个字段的注释，它代表了订单的生命周期。设计这套状态的同学是在把真实业务抽象成数字，答辩时导师看到这张表，十有八九会问"状态之间的流转关系是什么"。你最好能说出来：新订单是待确认，管理员在后台点确认变成已确认，顾客到店后由前台标记已入住，退房后变成已退房，用户自己可以取消还没确认的订单。

total_price字段是冗余设计的典型例子。理论上房价可以由入住天数动态算出，但订单表里冗余存一个总价，查询历史订单时可以少两次 JOIN，也可以避免房价调整后历史订单金额对不上账。这个点你主动讲出来，比被动等老师问要好得多。

3.2 初始化数据：区分"测试数据"和"演示数据"

有些项目的 SQL 脚本里只建了表结构，没有任何数据。你导入之后打开页面，客房列表空空如也。这个时候你就得知道怎么自己往库里塞几条像样的数据，否则演示时没有房型可以展示，场面会很尴尬。

-- 给客房类型表插入两条演示数据 INSERT INTO t_room_type (type_name, price, bed_num, area, remark) VALUES ('标准双床房', 268.00, 2, 28, '适合商务出差，含双早'); INSERT INTO t_room_type (type_name, price, bed_num, area, remark) VALUES ('豪华大床房', 428.00, 1, 40, '大落地窗，配备浴缸');

这里为什么单独建了客房类型表而不是直接把房价写在客房表里？因为同一类房间价格一致，如果每间房都冗余一个 price 字段，改价时需要更新几十条记录；拆成两张表，前台改一次类型表的价格，所有属于该类型的房间自动生效。这个设计思路也是第 4 章写代码时 Controller 里经常要查类型表的原因。

客房表本身是具体房间和类型的关联，一条客房记录必须属于某一个类型，SQL 里表现为room_type_id字段加上外键约束。但在实际的 SSM 查询场景中，我们的操作顺序是反向的：用户在前台选"豪华大床房"→ 系统按类型查出该类型下所有状态为"空闲"的客房 → 展示给用户挑。所以表之间通过type_id关联，Java 实体里再维护一个RoomType对象做 JOIN，这就是 MyBatis 里一对一关联查询的经典场景。

如果脚本里没有测试数据，我建议你至少插入 2~3 个类型、每个类型下 5~10 间客房、2 个测试用户和 1 条已完成订单。这些数据会直接决定你截图答辩时页面的丰满程度。

4. SSM 整合的核心配置与 JSP 页面实现：从配置文件到页面数据的完整链路

4.1 三个配置文件的职责边界，搞懂它们你就能讲清楚架构

SpringMVC 项目里最让人头晕的就是"配置文件到底有几份、谁管谁"。其实就三条线：applicationContext.xml管 Spring 容器，负责 Service、DAO、数据源、事务；spring-mvc.xml管 Controller 和视图解析器；mybatis-config.xml管 MyBatis 的全局设置，比如下划线转驼峰、别名等。

<!-- applicationContext.xml 中的数据源与 SqlSessionFactory 核心配置 --> <bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource"> <property name="driverClassName" value="com.mysql.jdbc.Driver"/> <property name="url" value="jdbc:mysql://localhost:3306/hotel_db?useUnicode=true&amp;characterEncoding=utf8"/> <property name="username" value="root"/> <property name="password" value="${jdbc.password}"/> </bean> <bean id="sqlSessionFactory" class="org.mybatis.spring.SqlSessionFactoryBean"> <property name="dataSource" ref="dataSource"/> <property name="mapperLocations" value="classpath:mapper/*.xml"/> </bean>

url末尾的characterEncoding=utf8不能省，少了它你往数据库里写中文酒店名会变成问号。mapperLocations指向classpath:mapper/*.xml，意思是去resources/mapper目录下找所有 XML，这些 XML 里就是你实际执行的 SQL 语句。这是 MyBatis 区分于 Hibernate 的地方之一：SQL 归 SQL，Java 代码归 Java 代码，两者通过 namespace 和 method id 绑定。

事务配置一般也在这个文件里，常见做法是对 Service 层做方法名匹配的事务增强，比如所有以add、update、delete开头的 Service 方法自动开启事务。毕业设计只要订单保存这个动作涉及多表写操作，就必须有事务，否则用户下单时同时写了订单表和改了客房状态，要是中途崩了，数据就不一致了。

4.2 SpringMVC 的请求流转和 JSP 页面的数据来源

spring-mvc.xml里最关键的两个配置是组件扫描路径和视图解析器的前后缀。

<!-- 扫描 controller 包 --> <context:component-scan base-package="com.hotel.controller"/> <!-- 视图解析器：Controller 返回 "roomList" 时对应 /WEB-INF/jsp/roomList.jsp --> <bean class="org.springframework.web.servlet.view.InternalResourceViewResolver"> <property name="prefix" value="/WEB-INF/jsp/"/> <property name="suffix" value=".jsp"/> </bean>

视图解析器决定了 Controller 返回的字符串和实际 JSP 文件之间的对应关系。很多新手改了 JSP 文件名却忘了改 Controller 里的返回字符串，结果页面 404，报错提示找不着对应的视图。养成习惯：文件改名时全局搜索一下旧名字在哪出现。

JSP 页面里取值是另一套语言。Controller 往Model里塞了一个List<Room>对象，JSP 前端用 JSTL 的c:forEach遍历它。

<%-- 客房列表页 JSP 片段：循环遍历房间数据 --%> <c:forEach var="room" items="${roomList}"> <tr> <td>${room.roomNumber}</td> <td>${room.roomType.typeName}</td> <td>${room.roomType.price}</td> <td> <c:if test="${room.status == 0}"> <a href="${pageContext.request.contextPath}/order/toBook?roomId=${room.id}">立即预订</a> </c:if> <c:if test="${room.status == 1}"> <span>已入住</span> </c:if> </td> </tr> </c:forEach>

${room.roomType.typeName}这行是"对象里套对象"的取数方式：Room 对象里有一个 RoomType 类型的属性，JSP 的 EL 表达式一路点下去就能取到类型名和价格。这个点的前提是 Controller 查房间时做了关联查询，如果没查出来，页面上这列就是空的，问题往往出在 Service 层没有把 RoomType 对象塞进 Room 里，而不是页面写错了。

pageContext.request.contextPath是另一个值得讲给老师的细节。它动态获取当前应用的前缀路径，保证即使部署时的路径改了，链接也不会断。有些同学直接把链接写死成/hotel/order/toBook，项目改个名字整个网站链接全废。这个细节毕业答辩时提一嘴，老师会认为你理解 Web 应用的部署机制。

4.3 订单提交的业务逻辑：插入订单和修改房间状态为什么必须在同一个事务里

看完整套代码后你会发现，酒店预定的核心动线就一条：用户选中一间空闲客房 → 填写入住离店日期 → 系统算总价 → 生成订单。其中最容易写错的是最后一步。正确流程是同时完成两件事：往t_order插入一条新订单，把t_room里对应客房的status从"空闲"改成"已预定"。这两步缺一不可，而且必须打包成同一个事务方法。

@Transactional public boolean createOrder(Order order) { // 第一步：插入订单记录 int orderResult = orderMapper.insert(order); if (orderResult == 0) { return false; } // 第二步：把客房状态改为不可预订 int roomResult = roomMapper.updateStatus(order.getRoomId(), 1); return roomResult > 0; }

这段代码的关键不是逻辑有多复杂，而是@Transactional那个注解。没有它，插入订单成功了、房间状态却没改掉，客房被双重预定了都不知道。有了它，第二步报了异常，第一步插入的订单也会自动回滚，数据库不会出现脏数据。

答辩时如果被问到"为什么预订不需要锁机制"，你可以把这个话题接住：当前设计是先查房间状态为空闲，再插入订单、改状态。两个人同时订同一间房，后提交的人看到的房间状态还是空闲的，因为第一步查询发生在改状态之前，这就产生了超卖风险。优化方案是在查询空闲房间的 SQL 里加for update行锁，或者干脆改状态时用update ... where status = 0做乐观锁判断。这个点你讲出来，属于超纲加分项，但前提是你确实理解了并过了测试，不然老师追问底层细节时反而露怯。

5. 跑通项目避坑：从解压到能下单，最常翻车的五个地方

5.1 启动 Tomcat 时端口被占用，和 Zookeeper 无关，但和很多东西有关

现象：IDEA 里 Tomcat 启动日志打到一半突然停了，报错信息里有Port 8080 was already in use。

原因：要么你有另一个 Tomcat 在跑，要么是某个开发工具占用了 8080。最常见的是你之前启动过同一个项目没关干净，残留了一个 Java 进程。IDEA 的 Tomcat 面板显示"已停止"，但实际进程没死。

解决：在 Windows 上打开命令行，查到占用 8080 的进程号，直接结束：

netstat -ano | findstr 8080 # 假设查到 PID 为 12345，然后结束该进程 taskkill /PID 12345 /F

如果还不行，换一个端口，修改 Tomcat 配置里port改为 8081 或 8082，同时检查项目的jdbc.properties里数据库端口是否写的是 3306。这个错基本是环境问题，和项目代码无关，但很多同学在这卡了半小时，其实一条命令就解决。

5.2 MySQL 8.0 连接报时区错误，代码没写错，是驱动版本的问题

现象：Tomcat 启动时控制台出现完整的 Java 异常栈，关键句是The server time zone value '???ú±ê׼ʱ¼ä' is unrecognized，页面完全打不开。

原因：MySQL 8.0 的连接驱动对时区要求很严格，而项目如果用的还是 5.x 时代的连接方式，连接串又没有serverTimezone参数，数据库就会告警甚至拒绝连接。中文乱码样的报错是时区名称在终端里编码显示问题。

解决：两件事一起做，一个改依赖，一个改连接串：

<dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>8.0.27</version> </dependency>

jdbc.url=jdbc:mysql://localhost:3306/hotel_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai

改完这两个地方，重新 clean 再启动。注意useSSL=false也建议加上，否则驱动版本新的时候会有一行 SSL 连接警告，虽然不是致命错误，但控制台里一大片警告信息容易掩盖真正的问题。

改了版本之后如果报驱动类找不到com.mysql.jdbc.Driver，换成com.mysql.cj.jdbc.Driver。新版驱动改了类名，旧配置不兼容。这种问题体现出来的教训是：SSM 项目常年在老版本生态里跑，轻易升级 MySQL 版本就是给自己制造工作量。

5.3 JSP 页面中文乱码，表和页面各有一处要查

现象：页面上的酒店标题和用户昵称变成æ ‡å这样的乱码，或者干脆全是问号。

原因：三层乱码的可能。第一层是数据库连接串没带字符集参数，这一点配置时最容易踩，我见过某同学的连接串里characterEncoding拼错了，导致写入时表里直接存了乱码，这种最惨，得把已经存的数据删了重插；第二层是 JSP 页面头部没声明编码，第三层是 Tomcat 的 POST 请求参数默认用 ISO-8859-1 解析，中文参数传进来就乱了。

解决：先查表里数据是否正常。如果表里本来就没存对，改完连接串之后把乱码记录删掉重新插入；如果表里没问题、页面显示乱码，去 JSP 文件开头检查有没有这一段：

<%@ page contentType="text/html;charset=UTF-8" language="java" %>

这是 JSP 页面的一切前提。然后检查项目的web.xml里有没有配置 SpringMVC 的 CharacterEncodingFilter：

<filter> <filter-name>encodingFilter</filter-name> <filter-class>org.springframework.web.filter.CharacterEncodingFilter</filter-class> <init-param> <param-name>encoding</param-name> <param-value>UTF-8</param-value> </init-param> </filter>

这个过滤器必须在所有过滤器前面，因为它的作用是提前把请求和响应的编码统一成 UTF-8。如果项目里没配这一段，前端表单里填中文用户名的功能一定是乱的。三层检查顺序按我说的来，乱码问题十分钟内能定位。

5.4 MyBatis 报 BindingException：mapper 接口和 XML 没有对上号

现象：启动时不报错，但点预订按钮后页面 500，后台异常Invalid bound statement (not found): com.hotel.dao.RoomDao.findRoomsByType。

原因：MyBatis 的 DAO 接口和resources/mapper目录下的 XML 文件，靠的是"同名同路径"的关系绑定。接口全限定名是com.hotel.dao.RoomDao，XML 的 namespace 就必须是com.hotel.dao.RoomDao，方法名必须和<select>标签的 id 一一对应。最常见的导致绑定失败的原因是 XML 文件放错了地方，比如放进了java源码目录而不是resources目录，Maven 打包时就没把它复制到 classes 里。

解决：检查target/classes/mapper下有没有对应的 mapper XML 文件。如果没有，把 mapper 文件移到src/main/resources/mapper目录下，再确认applicationContext.xml里mapperLocations的路径和它一致。还要注意一个问题：IDEA 里有时把.xml文件放进了java包目录下，虽然项目源码结构看起来正常，但 Maven 默认只把resources目录下的 XML 当资源文件处理。此时需要手动在pom.xml的 build 里声明把src/main/java下的 XML 也打包进去，或者更简单，直接按 Maven 规范放文件，不搞特例。

5.5 页面 404 且 Tomcat 部署名不一致，链接全部失效

现象：Tomcat 能启动，MySQL 连接正常，但浏览器打开首页直接 404，F12 里看到请求路径是/hotel_war_exploded/...。

原因：这是 IDEA 部署 Web 项目时最常见的样子。IDEA 给项目起的 context path 是hotel_war_exploded，就是你在浏览器地址栏里看到的那一截。而源码里前端链接可能写的是/hotel/...，两者对不上，自然全站 404。

解决：在 IDEA 的 Run Configuration 里找到 Deployment 页签，把 Application context 改成/hotel，或者改成/直接部署到根路径。改完之后重启 Tomcat。如果你改了 context path 还是打不开首页，去webapp目录下看入口页面的命名，SSM 项目的欢迎页一般在WEB-INF/目录里，通过 Controller 的@RequestMapping("/")方法进入，而不是直接放一个index.html。

这个问题的根因是 IDE 的部署机制而非项目代码，所以换一台电脑、换个 IDE 版本，context path 可能就变了。理解这里的原理之后你就明白，为什么所有 JSP 里的超链接都应该用${pageContext.request.contextPath}拼接，而不是写死路径——就是不希望部署路径变化的时候全站链接失灵。

5.6 明明按步骤走了还是跑不起来，试试这几条排查思路

前面五条是按现象分类的，但你仍然可能遇到没列出来的问题。我建议按下面三步做最基础的排查。

第一步看日志。Tomcat 的本地控制台日志是最直接的信息源，把异常栈滚动到最后一段Caused by处，那通常才是真正的根因。好多人看报错只看第一行类名，不看最底下的原因，方向就完全错了。

第二步看配置文件。SSM 报错中有很大比例是配置问题而不是代码问题，比如数据源密码写错、mapperLocations 路径写错、包扫描路径写错、注解没加。每个配置文件逐行确认，尤其注意classpath:前缀和包名有没有写错一个字母。

第三步回到最小验证。JDK 配好了吗？Maven 依赖下载完整吗？数据库的表导入了吗？把依赖、数据库、部署三件事从大到小逐项验证一遍，任何一步失败都有明确的报错信息。这三步走完，90% 的启动问题都能定位到具体环节。

6. 最后一步：跑通只是开始，把业务闭环走一遍，答辩才有底气

系统能启动、能登录，这只是起点。真正的验收标准是：你能顺着一条完整的业务链路走到底，并且每一步都知道数据流到哪里去了。我建议你按下面这条路径完整测一遍，每个环节拍照或截图存档：管理员登录后台添加一个"豪华大床房"类型，再给这个类型下挂三个具体房间；前台用户注册一个新账号；用这个账号在前台页面看到刚才新增的房型；选一间房提交订单；管理员在订单列表里看到"待确认"订单并点确认；前台用户的订单状态从"待确认"变成"已确认"。这一圈走完，系统的核心功能就闭环了，你演示时按这个顺序操作，导师顺着你的步骤就能理解整套系统。

测试过程中留意两个容易出彩的细节。第一是在地图上看日期跨度的计算：假设入住 6 月 1 日、退房 6 月 3 日，订单总价应该按 2 晚算，很多新手在这个地方会按日期差 +1 算出 3 晚，多收顾客钱。你自己动手的时候，故意下一单跨两天的订单，算一下总价对不对，这个细节会成为演示亮点。第二是取消订单和入住登记这两条扩展流：不在核心链路里的功能页，也要点开看看接口有没有报错，这是你花了钱和时间的项目，不是别人帮你写的脚本，每个按钮背后的逻辑你都应该能解释。

如果你还有富余时间，我推荐做一个小升级：把原本的普通密码登录改成 MD5 加密存储，或者给订单查询加一个分页展示。这两个改动各有各的难度，前一个涉及登录验证逻辑和数据库已有数据的迁移，后一个涉及 MyBatis 分页插件引入和前端页码条生成，分量刚好够写进论文的"系统优化"章节，又不至于大改架构。我在帮同学梳简历时反复强调过一句话：答辩得到的分数和代码量几乎没有关系，和你能讲清楚自己做的东西是什么、为什么这么做、出问题时怎么排查的关系最紧密。这套源码是别人写好的，但经过今天这一轮环境搭建、配置梳理、业务走查，你已经对它的每个环节有了真切的感知。

还有一个容易被忽视的小事：如果你打算在论文里放页面截图，记得先把 Tomcat 部署路径里的_war_exploded去掉、把地址栏 URL 整理成干净的格式，页面上的示例数据也换成合理的中文内容。这些细节会给答辩老师一个直观的"It is a real project"的信号。

我自己的习惯是，拿到任何一套现成的参考系统，第一遍跑通之后，一定要自己动手改一处小功能再跑一遍，比如把列表每页显示条数从 10 改成 5。这个过程会暴露很多你以为理解了、实际没理解的依赖关系。毕业设计的价值，恰恰在这份动手思考的经验上，而不是对应的那几行代码。希望这些踩过的坑和思路能帮你少走弯路，快的话，今晚就能看到自己的项目跑起来。

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