Java教务系统开发实战：Spring Boot + MyBatis 从建库到并发优化全解析

简介：这是一份基于Web的数据学院教务管理系统完整源码与设计文档，采用SSM框架（Spring、SpringMVC、MyBatisPlus）搭配Vue与Ajax实现前后端交互，数据库使用MySQL 5.7，适合Java学习者、毕业设计开发者或需要搭建教务管理平台的技术人员参考。整套资源共465个文件、约8.88MB，包含128个Java后端源码、49个Vue前端组件、SQL建表脚本、XML/MyBatis映射配置以及BAT一键运行脚本，另有SVG图标、JPG/PNG图片素材和Word论文文档，目录结构清晰，方便按模块查阅。系统覆盖用户信息管理、图片素材与视频素材管理等功能模块，论文部分包含选题动因、背景意义、技术介绍和系统实现等内容，可帮助理解从环境搭建到功能落地的完整流程。目前已有176人学习下载，对于正在做SSM项目实战或教务系统二次开发的人群而言，这套代码具备直接运行和扩展改造的参考价值。

1. 基于Web的数据学院教务系统：一个Java课设题为什么值得认真做

每年到了课程设计季，总有人把“基于Web的数据学院教务管理系统”当成一个能混过去的Java作业——数据库随便建三张表，前端套一个Bootstrap模板，后端用Servlet硬怼，最后交一篇写了跟没写一样的报告。但真正在软件公司带过新人的工程师都清楚，这个题目恰好是Java企业级开发的最小完整闭环：有权限、有事务、有并发、有报表。把“数据学院教务系统”做扎实了，Spring Boot、MyBatis、MySQL、Maven这一套主流工具链的实战经验就全有了，面试时聊项目也不至于只背概念。这篇笔记就按“设计 -> 建库 -> 写代码 -> 踩坑 -> 优化”的顺序，把整套系统的落地路径拆开讲，新手照做能跑通，熟手也能在边界条件里找到点参考价值。

2. 技术选型与分层架构：Spring Boot + MyBatis 还是 JSP直连？

2.1 技术选型对比：为什么 Spring Boot + MyBatis 是主流方案

数据学院教务系统这种题目，最常被拿出来对比的三套方案是：纯 JSP + Servlet + JDBC、Spring MVC + MyBatis 的 SSM 组合、以及 Spring Boot + MyBatis。把三套放在一个表里对比，结论会非常直观：

我一般会直接推荐 Spring Boot + MyBatis。原因不是“新就是好”，而是这个组合能让开发重心回到业务本身。教务系统的核心是三个角色的权限流转（学生、教师、教务管理员），是选课的并发控制，是成绩录入的事务边界——这些才是值得花时间的设计点。如果用 JSP + Servlet，时间全耗在手工封装 JDBC 结果集、处理字符编码、写一大坨 if/else 判断角色上，那等于把力气花在了毫无成长性的地方。

Spring Boot 2.x 是目前课程设计和中小型项目最稳的选择，JDK 用 8 或 11 都行。MyBatis 比 JPA 更贴合这类“多表关联查询多、动态 SQL 多”的业务场景——教务系统里教师按条件查学生成绩、管理员按学期按专业统计选课人数，这些全是典型的动态 SQL，MyBatis 写起来比 JPA 直白得多。

2.2 前后端形态：服务端渲染还是前后端分离

确定了后端技术栈，紧接着要决定的是页面怎么出。这里两条路：用 Thymeleaf 做服务端渲染，或者用 Vue/React 做前后端分离。我的建议很直接——单人开发、周期短的教务系统，优先选 Thymeleaf。

前后端分离不是不行，但它引入了一整套额外复杂度：跨域配置、Token 鉴权、接口文档维护、前端工程构建。一个人写课设，把这些全部搞定不是不行，而是性价比太低。Thymeleaf 的好处是后端一个 war 包全搞定，页面里用th:each遍历学生列表，用th:if控制按钮显隐，角色权限直接在模板层判断，开发效率至少快一倍。

如果读者执意要上前后端分离，也有一个折中做法：后端把 REST 接口写好，前端用一个轻量的 CDN 引入 Vue 2 + axios，不做工程化构建，页面文件直接扔进static目录。这样既有了接口化的好处，又不需要配置 Node 构建链。只是要额外处理跨域，这个在第 5 章避坑里会说。

2.3 Maven 工程结构与分包原则

工程结构决定了后续维护的心态。一个标准的 Spring Boot 教务系统，我习惯按“controller -> service -> mapper -> entity -> config -> common”六层分包：

com.datacollege.education ├── controller // 接收请求，参数校验，返回视图或JSON ├── service // 业务逻辑：选课事务、成绩计算、权限校验 │ └── impl ├── mapper // MyBatis接口，SQL写在XML里 ├── entity // 数据库实体，与表字段一一对应 ├── config // 拦截器、跨域配置、全局异常处理 ├── common // 统一返回结果、常量类、工具类 └── resources ├── mapper // MyBatis XML文件 └── templates // Thymeleaf模板

分包的核心原则是“依赖方向自上而下”：controller 只依赖 service 接口，不直接碰 mapper；service 只管业务编排，不写 SQL；mapper 只做数据读写。教务系统里最容易出现的坏味道，就是为了省事在 controller 里直接注入 mapper，初期写起来确实快，但做到选课事务、成绩汇总这类跨表逻辑时，没有 service 层兜底，事务注解都不知道该往哪里放。

2.4 第一个可运行的最小工程

Maven 骨架可以手工从 start.spring.io 生成，也可以直接在 IDEA 里新建 Spring Initializr 项目。依赖只需要选四个：Spring Web、Thymeleaf、MyBatis Framework、MySQL Driver。注意 MyBatis 要选MyBatis Framework，不是MyBatis Plus——虽然 Plus 用起来更省事，但课设阶段我不建议直接用，原因后面避坑章节会专门说。

生成工程后，先别急着写业务。第一步是配置数据源和 MyBatis 映射，跑通一个最基础的查询接口，确认整条链路是通的：

# application.yml server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/data_college?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false username: root password: 123456 mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.datacollege.education.entity configuration: map-underscore-to-camel-case: true

数据源配置里有三个细节直接决定你后面省不省心。第一，characterEncoding=utf8必须写，不写的话 MySQL 默认的连接字符集可能不是 UTF-8，中文数据写入就乱码。第二，serverTimezone=Asia/Shanghai必须写，MySQL 8 的驱动不指定时区会直接报错；第三，map-underscore-to-camel-case设为 true，能让数据库的student_name自动映射到 Java 实体的studentName，少写一堆@Results注解。

3. 数据库设计：六张核心表把教务业务说清楚

3.1 实体关系分析：从业务场景推导表结构

数据学院教务系统的业务边界要圈清楚。最小可用版本需要支撑的角色是三类：学生（选课、查成绩、查课表）、教师（录入成绩、查看授课班级）、教务管理员（维护学生信息、教师信息、课程信息、审核选课结果）。由此推导出的核心实体就是五个：学生、教师、课程、选课记录、成绩。

外加一个“用户表”用于统一登录。大多数课设会把账号密码直接塞进学生表和教师表，这样做的坏处是扩展角色时要改表结构，而且密码和业务数据混在一起不好做权限控制。我更建议拆一张独立的sys_user表存登录信息，通过user_type区分角色，再关联对应业务表的 ID——这样以后想加一个“辅导员”角色，不动业务表，只加一条用户记录。

5 张业务表加 1 张用户表，正好六张。实体关系是：学生和课程是多对多（通过选课记录关联），教师和课程是一对多（一个教师可以带多门课），选课记录和成绩是一对一（一门选课最终只对应一条成绩记录）。这里有一个新手常犯的设计错误：把成绩字段直接放在选课记录表里。表面看没问题，但一旦要做“成绩修改留痕”或者“成绩审核流程”，单独的成绩表才有存放状态的余地。

3.2 建表 SQL 与字段参数说明

直接给出一套可直接执行的建表脚本，覆盖上面六个实体：

-- 用户表：统一登录入口 CREATE TABLE `sys_user` ( `id` INT NOT NULL AUTO_INCREMENT, `username` VARCHAR(50) NOT NULL COMMENT '登录账号', `password` VARCHAR(100) NOT NULL COMMENT 'BCrypt加密后的密码', `user_type` TINYINT NOT NULL COMMENT '1-学生 2-教师 3-管理员', `ref_id` INT NOT NULL COMMENT '关联学生表或教师表的ID', `status` TINYINT DEFAULT 1 COMMENT '1-启用 0-禁用', PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='系统用户表'; -- 学生表 CREATE TABLE `student` ( `id` INT NOT NULL AUTO_INCREMENT, `student_no` VARCHAR(20) NOT NULL COMMENT '学号', `name` VARCHAR(50) NOT NULL, `gender` TINYINT DEFAULT 0 COMMENT '0-未知 1-男 2-女', `major` VARCHAR(100) COMMENT '专业', `grade` VARCHAR(10) COMMENT '年级，如2024', `phone` VARCHAR(20), PRIMARY KEY (`id`), UNIQUE KEY `uk_student_no` (`student_no`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='学生信息表';

后面四张表的字段逻辑与上面类似，不做完整展开，但有三处参数例外要说清楚。

第一处是password字段长度必须给 100，不能省成 50。因为 Spring Security 自带的BCryptPasswordEncoder加密出来的字符串长度是 60，后面如果换算法或者加盐格式变化，50 的长度会直接导致插入失败。这个是我见过最频繁的翻车现场。

第二处是表和字段统一用utf8mb4而非utf8。utf8 在 MySQL 里最多存 3 字节的字符，遇到生僻字或 Emoji 直接报错或变成问号。学生姓名、课程名称里出现生僻字是常态，所以建表时就要用 utf8mb4。

第三处是课程表里建议冗余一个teacher_id字段直接关联教师表，而不是建第三张关联表。一门课只有一个主讲教师，多对一关系用外键字段表达就够了。冗余字段不是设计缺陷，相反，它在查课表、查授课班级时能少一次 JOIN，性能差别在数据量小的时候看不出来，但 SQL 的可读性会明显更好。

3.3 外键策略与索引设计：哪些约束该留、哪些该删

教科书上强调外键约束保证数据一致性，但实际项目中，教务系统这类读多写少的业务，我一般建议“逻辑外键、物理不加约束”。

原因有两条。一是性能：InnoDB 的外键约束在每次插入、更新时都要做额外的一致性检查，选课高峰期大量并发插入选课记录时，外键检查会成为瓶颈。二是灵活性：如果哪天要清理历史数据、批量导入、或者做分库分表，物理外键会变成巨大的阻碍。

做法是在建表时只建普通字段和索引，不在 DDL 里写FOREIGN KEY，数据一致性交给 service 层的事务和代码逻辑来保证。比如插入选课记录前，先查课程是否存在、课程容量是否已满，这些是业务校验，不属于数据库约束。

索引设计的关键点在于：连接字段必须建索引，查询条件字段按需建索引。选课记录表里student_id和course_id都是高频 JOIN 字段，必须建普通索引；成绩表的course_id加semester的联合索引，是“查某学期某门课的全部成绩”这个高频查询的优化关键。索引不是建得越多越好，因为每次插入都要同步维护索引树，索引过多反而拖慢写入速度。

4. 核心模块实现：登录鉴权、选课事务与成绩录入的 Java 代码

4.1 登录与角色鉴权：拦截器三个角色如何区分处理

教务系统的登录逻辑本质上就是三步：先按用户名查出用户，校验密码，再按用户类型跳转到不同首页。技术选型上，我建议不引入 Spring Security——不是它不好，而是对课设项目来说，Spring Security 的过滤器链配置门槛高，出了问题很难排查，而教务系统需要的能力（登录校验、角色区分）用 HandlerInterceptor 加一个注解就能实现，代码可控性更强。

先写登录的 service 层逻辑：

@Override public LoginResult login(String username, String rawPassword) { // 1. 按用户名查用户 SysUser user = userMapper.findByUsername(username); if (user == null) { return LoginResult.error("用户名或密码错误"); } // 2. 校验密码（BCrypt） if (!passwordEncoder.matches(rawPassword, user.getPassword())) { return LoginResult.error("用户名或密码错误"); } // 3. 查角色对应的详细信息（学生查学生表、教师查教师表） if (user.getStatus() == 0) { return LoginResult.error("账号已被禁用，请联系管理员"); } return buildLoginResult(user); }

这段代码的关键点是第二行的matches方法。数据库里存的是 BCrypt 加密后的密文，不是明文，所以不能用equals直接比。之前见过一个课设代码，用 MD5 加盐配合自定义校验，当然也能跑，但 BCrypt 是行业默认标准，写进简历里也经得起问。passwordEncoder就是一个BCryptPasswordEncoder的 Bean，Spring Boot 里手动声明一个即可。

登录成功后，需要把用户信息放进 Session，然后交给拦截器做后续校验。拦截器的作用是挡掉未登录的请求：

public class LoginInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 放行登录接口和静态资源 String uri = request.getRequestURI(); if (uri.startsWith("/login") || uri.startsWith("/css") || uri.startsWith("/js")) { return true; } // 检查Session中是否有登录用户 Object loginUser = request.getSession().getAttribute("loginUser"); if (loginUser == null) { // AJAX请求返回JSON状态码，普通请求重定向到登录页 String requestedWith = request.getHeader("X-Requested-With"); if ("XMLHttpRequest".equals(requestedWith)) { response.setContentType("application/json;charset=utf-8"); response.getWriter().write("{\"code\":401,\"msg\":\"未登录\"}"); } else { response.sendRedirect("/login"); } return false; } return true; } }

拦截器里最容易忽略的是对 AJAX 请求的处理。如果你做了前后端分离或者页面里有异步加载，未登录时重定向会返回一整页 HTML 给前端，导致前端解析 JSON 报错。所以我在这里对X-Requested-With做了判断，AJAX 请求返回一个 401 的 JSON，前端拿到后统一跳转登录页。这个细节在联调时非常实用。

4.2 选课模块：事务边界与超选并发控制

选课是教务系统里技术要求最高的一个功能，因为它是真正的“写并发”场景——成千上万个学生同时选同一门热门课，如果代码不做并发控制，课程容量 50 人，实际可能选进去 80 人。

先看基础版本，一个选课操作的 service 方法：

@Transactional(rollbackFor = Exception.class) public void selectCourse(Long studentId, Long courseId) { // 1. 查课程信息（含当前已选人数） Course course = courseMapper.selectByIdWithSelectedCount(courseId); if (course == null) { throw new BusinessException("课程不存在"); } // 2. 校验课程容量 if (course.getSelectedCount() >= course.getCapacity()) { throw new BusinessException("课程已满员"); } // 3. 查是否已选过 int existCount = courseSelectMapper.countByStudentAndCourse(studentId, courseId); if (existCount > 0) { throw new BusinessException("请勿重复选课"); } // 4. 插入选课记录 courseSelectMapper.insert(studentId, courseId); // 5. 课程已选人数+1 courseMapper.increaseSelectedCount(courseId); }

这个版本在低并发时没问题，但一旦并发上来就翻车。问题出在哪？“查容量 -> 判断 -> 插入”这中间有三步，两个请求同时通过了容量判断，就都执行了插入，最后选课人数超出容量。

解决超选的常见做法是使用数据库的乐观锁。给课程表加一个version字段，更新时带上版本号条件：

// SQL: UPDATE course SET selected_count = selected_count + 1, version = version + 1 // WHERE id = #{courseId} AND version = #{version} int rows = courseMapper.increaseSelectedCountWithVersion(courseId, course.getVersion()); if (rows == 0) { throw new BusinessException("选课人数已满，请选择其他课程"); }

这段代码的逻辑核心在于：把“判断容量”和“更新人数”合并成一条原子 SQL。version字段作为乐观锁令牌，更新时发现版本号不匹配（说明有其他人抢先改过），rows返回 0，当前请求直接失败，由前端提示“课程已满”。与悲观锁SELECT ... FOR UPDATE相比，乐观锁在冲突不激烈时性能好很多，适合教务系统这种“偶尔抢课、平时冷清”的性质。

4.3 成绩录入：批量更新与成绩变更留痕

成绩录入是教师端的核心操作。最原始的写法是一条条 UPDATE，一门课 60 个学生就要执行 60 次数据库请求，网络开销和事务时间都被拉长。批量更新是必须做的优化。

MyBatis 支持在 XML 里用<foreach>拼接批量 SQL：

<update id="batchUpdateScore" parameterType="list"> <foreach collection="list" item="item" separator=";"> UPDATE score SET score = #{item.score}, update_time = NOW() WHERE course_id = #{item.courseId} AND student_id = #{item.studentId} </foreach> </update>

这里有一个隐藏坑需要提醒：MySQL 的 JDBC 驱动默认允许在rewriteBatchedStatements=true时才真正合并批量语句，否则<foreach>拼出的多语句虽然能执行，但性能优势不明显。在application.yml的 JDBC URL 后面加上&rewriteBatchedStatements=true，批量插入和批量更新的性能能提升一个数量级。

成绩变更留痕是另一个容易被忽略但面试常问的点。教务系统成绩一旦被修改应该留下记录，做法是在代码里加一层审计逻辑，不直接 UPDATE 原表，而是先插入一条变更日志，再更新成绩：

@Transactional(rollbackFor = Exception.class) public void updateScore(ScoreUpdateDTO dto, Long teacherId) { // 1. 校验教师是否有权录入这门课的成绩 int checkCount = courseMapper.countByTeacherAndCourse(teacherId, dto.getCourseId()); if (checkCount == 0) { throw new BusinessException("您不是该课程的授课教师"); } // 2. 插入成绩变更日志 ScoreLog log = new ScoreLog(); log.setCourseId(dto.getCourseId()); log.setStudentId(dto.getStudentId()); log.setOldScore(scoreMapper.selectScore(dto.getCourseId(), dto.getStudentId())); log.setNewScore(dto.getScore()); log.setOperatorId(teacherId); scoreLogMapper.insert(log); // 3. 更新原成绩 scoreMapper.updateScore(dto.getCourseId(), dto.getStudentId(), dto.getScore()); }

这个模块对应的权限控制是一个容易踩坑的点：接口层面不能只做“登录校验”，必须做“业务权限校验”。拦截器只能判断用户是不是教师，不能判断该教师是否教这门课。所以 service 层第一步就要查course表里课程的teacher_id是否等于当前登录用户。这个逻辑看似简单，却是权限设计的核心层次——功能权限是“能不能用”，数据权限是“能用在哪条数据上”，两者缺一不可。

5. 避坑手册：教务系统开发中五个典型翻车现场

5.1 中文乱码：配置全对了还是显示问号

现象：学生姓名、专业名称写入数据库后变成??，或者从数据库读出来在页面上显示乱码。

原因：三层编码不一致。最常见的是数据库表用了latin1或utf8（非 utf8mb4），或者 JDBC URL 没加characterEncoding=utf8，又或者 Tomcat 的 URI 编码不是 UTF-8。还有一个让新手懵的坑：MySQL 整个实例的默认字符集不对，新建表时没有显式声明DEFAULT CHARSET，于是继承了实例的旧字符集。

解决：统一三层配置。JDBC URL 加上useUnicode=true&characterEncoding=utf8；建表语句显式写明DEFAULT CHARSET=utf8mb4；Spring Boot 里server.servlet.encoding.force=true强制请求和响应都用 UTF-8。排查时用SHOW CREATE TABLE看表的实际字符集，不要太相信工具里的显示。

5.2 选课并发导致超选：容量明明设了限还是超员

现象：一个容量 50 人的课程，最终选课人数到了 57 人。用 JMeter 或其他压测工具并发请求选课接口，问题必现。

原因：查容量和插入选课记录之间不是原子操作。两个并发事务都读到selected_count=49，都判断“未满”，于是都执行了插入。“数据库层面的并发问题，不能靠业务代码顺序来解决”这句话在这个场景体现得最典型。

解决：用版本号做乐观锁，把更新操作改为条件更新，UPDATE ... WHERE version = #{version}，更新影响行数为 0 就说明冲突，直接抛业务异常。如果觉得乐观锁在极端高峰时失败率太高，可以改用SELECT ... FOR UPDATE悲观锁锁行，但要注意锁必须放在事务里，且尽快提交释放，否则会拖垮其他写操作。

5.3 前后端分离部署时的跨域问题

现象：前端跑在 8081 端口，后端跑在 8080，浏览器里 AJAX 请求全部被拦截，控制台报CORS origin相关错误。

原因：浏览器的同源策略。端口不同即视为跨域，需要后端在响应头里显式声明允许跨域。

解决：Spring Boot 里实现WebMvcConfigurer接口，重写addCorsMappings方法，配置允许的来源、方法和请求头。如果启用了 Spring Security，还需要把 CORS 配置放在安全过滤器链之前，否则结果还是被拦。配置代码不复杂，核心是allowedOriginPatterns要按实际前端域名写，不要图省事直接*，否则带 Cookie 的请求还是会失败。

5.4 MyBatis 一级缓存导致的“查不到刚更新的数据”

现象：同一次请求里，先调用了更新接口，再查询数据，结果查询到的还是旧值。

原因：MyBatis 默认开启一级缓存（SqlSession 级别的缓存），在同一个 SqlSession 中执行两次相同的 SQL，第二次直接命中缓存。Spring 管理的事务中，SqlSession 在事务内是复用的，所以先 UPDATE 再 SELECT 同一条记录时，SELECT 可能拿到了缓存里的旧结果。

解决：这个坑其实很罕见，因为多数场景下 UPDATE 会触发缓存清空。真正会翻车的场景是通过@Transactional包了多个操作，且 MyBatis 的一级缓存作用域超出预期。稳妥的做法是设置mybatis.configuration.local-cache-scope=STATEMENT，放弃一级缓存，换取数据的绝对实时性——教务系统查询压力不大，损失一点缓存性能换取正确性非常划算。

5.5 Spring 事务自调用导致 @Transactional 失效

现象：在同一个类里，一个方法调用了另一个标了@Transactional的方法，事务没有生效，数据写入一半报错后无法回滚。

原因：@Transactional是基于 Spring AOP 代理实现的。同一个类里的方法调用走的是this引用，不会经过代理对象，注解自然不生效。这是 Spring 事务机制里最经典的误用，别说学生，工作两三年的程序员也照样踩。

解决：事务方法不要写在当前类的内部调用链里。要么把需要事务的代码逻辑拆到另一个 Service 类中，把调用关系变成跨类调用，同时注入的是接口类型（注入机制保证注入的是代理对象）——这里特别提醒一下，注意不要注入成实现类；如果事务边界确实只能留在本类，就用AopContext.currentProxy()获取代理对象再调用。第一种方案是最干净的，也符合单一职责原则。

6. 最后一步：上线前的验证方法和性能体检

系统代码写完了，不代表它可以上线。教务系统的核心特征是“学期末集中使用、读多写少、关键时刻不能掉链子”，所以验证重点要放在功能覆盖和并发临界点上。

功能验证建议列一张 checklist，按角色逐项走：学生登录后能查到可选课程列表、选课成功后在“我的课表”里能看到、退课后容量正确释放；教师端能看到自己名下的课程、能批量录入成绩、修改成绩后日志里有变更记录；管理端能禁用学生账号、能调整课程容量、能在极端情况下手动代替学生完成退选课。验证完成后，用 Navicat 之类工具看一遍所有表的数据，逐个核对数据一致性——这个步骤能发现隐藏的问题，比任何代码审查都直接。

并发临界的验证，推荐用 JMeter 做一个最简单版本的压测实验：针对选课接口模拟 100 个线程同时发起请求，观察已选人数最终是否超过课程容量。这个实验不需要复杂的脚本，一个线程组加一个 HTTP 请求采样器就够。如果出现超选，优先检查乐观锁的条件 UPDATE 是否生效；如果出现大量失败，后退一步看数据库连接池的初始配置是否太小。

性能优化的优先级也有顺序。第一步看索引，用EXPLAIN检查高频查询是否走索引，重点关注选课记录表的student_id和成绩表的联合索引。第二步看缓存，把“课程列表”“学生列表”这些变化频率低、读频率高的数据用本地缓存（如 Caffeine）存起来，设置 5 分钟过期，效果立竿见影。第三部才考虑 SQL 本身优化，比如分页查询用覆盖索引避免回表。顺序别反——很多同学一上来就加缓存，结果索引错了，缓存数据还是错的，半天找不到根因。

最后一个习惯想分享给看到这里的读者：给项目留一份“部署手记”，把启动步骤、MySQL 初始化脚本、默认账号密码、遇到的坑和解决方案都写进去。我做过不少学生的课设答辩评审，答辩时问到部署细节，能掏出这份手记的人，和支支吾吾的人，分数差距一眼就看出来了。这个习惯在职场上也值钱——线上问题排查时，一份准确的环境文档就是后悔药，能让你少熬好几次夜。希望这篇笔记能帮你在数据学院教务系统这个项目上少走几步弯路。

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