每年三四月份，计算机毕设群里的日常就是同一个问题来回刷：SSM和Spring Boot到底选哪个做管理系统？我自己做完这个SSM框架的教务管理系统之后，答案反而很明确——如果目标是让答辩老师愿意听你把框架一层层讲明白，SSM才是更能拿分的选择。这一点不展开说，等你被追问"你这个项目的事务在哪个类上生效、拦截器为什么能拦住请求"的时候，就会懂我这句话的意思。这篇博文就围绕"Java教务管理系统 + SSM框架"这条技术线，把技术选型、数据库设计、权限控制、核心业务逻辑、联调排障、部署答辩这整条链路完整复盘一遍。适合正在做同类毕设、或者想用SSM练手Web开发的同学。
1. 毕设选型复盘：教务系统用SSM框架还是Spring Boot
1.1 教务系统这个选题到底在考察什么
教务管理系统几乎是管理系统类毕设里最经典的一类选题，它和图书馆管理、停车管理系统站在同一个梯队：功能边界清楚、角色分明、数据关联性强。一个合格的教务系统至少要覆盖三类用户——管理员、教师、学生，对应三种完全不同的操作权限。这意味着你写的不只是"增删改查"，而是一套有权限区分、有业务流程、有数据状态流转的业务系统。
教务系统特别适合SSM框架，一个重要原因是它天然要处理多表关联：学生属于班级、班级属于专业、专业属于学院；课程要关联教师、选课要关联学生和课程、成绩要关联选课记录。这种密集的关联关系，正好把MyBatis动态SQL、ResultMap映射、嵌套查询这些硬核知识点全部暴露出来。你要是用Spring Boot的话，很多东西被自动配置遮住了，反而不容易讲出深度。
1.2 SSM和Spring Boot在毕设评分中的实际差别
很多同学有一个误区：觉得Spring Boot是升级版，用Boot做项目显得技术新、评分高。实际情况是，本科毕业设计考察的不是技术新不新，而是你对所用技术有没有真正理解。Spring Boot的自动配置机制对你来说是个黑盒，答辩的时候老师问你"内嵌Tomcat是怎么启动的""ConditionalOnMissingBean是怎么回事"，大部分用Boot做毕设的同学答不上来。
而SSM框架的代码是显式可见的：Spring容器在web.xml里通过监听器启动、DispatcherServlet在web.xml里显式配置、MyBatis的SqlSessionFactoryBean在XML里显式装配。每一个环节你都能指着配置讲出原理，这种"能讲原理"的状态，在答辩时比"用了Boot自动配置"值钱得多。
来看一张实操层面的对比：
| 对比维度 | SSM框架 | Spring Boot |
|---|---|---|
| 配置方式 | web.xml + Spring XML + 注解混合 | application.yml全局配置 |
| 启动方式 | 部署到Tomcat的war包 | 内嵌Tomcat直接跑jar |
| 依赖管理 | 手动维护Spring版本兼容 | 父级starter统一管理 |
| 答辩深度 | 每个组件都要自己装配，原理天然要懂 | 自动配置屏蔽细节，容易被问住 |
| 代码量 | 配置代码多，但都在可控范围 | 配置少，但业务代码量差不多 |
| 上手难度 | 前期环境搭建需要多点耐心 | 初始化快，但理解不深 |
我自己最终选了SSM，还有一个现实原因：人懒。MyBatis的SQL完全自己掌控，查询过程出了性能问题，一眼就能在XML里定位。而JPA那种自动生成的SQL一旦慢查询，排查起来反而不直观。
1.3 一个合格版本的工作量边界
做毕设最忌两件事：功能太少拿不出手、功能太多收不住尾。教务系统合理的边界应该是：管理员端管用户、管课程、管公告、管成绩审核；教师端管自己的课程和成绩录入；学生端选课、查课表、查成绩。在此基础上，把"分页查询""条件检索""批量操作""文件导出"这些加分项加上去，就完全够用了。
技术版本方面，我的组合是Spring 5.3.x + Spring MVC 5.3.x + MyBatis 3.5.x + MySQL 5.7 + Tomcat 8.5 + Maven。数据库表15张左右，Java类和Mapper各20来个，总共大概八千行代码。这个规模，一个人一个月左右完成是合理的，不至于让自己毕设月连续熬夜。
2. 先画表再写代码：教务系统的核心数据模型与建表SQL
2.1 角色统一还是角色分表：一个必须想清楚的决策
教务系统的第一张表，不是学生表，而是账号表。常见的错误做法是给管理员、教师、学生各建一张登录表，三张表字段几乎一样，登录的时候还得先判断"你属于哪类人"再去对应表里查询。这个设计在答辩时很容易被老师一票否决：扩展性太差，以后想加一个"辅导员"角色，难道再复制一张表？
正确做法是所有的登录账号统一放在一张sys_user表里，用role字段区分身份，然后通过user_id关联各自的详细信息表。这样的好处非常直接：
- 登录验证只需要查一张表，不需要判断角色类型再选表
- Session里统一存用户信息，JSP页面直接通过
user_id或role渲染不同菜单 - 后续加角色（班级助理、教务处干事）只需要加一个role值，不需要动表结构
这也是教务系统和其他小管理系统的区别：业务角色多、权限层级复杂，数据模型必须按角色抽象，不能图省事。
2.2 五张核心表的建表SQL与设计思路
从建表顺序看，先有学院、专业、班级这些基础维度，才有学生；先有教师，才有课程；先有课程和学生，才有选课记录；先有选课记录，才有成绩。我把最核心的五张表和关键字段列出来，这份SQL是直接照着能跑的。
-- 1. 账号表 CREATE TABLE sys_user ( id INT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE COMMENT '登录名', password VARCHAR(64) NOT NULL COMMENT 'MD5加盐后的密码', role TINYINT NOT NULL COMMENT '1管理员 2教师 3学生', status TINYINT DEFAULT 1 COMMENT '0禁用 1正常', create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='账号表'; -- 2. 学生信息表，关联sys_user并补充业务信息 CREATE TABLE student ( id INT PRIMARY KEY AUTO_INCREMENT, user_id INT NOT NULL UNIQUE COMMENT '关联sys_user.id', student_no VARCHAR(20) NOT NULL UNIQUE COMMENT '学号', student_name VARCHAR(50) NOT NULL, gender TINYINT COMMENT '0男 1女', class_id INT NOT NULL COMMENT '关联班级表', phone VARCHAR(20), email VARCHAR(100) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='学生信息表'; -- 3. 课程表，一个教师可以带多门课 CREATE TABLE course ( id INT PRIMARY KEY AUTO_INCREMENT, course_code VARCHAR(20) NOT NULL UNIQUE COMMENT '课程编号', course_name VARCHAR(50) NOT NULL, credit DECIMAL(3,1) COMMENT '学分', teacher_id INT COMMENT '关联教师id', max_student INT DEFAULT 50 COMMENT '选课容量', selected_count INT DEFAULT 0 COMMENT '当前已选人数', semester VARCHAR(20) COMMENT '学期，例如2025-2026-1' ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='课程表'; -- 4. 选课记录表，联合唯一约束防止重复选课 CREATE TABLE course_selection ( id INT PRIMARY KEY AUTO_INCREMENT, course_id INT NOT NULL, student_id INT NOT NULL, select_time DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_course_student (course_id, student_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='选课记录表'; -- 5. 成绩表，通过selection_id关联到选课记录，保证一门课只有一个成绩 CREATE TABLE grade ( id INT PRIMARY KEY AUTO_INCREMENT, selection_id INT NOT NULL UNIQUE, score DECIMAL(5,2) COMMENT '成绩', status TINYINT DEFAULT 0 COMMENT '0未录入 1已保存 2已提交 3已审核' ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='成绩表';有几个设计点必须说清楚，因为这是答辩时的高频提问。
第一，student.user_id为什么加UNIQUE？因为业务上一个学生账号最多对应一条学生信息，这条约束从数据库层面防止重复建档。
第二，course表里的selected_count其实属于冗余字段，因为完全可以通过course_selection表count出来。但选课时如果每次先count再判断容量，并发情况下很容易超选。保留这个字段，是为了配合"乐观锁式"的扣减语句完成防超选控制。这个在第4章会详细展开。
第三，grade表不直接存course_id和student_id，而是存selection_id。这样做的好处是成绩和选课记录一对一绑定，你不可能出现"一个学生同一门课有两条成绩"的脏数据。这个表结构设计是别人问起来最亮眼的点。
2.3 MyBatis的ResultMap映射注意点
教务系统查列表很少只查单表，比如"学生列表"要同时显示班级名和专业名，就要把student和clazz、major关联。这种场景用ResultMap比用SELECT *更规范。
<resultMap id="StudentVO" type="com.example.entity.Student"> <id property="id" column="id"/> <result property="userName" column="username"/> <result property="studentNo" column="student_no"/> <result property="studentName" column="student_name"/> <association property="clazz" javaType="com.example.entity.Clazz"> <id property="id" column="class_id"/> <result property="className" column="class_name"/> </association> </resultMap>这里最容易翻车的问题是：多表关联查询时，两表有同名列（比如clazz.id和student.id都是id），MyBatis会用后查到的列覆盖先查到的列。解决方法是SQL里给列起别名，比如SELECT stu.id AS stu_id, cla.id AS cla_id，从根源上避免列名冲突。这个小细节，很多调试了半天"为什么对象是null"的同学最后才发现是这里出了问题。
3. 登录权限这部分：拦截器、角色路由与AJAX超时处理
3.1 登录流程为什么不能用纯JSP判断
初学者写登录，最容易写成"登录成功后在JSP里判断角色，然后用response.sendRedirect跳不同首页"。这个做法能用，但有一个致命问题：如果用户不通过登录页面，直接输入某个后端URL，照样能访问接口拿到数据。因为JSP跳转只是前端跳转，后端没有任何一道防护。
正规做法是把校验统一放在Spring MVC的拦截器里。拦截器在Controller执行之前拦截请求，先查Session里有没有登录用户，没有就直接重定向到登录页。这才是权限控制应该存在的层级。
登录Controller的逻辑本身不复杂，但有几个细节要做到位：
@Controller public class LoginController { @Autowired private UserService userService; @PostMapping("/login") public String login(String username, String password, HttpSession session, Model model) { String md5Pwd = MD5Util.md5(password + MD5Util.SALT); User user = userService.login(username, md5Pwd); if (user == null) { model.addAttribute("error", "用户名或密码错误"); return "login"; } if (user.getStatus() == 0) { model.addAttribute("error", "账号已禁用，请联系管理员"); return "login"; } // 登录成功，把用户对象放入Session，后续所有页面都从这里取 session.setAttribute("loginUser", user); return "redirect:/index"; } @GetMapping("/logout") public String logout(HttpSession session) { session.invalidate(); return "redirect:/login"; } }密码为什么要加盐MD5而不是明文？因为数据库一旦泄露，明文密码就是灾难。加盐后再MD5，至少能挡住"字典攻击"里最常见的那批弱口令。严格来说现在生产环境应该上BCrypt，但毕设场景用加盐MD5已经可以交代清楚你的安全意识，前提是你要能讲明白"为什么不能只做一次简单MD5"。
3.2 拦截器配置：排除静态资源和登录接口
拦截器写起来简单，配置上容易踩坑的地方是"排除路径"。如果你的登录页面里用了CSS、JS、图片，而这些静态资源也走/**拦截范围，就会陷入"样式加载不出来，以为什么都是自己的问题"的坑。
Spring MVC拦截器配置XML里，用exclude-mapping把登录接口、静态资源、错误页面全部排除掉：
<mvc:interceptors> <mvc:interceptor> <mvc:mapping path="/**"/> <mvc:exclude-mapping path="/login"/> <mvc:exclude-mapping path="/logout"/> <mvc:exclude-mapping path="/static/**"/> <mvc:exclude-mapping path="/error"/> <bean class="com.example.interceptor.LoginInterceptor"/> </mvc:interceptor> </mvc:interceptors>拦截器本身的preHandle写法：
public class LoginInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { HttpSession session = request.getSession(); User loginUser = (User) session.getAttribute("loginUser"); if (loginUser == null) { // 判断是不是AJAX请求：是则返回401状态码，不是则重定向 String requestedWith = request.getHeader("X-Requested-With"); if ("XMLHttpRequest".equals(requestedWith)) { response.setStatus(401); return false; } response.sendRedirect(request.getContextPath() + "/login"); return false; } return true; } }这里有个非常实战的细节：AJAX请求和普通页面跳转的处理方式必须分开。如果你Session过期了，页面里的$.ajax()拿到的是一个重定向后的HTML登录页，前端解析JSON必然报错。所以让后端针对AJAX请求直接返回401状态码，前端统一在error回调里做"跳转登录页"的处理，体验会好很多。
3.3 角色可控的前端菜单渲染
权限控制不只是后端拦截，前端菜单也要按角色显示，否则学生登录后看到一堆管理功能，虽然点了会报错，但体验极差。
最省事的做法是用JSTL的c:if判断Session里的角色，JSP页面按角色隐藏菜单：
<c:if test="${sessionScope.loginUser.role == 1}"> <li><a href="${ctx}/admin/user/list">用户管理</a></li> <li><a href="${ctx}/admin/grade/audit">成绩审核</a></li> </c:if> <c:if test="${sessionScope.loginUser.role == 2}"> <li><a href="${ctx}/teacher/course/list">我教的课程</a></li> <li><a href="${ctx}/teacher/grade/input">成绩录入</a></li> </c:if> <c:if test="${sessionScope.loginUser.role == 3}"> <li><a href="${ctx}/student/course/select">选课中心</a></li> <li><a href="${ctx}/student/grade/list">我的成绩</a></li> </c:if>注意${ctx}是pageContext.request.contextPath的简写，建议在页面顶部用<c:set>一次性设置。所有超链接都用它拼路径，能避免大量"相对路径在二级页面失效"的问题。
后端侧还要配合一个BaseController，把当前登录用户和当前用户ID封装成公共方法，避免每个Controller里去Session里现取：
public class BaseController { @Autowired protected HttpSession session; protected User getLoginUser() { return (User) session.getAttribute("loginUser"); } protected Integer getLoginUserId() { return getLoginUser().getId(); } }这样业务Controller继承BaseController，取用户ID只调一个方法，代码立刻清爽很多。
4. 业务核心实现逻辑：选课防超选、成绩审核链路与分页查询
4.1 学生管理模块：分页和动态SQL的组合
学生管理页是教务系统里最典型的列表页，涉及条件查询（按姓名、学号、班级）、分页、批量删除三个基本能力。技术落地点是PageHelper分页插件和MyBatis动态SQL的配合。
Controller层写法没有玄机，重点在于Service层的调用顺序：
public PageInfo<StudentVO> queryStudentPage(int pageNum, int pageSize, StudentQuery query) { // 这一行必须紧跟着要分页的那条查询，中间不能穿插任何其它数据库操作 PageHelper.startPage(pageNum, pageSize); List<StudentVO> list = studentMapper.selectStudentList(query); return new PageInfo<>(list); }PageHelper.startPage()的原理是基于ThreadLocal的，它会把分页参数绑定到当前线程，然后拦截下一次查询。一旦你在startPage之后做了别的查询，分页参数就可能被错误地应用，出现"结果集对不上"这种诡异问题。我的习惯是：在Service里用startPage之后立即调用mapper查询，中间连日志输出这种无关代码都不放。
Mapper的XML动态SQL部分，比JPA那种模板化的where 1=1要灵活得多：
<select id="selectStudentList" resultMap="StudentVO"> SELECT stu.id, stu.student_no, stu.student_name, stu.gender, cla.class_name, maj.major_name FROM student stu LEFT JOIN clazz cla ON stu.class_id = cla.id LEFT JOIN major maj ON cla.major_id = maj.id <where> <if test="studentName != null and studentName != ''"> AND stu.student_name LIKE CONCAT('%', #{studentName}, '%') </if> <if test="studentNo != null and studentNo != ''"> AND stu.student_no = #{studentNo} </if> <if test="classId != null"> AND stu.class_id = #{classId} </if> </where> ORDER BY stu.id DESC </select><where>标签会自动处理"去掉开头的AND/OR"的逻辑，不用你手动写where 1=1以及纠结第一个条件要不要带AND，干净得多。
4.2 选课模块：如何防超选
选课是教务系统里最值得展开讲的服务，因为它是唯一一个"并发安全性"能写进答辩提纲的点。核心需求很简单：课程有容量上限（max_student），同时有很多学生选课时，不能让选课人数超过容量。
如果按"先查已选人数、判断未满、再插入记录"的方式，就会出现经典的"丢失更新"问题：两个请求同时读到剩余名额为1，同时判断可以选，最后都插入成功，实际超了1人。MySQL默认隔离级别下的这种场景，靠代码层面加锁很麻烦，最可靠的做法是让数据库自己完成原子判断。
关键SQL写成一条UPDATE语句，同时扣减名额并校验上限：
UPDATE course SET selected_count = selected_count + 1 WHERE id = #{courseId} AND selected_count < max_student这条语句的含义是：只有当当前已选人数小于容量时才加一，否则影响行数为0。利用"UPDATE的操作是行级锁、天然原子性"这一点，在高并发场景下直接把"判断"和"扣减"合并成一步。
Service层代码：
@Transactional(rollbackFor = Exception.class) public boolean selectCourse(Integer courseId, Integer studentId) { // 第一步：原子扣减，返回0表示容量已满或课程不存在 int updated = courseMapper.increaseSelectedCount(courseId); if (updated == 0) { return false; } // 第二步：插入选课记录，重复选课会被数据库唯一索引挡住 try { courseSelectionMapper.insert(courseId, studentId); } catch (DuplicateKeyException e) { // 这里要把第一步扣减回滚掉才能保持数据一致 throw new RuntimeException("不能重复选课", e); } return true; }注意这段代码一个容易被忽视的点：第一步扣减成功之后，如果插入选课记录失败（比如重复选课触发唯一索引），整个事务必须回滚，把扣减撤销掉。所以在Service方法上加@Transactional并指定rollbackFor = Exception.class，同时不要自己吞掉DuplicateKeyException，要让它抛出才能触发回滚。这是典型的"事务一致性"案例，直接对应答辩问题：事务在什么场景下使用？
查询学生已选课程和剩余可选课程时，还要注意：课程列表是LEFT JOIN选课表，判断当前学生是否已选，需要在SQL里做"是否选了这门课"的标记字段，具体实现用CASE WHEN：
SELECT c.id, c.course_name, c.credit, c.max_student, c.selected_count, CASE WHEN cs.id IS NULL THEN 0 ELSE 1 END AS is_selected FROM course c LEFT JOIN course_selection cs ON c.id = cs.course_id AND cs.student_id = #{studentId} WHERE c.semester = #{semester}这条SQL的WHERE cs.student_id加在了关联条件里，而不是WHERE条件里，非常关键。如果写在外面过滤，会得到"没选过的课程都不见了"的结果，这又是一道易错题。
4.3 成绩模块：状态机设计比你想的更重要
成绩表面上看就是一个score字段，但教务业务里成绩要经过三道关：教师临时保存、教师提交、管理员审核。审核通过之前，学生不应该在系统里看到成绩。所以我在grade表设计了status字段：0未录入、1已保存、2已提交、3已审核。
教师端成绩录入页面加载该班级的学生列表，教师录入分数后点"保存"是status=1，点"提交"是status=2。提交之后教师自己也不能随便改，必须走管理员退回逻辑。管理员端成绩审核页面只展示status=2的数据，审核通过变3，不通过退回变1。
这个设计的好处是：业务流程和表结构高度对应，每个状态对应一个页面入口或者一个操作按钮，答辩时在黑板上画状态流转图讲三四分钟毫无压力。
学生端查询成绩则只查"已审核"状态：
<select id="selectStudentGrade" resultMap="GradeVO"> SELECT g.score, g.status, c.course_name, c.credit, t.teacher_name FROM grade g JOIN course_selection cs ON g.selection_id = cs.id JOIN course c ON cs.course_id = c.id LEFT JOIN teacher t ON c.teacher_id = t.id WHERE cs.student_id = #{studentId} AND g.status = 3 ORDER BY c.id DESC </select>注意这个查询把成绩的"可见性"放到了SQL层，而不是在页面层用<c:if>判断status再显示。数据访问层直接屏蔽不可见数据，比自己过滤更安全、也更容易理解。
5. 联调阶段排错实录：事务失效、JSON日期乱掉、PageHelper分页诡异
5.1 事务不生效：表面上是加了注解，实际上回调都没进
SSM应用里最常见的事务事故，就是@Transactional加了跟没加一样。我复盘自己遇到过的场景，可以把原因归纳成四类，这几类都值得你提前检查：
第一，注解加错了层。有人把@Transactional加在Controller方法上，Spring的事务拦截器是按AOP代理配置的，默认只对Service层生效，Controller上加了其实是不被处理的。正确位置是Service实现类或实现类的方法上。
第二，方法不是public。Spring事务是CGLIB代理实现的，代理只有在接口方法或public方法上才生效。如果你在Service实现类里写了一个private方法并加注解，事务不会启动。
第三，异常被吞掉。这是一个隐蔽的坑：
@Override @Transactional public void updatePassword(Integer userId, String newPwd) { try { userMapper.updatePassword(userId, newPwd); throw new RuntimeException("测试回滚"); } catch (Exception e) { log.error("更新失败", e); } }代码执行完后事务照样提交了，因为异常被catch住，Spring根本感知不到。rollbackFor = Exception.class匹配的是"从方法抛出去"的异常，你在方法里把异常处理掉了，事务自然认为是"正常完成"。排查这类问题的方法很简单：在方法里手动throw new RuntimeException()，看数据回不回滚；不回滚就说明要么代理失效、要么异常没抛出去。
第四，数据库表用了MyISAM引擎。MyISAM不支持事务，你注解写得再标准也没用。建表SQL里显式写明ENGINE=InnoDB是最稳妥的习惯。
5.2 JSON日期要么是时间戳、要么差8小时
前后端交互时最常见的显示问题：后端返回的java.util.Date字段在前端变成一串数字，或者显示的日期和时间差了8个小时。前者是因为默认序列化时把Date变成了时间戳；后者是因为时区没有设置成GMT+8。
解决办法是在POJO的时间字段上加注解，并且timezone不要漏：
@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss", timezone = "GMT+8") private Date createTime;如果你全项目很多地方都用日期字段，逐个注解太累，也可以在SpringMVC配置文件里，给ObjectMapper做一个全局的日期格式设置。两种方式选一种即可，我建议项目初期就全局配置，避免后来忘了加注解导致接口输出不一致。
另一个容易忽略的方向是"接收前端传来的时间字符串"。当前端传2025-03-10这种格式，而后端Controller用@RequestParam("birthday") Date birthday接收时，SpringMVC默认解析不了这种格式，会抛400。解决方式是在对应字段上加@DateTimeFormat(pattern = "yyyy-MM-dd")，两个注解一个管出、一个管进，很容易混淆，写的时候注意。
5.3 PageHelper分页错乱：startPage到底该放在哪
PageHelper分页错乱分两类：一类是"第一页显示第二页的数据"，一类是"总条数永远对不上"。产生原因都有一个共同点：startPage()之后、真正要分页的查询之前，中间有其他SQL被执行了。
我接手过一个项目，同学在PageInfo里除了列表还查了一个统计总数，他以为先查列表再查总数没关系，结果是总数查询被PageHelper当成了分页对象，列表反而只返回一条。从代码上看就是顺序问题。强制约束自己：startPage之后的下一行必须是目标查询，中间不要插入其他判断、日志、或者服务调用。
另外一个PG不爱提的点：PageHelper配合LEFT JOIN做关联查询过滤时，如果关联产生一对多的结果集（比如一个订单对应多个商品），分页是按"查询结果行数"来算的，不是按"主表记录数"来算的。在教务系统里，学生和班级是一对多，一个学生的列表不会重复，所以这个问题不明显。但如果你以后做订单系统就要小心，这种场景需要另开一套基于主键ID的子查询分页方案。
5.4 IDEA编译报OutOfMemoryError
SSM项目在IDEA里编译经常遇到一个问题：java.lang.OutOfMemoryError: Java heap space，表现是不管怎么重启IDEA都报错，而且错误信息出现在Maven或编译器的任务窗口。
这类问题90%和项目代码无关，是IDEA编译器自身分配的堆内存太小。处理的入口有两个：Settings里的Build Tools -> Maven -> Runner，把VM Options填成-Xmx1024m；再在Help -> Change Memory Settings里调高IDE的堆内存，一般设2048MB就够了。改完记得重启IDEA再编译，如果还是报错，再确认一下项目里是否引入了互相冲突的依赖导致反复重编译。
还有一个看起来无关、实际很坑的点：Maven编译时控制台报"java: 找不到符号"并且指向的是自己在别的模块里定义的类。这种情况不要急着改代码，先执行一遍mvn clean，很多时候是本地缓存编译到了旧class导致的。
5.5 AJAX请求提交JSON，但Controller收不到参数
前端.ajax把contentType设置成了application/json，请求体是{"studentName":"张三"}，而后端Controller用普通的@RequestParam String studentName接收，结果是null。原因不复杂：application/json格式的请求体必须用@RequestBody解析。
要么前端不设置application/json，用表单默认的application/x-www-form-urlencoded提交，后端就能用@RequestParam；要么后端改成下面这种写法：
@PostMapping("/student/query") @ResponseBody public Object query(@RequestBody StudentQuery query) { return service.doQuery(query); }这两种方式对应不同的"提交协议"，只要两边保持一致就不会出问题。我自己的习惯是：后端接口一律用@RequestBody接收JSON，因为前端可以少拼很多查询参数，数据量大一点的时候也不会因为URL长度超限被服务端拒绝。
6. 答辩部署复盘：打包war、初始化脚本与演示顺序建议
6.1 Maven打包war部署到Tomcat的完整流程
SSM项目默认打war包，部署到独立Tomcat。踩过几个坑，这里直接给终版操作：
pom.xml里的几个关键配置，一是打包方式必须是war，二是最终包名最好固定，方便Tomcat里访问的URL路径不随机变化：
<packaging>war</packaging> <build> <finalName>course-manage</finalName> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-war-plugin</artifactId> <configuration> <failOnMissingWebXml>false</failOnMissingWebXml> </configuration> </plugin> </plugins> </build>打包命令用mvn clean package，打好之后把target/course-manage.war复制到Tomcat的webapps目录下，启动Tomcat后，war包会自动解压，访问地址就是http://localhost:8080/course-manage/。
有个部署常见的坑：Tomcat启动后页面正常，但一打开就报404。先确认你的SpringMVC配置里DispatcherServlet映射的url-pattern，如果你用/而项目访问路径是/course-manage/，Controller里的@RequestMapping("/login")实际访问地址是/course-manage/login，不能少了项目名。也可以在Tomcat的server.xml里配置Context path=""，这样访问就变成根路径http://localhost:8080/login，演示时更清爽。
6.2 数据库初始化脚本：一秒钟准备好答辩数据
答辩现场最怕的不是功能bug，而是数据太难看或者环境没准备好。强烈建议写一个schema.sql和一个data.sql，前者包含建表语句，后者包含演示用数据。插入的数据要刻意配合演示流程：至少3个管理员账号、5个教师账号、2个班级20个学生、每门课程容量故意空出若干名额、再制造几门已满的课程用来演示"选课失败"的场景。
演示数据还可以准备一组"状态差异"数据。比如成绩表里，留一条status=2已提交但未审核的成绩，答辩现场点击审核按钮，让审核前后学生端看不到变成看得到。这种实时的状态切换演示，比口头解释"这里有状态"要有说服力得多。
6.3 演示顺序的思路：按角色串起一条故事线
教务系统的演示最忌"这里能增删改查、那里也能增删改查"的流水账，要根据业务角色走一条完整故事线：
- 用管理员账号登录，展示首页统计面板（学生数、课程数、今日选课数），这是系统的"门面"
- 切到教师端，选一门课程，给班级学生录入成绩并提交，讲清成绩状态流转
- 切到管理员端，审核刚才提交的成绩，顺带讲一遍审核链路里的状态变化
- 切到学生端，先查成绩（审核后的已经可见），再完成一次"选课"操作
- 故意对一门已满课程发起选课，演示防超选返回的提示，让并发控制这个亮点数据化
这套顺序的好处是：每个操作都是上一操作的结果，演示过程本身就是一个完整业务流程，老师能顺着你的故事理解整个系统。
6.4 高频答辩问题准备清单
最后整理一份我搜集的高频提问和自己的作答思路，放在这里供你对着自查：
| 问题 | 作答要点 |
|---|---|
| 为什么用SSM框架 | 三层架构职责清晰，Spring管对象、Spring MVC管请求、MyBatis管SQL，每个环节可独立讲原理 |
| 事务在项目里哪里用到 | 选课模块的容量扣减和选课记录插入必须同生共死，缺一个都会造成数据不一致 |
| 拦截器原理 | 基于HandlerInterceptor接口，preHandle在Controller执行前运行，通过判断Session控制访问 |
| MyBatis和JDBC的区别 | MyBatis封装了JDBC的重复代码，动态SQL适合复杂条件查询，但又保留SQL可控性 |
| 分页怎么实现 | PageHelper利用MyBatis插件机制拦截SQL并拼接LIMIT，返回PageInfo封装总数和页数 |
| 如何防止超选 | UPDATE语句同时判断selected_count < max_student并自增，利用行锁原子性避免并发超卖 |
| 数据库索引有哪些 | 学号、课程编号这类唯一字段建UNIQUE索引，外键字段建普通索引，选课表建联合唯一索引 |
| 如何保障安全性 | 登录接口加盐MD5，后端拦截器统一校验Session，SQL用#{}预编译防止注入 |
每个问题不用答太久，三句话内讲到"原理 + 项目位置 + 实际效果"即可，老师最反感背概念却不知道用在哪里的回答。
如果让我再重做一遍这个项目，我大概率会用Spring Boot把后端重写一版，因为自动配置省掉的重复代码确实多。但回过头看，SSM阶段被迫手写的那套XML配置、显式声明的事务规则、手动拼接的SQL映射，反而让我对Java Web的底层机制有了扎实的理解——这种理解，恰恰是答辩和后面读Boot源码时的底气。
