企业官网建设流程全解析

1. 项目定位与整体设计拆解

1.1 为什么“教师信息管理系统”是经典且稳妥的毕设选题

每年毕业设计选题季，Java 方向的同学总能在参考列表里刷到“教师信息管理系统”这个题目。有人觉得它太普通，非要加个“平台”或者“智慧”的前缀心里才踏实。但我要先泼一盆冷水：普通不等于简单，把普通题目做出完整度，远比把大题目做出半成品更容易拿高分。

这类系统的核心业务非常清晰：管理教师的基本档案信息，比如工号、姓名、性别、职称、学历、所属院系、联系电话、入职时间；往上叠加课程信息管理，比如课程编号、名称、学分、课时、开课院系、课程性质；最后通过一个排课关联模块把“谁在哪个学期上什么课、在哪个教室几点上课”管理起来。本质就是一个多角色、多实体、多对多关系的典型业务系统。

从毕业答辩的角度看，这个选题有几个天然优势。功能边界很清楚，不会被“你这系统到底解决了什么问题”问住；CRUD 覆盖齐全，增删改查、分页、模糊查询、登录鉴权、关联表操作全都有，覆盖了 Java Web 开发的主要知识点；扩展性好，往里面加数据统计、导入导出、课表视图都比较自然。更重要的是，数据库设计涉及多张表和一组多对多关系，正好能体现你建模的基本功。

1.2 角色划分与核心功能模块拆解

这部分我建议一开始就定死，不要在开发中途反复横跳。我按最常见的方案给你拆一下：

• 管理员（admin）：拥有全部权限。教师信息的增删改查、课程信息的维护、给教师分配课程、重置教师账号密码、查看基础统计。
• 教师（teacher）：只查看自己的课表、维护自己的联系方式，以及修改密码。

这里有个容易犯的错：很多同学会把“教师表”和“用户表”直接合成一张表。我强烈不建议这么做。用户表管的是登录凭证，教师表管的是教学档案，两者的生命周期和关注点不一样。就算现阶段教师登录名正好是工号，合成一张表也能跑通，但答辩时老师问一句“如果来了一位教务实习管理员，不教课，怎么登录系统”，你只能当场改代码。把两张表分开，是分层的习惯，也是给自己留余地。

核心功能列表如下：

• 登录认证：账号密码校验、角色区分、退出登录。
• 教师信息管理：列表分页、组合查询（按姓名/工号/职称/院系）、新增、编辑、删除。
• 课程信息管理：课程列表、新增、编辑、删除，课程按院系/性质筛选。
• 排课管理：给教师安排课程，绑定学期、上课时间、地点，同一个教师同一学期不能重复排同一门课，可做可不做，但做了就是加分项。
• 教师端视图：当前登录教师查看自己的授课安排和个人信息。
• 系统层面：密码修改、登录拦截、全局异常处理。

1.3 功能扩展的方向怎么选

如果时间有余量，我建议优先做两个方向，性价比最高。第一个是 Excel 导出：把教师列表或课表导出成 .xls 文件。这个功能在毕设展示时很直观，点一下按钮，文件就出来了，而且技术实现也不难，用 Apache POI 的简单 API 就能搞定。第二个是数据统计：按院系统计教师人数、按课程性质统计课程占比，再用图形展示。可以不引入前端图表库，直接在页面里用统计表格把数字列出来，效果也不差。

我见过有同学在毕设里非要上 Redis 缓存和消息队列，结果被答辩老师追问“缓存失效怎么处理”“消息丢失怎么办”直接卡住。不是说新技术不能用，而是毕设的第一原则是可控，不是花哨。你把 Spring Boot 基础 CRUD 写干净、把分页做得统一、把权限区分清楚，已经能达到中等偏上水平。

2. 技术选型与数据库设计思路

2.1 技术栈选型：以“够用且能讲清楚”为第一原则

技术栈的选择，决定了你接下来六周是轻松还是痛苦。我直接给一套经过大量实践验证的组合：Spring Boot + MyBatis + MySQL + JSP，构建工具用 Maven，服务器内嵌 Tomcat，JDK 用 8。这套组合在毕业设计里属于“经典街机配置”，遇到任何问题都能搜到解决方案，答辩老师也比较认可。

为什么选 Spring Boot 而不是传统的 SSM（Spring + Spring MVC + MyBatis）？因为 Spring Boot 的自动配置帮你解决了大量繁琐的 XML 配置，原来写一页的配置，现在一两行就完事。而且内嵌 Tomcat 让打包发布变得简单，演示的时候不用在答辩电脑上装一个完整 Tomcat 再部署 war 包。如果你在简历上写“熟悉 Spring Boot”，也比“熟悉 SSH”听起来更接近当前工程实践。

为什么选 JSP 而不是前后端分离 Vue？很多同学现在一开口就是“前后端分离”。但我认真建议，毕业设计尽量不要用 Vue + 后端接口分离。原因有三个：第一，前后端分离意味着你要处理跨域请求、Token 认证、接口异常处理三层问题，比简单会话管理复杂不少；第二，答辩现场的演示环境和网络状况不可控，前端静态资源和后端接口跨域部署容易翻车；第三，评审老师更习惯看到“页面 + 表单 + 数据回显”的经典 Web 结构，JSP + JSTL 在服务端渲染数据，思路直观。当然，如果你的选题明确要求前后端分离，那是另一回事，但对于教师信息管理系统，真没必要给自己加戏。

MyBatis 比 JPA 更可控。JPA 自动建表省事，但实体类映射复杂，而且“自动生成 SQL”会让你在答辩时很难回答“这个查询是怎么执行的”。MyBatis 的 SQL 全部写在 XML 里，一眼能看到逻辑，写复杂多表查询也更直接。

2.2 核心表结构设计：一张张说清楚为什么这么建

先上整体思路：我的方案需要四张正式表外加一张中间表。在设计上遵循一个原则：业务实体表和登录认证表分离，多对多关系用中间表承接。

第一张表是用户表 user。字段包括 id（主键）、username（登录用户名）、password（密码）、role（角色）、status（账号状态）、teacher_id（关联教师表），再补上 create_time 和 update_time。为什么要关联 teacher_id？因为管理员账号可能不绑定教师，但教师账号必须能关联到具体教师档案，便于登录后自动显示教师信息。username 必须建唯一索引，防止重复账号。角色字段用字符串 'ADMIN' 和 'TEACHER' 就够，不用搞复杂的权限模型。

第二张表是教师表 teacher。字段有 id、teacher_no（工号）、name（姓名）、gender（性别）、title（职称，如副教授/讲师）、education（学历）、department（所属院系，这里用字符串存院系名称，毕设阶段不必单独建院系表）、phone、email、hire_date（入职时间）。teacher_no 必须有唯一索引，这非常关键。删除策略后面细讲。

第三张表是课程表 course。字段有 id、course_no（课程号）、course_name（课程名）、credit（学分）、hours（课时）、dept（开课院系）、course_type（课程性质，必修或选修）。course_no 也建唯一索引。

第四张表是排课关联表 teach_assignment。字段有 id、teacher_id、course_id、semester（学期，如 2024-2025-1）、class_time（上课时间，如 周一 3-4 节）、location（上课地点）。这张表就是教师和课程多对多关系的落点：一个教师可以有多门课程，一个课程也可能由多个教师在不同学期承担。多对多关系拆成一张中间表，是数据库设计的经典操作，答辩必问，这个要能讲明白。

第五张和第六张表，如果你做通知公告，就加一张 notice 表；如果你做数据字典，加一张 dict 表。但做不了太多也别焦虑，四张核心表已经足够撑起一个完整的演示流程。

2.3 密码存储、逻辑删除与字段冗余的取舍

密码存储是必问问题。明文存密码，答辩基本会被打个低分。我的建议是至少用 MD5 加盐，或者直接上 BCrypt。MD5 本身有彩虹表风险，加盐能缓解，但 BCrypt 在 Spring Security 里有现成工具类，引入一个依赖就能用，没必要自己造轮子。不过如果不引入 Spring Security，只想简单做，可以用 JDK 自带的 MessageDigest 对密码加固定盐后做 SHA-256，也能讲清楚原理。

删除策略上，有物理删除和逻辑删除两条路。物理删除简单，DELETE 语句一行，但一旦删除教师档案，排课表里的关联记录就可能变成孤儿数据。更稳妥的做法是加一个 is_deleted 字段，默认 0；删除时置为 1，查询时统一加条件 is_deleted = 0。这个细节在答辩时能成为亮点，因为你主动考虑了数据完整性问题。同时建议在删除教师之前先检查 teach_assignment 里有没有关联记录，有的话给出提示“该教师还存在排课记录，无法删除”，这比直接报 SQL 异常优雅得多。字段冗余方面，比如在 teach_assignment 中不存教师姓名和课程名，通过 join 去查，不要冗余存储，这是符合范式设计的，也不难讲。

3. 核心功能实操与代码实现

3.1 环境准备和生产工具初始化

工具版本先对好，不然大概率在第一步就卡住。我实测下来比较顺的组合是：JDK 8（别追求 JDK 17，除非你清楚 Spring Boot 版本兼容，JDK8 是生态兼容性王者）、Maven 3.6.3 或更高、IDEA 2023 版本、MySQL 5.7 或 8.0（5.7 老而稳，8.0 也没问题，注意驱动类名需要改成 com.mysql.cj.jdbc.Driver）、Spring Boot 2.7.x。

怎么初始化项目？有两条路。一条是去 Spring 官方初始化器生成一个基础 Spring Boot 工程，然后引入必要依赖。另一条是直接用 IDEA 的 Spring Initializr，勾选 Web、MyBatis、MySQL Driver。我建议自己在 pom.xml 里手写依赖版本管理，别完全依赖初始化器生成的默认版本，否则遇到奇怪的依赖冲突你根本不知道从哪查起。

pom.xml 的核心依赖参考如下（只列最关键部分，完整依赖请配合官方文档补齐）：

<parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.7.18</version> </parent> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.mybatis.spring.boot</groupId> <artifactId>mybatis-spring-boot-starter</artifactId> <version>2.3.1</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <scope>runtime</scope> </dependency> <dependency> <groupId>javax.servlet</groupId> <artifactId>jstl</artifactId> <version>1.2</version> </dependency> <dependency> <groupId>org.apache.tomcat.embed</groupId> <artifactId>tomcat-embed-jasper</artifactId> <scope>provided</scope> </dependency> </dependencies>

JSTL 和 tomcat-embed-jasper 这两个一定要加，很多同学卡在 JSP 在 Spring Boot 里无法渲染，就是因为缺了它们。

3.2 建表 SQL 与初始数据

我说一下建表时比较容易被忽略的两个点：字符集和字段精度。字符集必须用 utf8mb4，如果只写 utf8，存emoji或者特殊符号会乱码；字段精度主要是学分和课时，用 DECIMAL(3,1) 存学分比较稳妥，课时用 INT 就行。

一张精简的建表脚本示例（注意这是简化版，完整脚本请自行补充注释和索引）：

CREATE TABLE teacher ( id BIGINT PRIMARY KEY AUTO_INCREMENT, teacher_no VARCHAR(20) NOT NULL UNIQUE COMMENT '工号', name VARCHAR(50) NOT NULL COMMENT '姓名', gender VARCHAR(4) COMMENT '性别', title VARCHAR(30) COMMENT '职称', education VARCHAR(30) COMMENT '学历', department VARCHAR(50) COMMENT '所属院系', phone VARCHAR(20), email VARCHAR(100), hire_date DATE COMMENT '入职时间', is_deleted TINYINT DEFAULT 0 COMMENT '逻辑删除标记', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='教师信息表'; CREATE TABLE course ( id BIGINT PRIMARY KEY AUTO_INCREMENT, course_no VARCHAR(20) NOT NULL UNIQUE COMMENT '课程号', course_name VARCHAR(100) NOT NULL COMMENT '课程名', credit DECIMAL(3,1) COMMENT '学分', hours INT COMMENT '课时', dept VARCHAR(50) COMMENT '开课院系', course_type VARCHAR(10) COMMENT '必修/选修', is_deleted TINYINT DEFAULT 0, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='课程表'; CREATE TABLE teach_assignment ( id BIGINT PRIMARY KEY AUTO_INCREMENT, teacher_id BIGINT NOT NULL, course_id BIGINT NOT NULL, semester VARCHAR(20) COMMENT '学期，如 2024-2025-1', class_time VARCHAR(50) COMMENT '上课时间', location VARCHAR(100) COMMENT '上课地点', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_teacher (teacher_id), KEY idx_course (course_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='排课关联表';

这里再提一句：交集表里我把 teacher_id 和 course_id 建了普通索引，但没建联合唯一索引。如果你要约束“同一教师同一课程同一学期不能重复”，可以在 semester、teacher_id、course_id 三个字段上建联合唯一索引。但真实需求和你们学校教务规则有关，这个自己评估，不建议拍脑袋定方案。

3.3 项目分层结构与包规划

Spring Boot 项目的目录结构要清晰，包命名尽量一致。我看过太多把 Controller 层和业务逻辑全部堆在 main 方法里的项目，答辩时翻代码连自己都找不到文件。整理一下比较合理的包结构：

com.example.teacherms ├── controller // 控制层，接收请求，返回视图 ├── service // 业务层，事务边界 ├── mapper // MyBatis 的 Mapper 接口 ├── entity // 实体类，对应数据库表 ├── dto // 传输对象，用于 VO 视图对象 ├── config // 拦截器、WebMvc 配置 └── common // 统一返回结果，通用分页对象

分层的核心逻辑是这样的：Controller 层只做参数接收和视图跳转，不写 SQL 相关代码；Service 层定义业务接口，并实现业务规则（比如删除前检查关联）；Mapper 层只负责数据库交互。这样分层，答辩时老师问“你这个删除逻辑写在哪”，你可以头也不抬地回答“在 Service 层，因为删除前要先验证排课关联是否存在”。

分页查询建议做一个通用的 PageResult 类，包含当前页数据列表、总记录数、总页数、当前页码、每页条数，避免每个功能各写各的分页逻辑。

3.4 登录认证与双角色权限控制落地

登录这部分要处理的核心问题是：如何让管理员和教师登录后看到不同的内容？如何保证未登录用户不能访问内部页面？

我用 Session + 拦截器来解决。登录成功后，把用户对象放进 Session；写一个 LoginInterceptor 拦截器，检查所有以管理员和教师前缀开头的请求，如果 Session 里没有登录用户，就跳转到登录页。这个方案简单、稳定、答辩好讲。

先写登录 Service 的核心逻辑：

public User login(String username, String password) { User user = userMapper.selectByUsername(username); if (user == null) { return null; } String hashed = DigestUtils.md5DigestAsHex((password + SALT).getBytes()); if (!hashed.equals(user.getPassword())) { return null; } return user; }

注意 SALT 是一个常量字符串，这种做法叫“固定盐”，安全性比不加密强得多，也能应付答辩。如果你愿意更专业一点，可以对每个用户生成随机盐存在库里，但复杂度会增加。固定盐加 MD5 在毕设里完全够用，答辩重点在思路。

然后写注册拦截器：

public class LoginInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { HttpSession session = request.getSession(); User user = (User) session.getAttribute("loginUser"); if (user == null) { response.sendRedirect("/login"); return false; } return true; } }

注册到 WebMvc 配置类中：

@Configuration public class WebMvcConfig implements WebMvcConfigurer { @Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new LoginInterceptor()) .addPathPatterns("/admin/**", "/teacher/**") .excludePathPatterns("/login", "/css/**", "/js/**", "/images/**"); } }

这段配置是关键：addPathPatterns 定义了要拦截的路径，excludePathPatterns 把登录页和静态资源排除掉。很多同学在拦截器上踩坑，后面调试章节专门讲。

3.5 教师信息管理：从列表到增删改查的完整实现

教师信息管理的核心痛点无外乎组合查询 + 分页。在 Controller 层接收 pageNum、pageSize、keyword、department、title 这些查询参数，传给 Service 层，Service 层计算出 offset 值，然后调用 Mapper 查询列表和总数。这里我建议不要用 PageHelper 插件，原因有两点：第一，你手写 LIMIT 计算完全能讲清楚思路，答辩时不会被“插件内部怎么工作”难住；第二，减少一个依赖，部署环境出问题概率更低。

Service 层的分页核心代码：

public PageResult<Teacher> pageTeachers(int pageNum, int pageSize, String keyword, String department, String title) { int offset = (pageNum - 1) * pageSize; List<Teacher> teachers = teacherMapper.selectTeacherPageWithCondition( keyword, department, title, offset, pageSize); long total = teacherMapper.countTeacherWithCondition(keyword, department, title); int totalPages = (int) Math.ceil((double) total / pageSize); return new PageResult<>(teachers, total, totalPages, pageNum, pageSize); }

Mapper XML 里的动态 SQL 是重点，用<where>和<if>标签拼接条件：

<select id="selectTeacherPageWithCondition" resultType="com.example.teacherms.entity.Teacher"> SELECT * FROM teacher WHERE is_deleted = 0 <if test="keyword != null and keyword != ''"> AND (name LIKE CONCAT('%', #{keyword}, '%') OR teacher_no LIKE CONCAT('%', #{keyword}, '%')) </if> <if test="department != null and department != ''"> AND department = #{department} </if> <if test="title != null and title != ''"> AND title = #{title} </if> ORDER BY create_time DESC LIMIT #{offset}, #{pageSize} </select>

这里有个实操细节一定要提示：LIMIT 的第二个参数是 pageSize，第一个参数是 offset，offset 的计算要在 Service 层完成，而不是前端传过来，这样既控制层只做参数传递，又能防止用户传一个恶意 offset 把全表扫出来。总条数查询语句跟列表语句高度一致，只是把 SELECT 换成 COUNT，同样加上过滤条件，不能只写SELECT COUNT(*) FROM teacher然后忘了过滤，那汇总数肯定大于实际展示数，页面翻页就会失准。

新增和编辑教师时，工号的唯一性校验是必修课。我用 Service 层做检查：

public void addTeacher(Teacher teacher) { Teacher exists = teacherMapper.selectByTeacherNo(teacher.getTeacherNo()); if (exists != null) { throw new BizException("工号已存在，请检查后再提交"); } teacherMapper.insert(teacher); }

用一个自定义异常 BizException 来覆盖业务错误，配合全局异常处理，返回友好提示。全局异常处理器用 @RestControllerAdvice（但注意你这个项目是 JSP 视图，更适合用 @ControllerAdvice 配合 ModelAndView 返回一个统一错误页面），把所有未处理异常收纳到一个 500 页面，同时打印日志，这是工程化思维的好体现。

3.6 课程管理与排课的多对多关联实现

课程管理的 CRUD 大体和教师管理一致，不一样的是排课逻辑。教师和课程的关联通过 teach_assignment 表来达成，新增排课时，前端要展示教师下拉框、课程下拉框、学期输入框、时间和地点输入框。提交到后台后，Service 层要做一次关联校验，查一下同一教师同一学期是否已经排了同一时间段的课：

public void assignCourse(TeachAssignment assignment) { int count = assignmentMapper.checkConflict( assignment.getTeacherId(), assignment.getSemester(), assignment.getClassTime()); if (count > 0) { throw new BizException("该教师在这个时间段已有排课"); } assignmentMapper.insert(assignment); }

查询“某教师本学期课表”的 SQL：

<select id="selectCourseByTeacherAndSemester" resultType="com.example.teacherms.dto.CourseAssignmentVO"> SELECT c.course_no, c.course_name, c.credit, c.hours, ta.semester, ta.class_time, ta.location FROM teach_assignment ta LEFT JOIN course c ON ta.course_id = c.id WHERE ta.teacher_id = #{teacherId} AND ta.semester = #{semester} ORDER BY ta.class_time </select>

为什么用 LEFT JOIN 而不是 INNER JOIN？因为中间表是主体，如果某条排课记录的课程因为逻辑删除而过滤掉了，LEFT JOIN 依然能返回一行，无非课程字段是空，InnoDB 在分析阶段也不会因为匹配不到而丢弃整行。实际业务里这不算大问题，但 LEFT JOIN 表达的主从关系更清晰，左侧表和右侧表的地位一眼可见。

每次查询课表时都去 JOIN 课程表，如果老师有多门课，N+1 查询问题有时会冒出来。小数据量其实无所谓，但你得知道有这个优化空间。可以在一次 SQL 里把多门课程都查出来，MyBatis 的 collection 映射能处理嵌套集合，这是加分点，能聊就聊一段。

3.7 事务管理和异常处理的几个细节

业务层一定要加 @Transactional 注解的地方就两个：第一个是新增教师时同时初始化一个用户账号的操作；第二个是删除教师时同时逻辑删除关联的用户记录。这种跨表操作必须保证原子性。

@Transactional 的位置非常关键，很多新手把它加到 Controller 上，这样做虽然也能生效，但事务粒度跨越了整个请求生命周期，一旦视图渲染出错，事务就会回滚到不预期的位置。正确做法是放在 Service 接口实现上，标注在具体业务方法上，比如：

@Transactional(rollbackFor = Exception.class) public void deleteTeacherWithUser(Long teacherId) { teacherMapper.deleteById(teacherId); userMapper.deleteByTeacherId(teacherId); }

rollbackFor = Exception.class 必须写。默认情况下，Spring 只对 RuntimeExpection 和 Error 回滚，对 Checked Exception 不回滚。如果你从 Service 里抛出一个 ServiceException（继承 Exception 的受检异常），事务不会回滚，数据就会半残。这个细节实战中极容易踩。

全局异常处理，建议用 @ControllerAdvice 统一捕获异常，写一个异常处理器返回统一提示页面。日志要记录堆栈，不能只打印 e.getMessage()。开发阶段 open 调试信息，部署阶段就关掉，避免堆栈信息泄露给用户。这些细节都是答辩时展示自己考虑过健壮性的好素材。

4. 常见问题与调试经验实录

4.1 中文乱码：最容易翻车也最好修的坑

中文乱码是 Java Web 项目里最常见的坑，没有之一。表现五花八门：页面显示问号、数据库里存进去是问号、表单提交后乱码、下载文件名字乱码。讲几个重点排查位。

第一，数据库连接串必须带 characterEncoding=utf8，否则 JDBC 驱动和 MySQL 服务器通信用的字符集不对，中文写入就会变成乱码。完整写法是：

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

第二，如果你用 JSP，页面顶部要写<%@ page contentType="text/html;charset=UTF-8" language="java" %>，同时<meta charset="UTF-8">也不能少。第三，Spring Boot 里加一个字符编码过滤器，模拟原来的 CharacterEncodingFilter：

@Bean public FilterRegistrationBean<CharacterEncodingFilter> encodingFilter() { FilterRegistrationBean<CharacterEncodingFilter> bean = new FilterRegistrationBean<>(); bean.setFilter(new CharacterEncodingFilter()); bean.addUrlPatterns("/*"); bean.addInitParameter("encoding", "UTF-8"); bean.setName("encodingFilter"); return bean; }

第四，MySQL 本身在 Linux 的配置文件里默认是 latin1 的话，光靠连接串也不行，还要在建库时指定 utf8mb4。第五，IDEA 里运行配置的 VM 参数有时候也要加-Dfile.encoding=UTF-8。多管齐下，基本能根治。

4.2 数据库连接、驱动与时区的连环坑

Spring Boot 2.7 配合 MySQL 8.0，最容易报的错是：

java.sql.SQLException: The server time zone value '�й���ʱ��' is unrecognized ...

这个错就是时区问题。MySQL 8.0 的驱动连接串如果没写 serverTimezone，会尝试读本地时区，但中文系统环境变量里的时区名在 JDBC 驱动解析时会乱码。解决方式我已经写在上面了，连接串里加serverTimezone=Asia/Shanghai。

另一个常见报错是没有指定驱动类，或者是用旧驱动名。MySQL 8 的驱动类名是com.mysql.cj.jdbc.Driver，MySQL 5.7 时代的com.mysql.jdbc.Driver已经废弃。如果 pom 里依赖了 mysql-connector-java 8.x 版本，Spring Boot 会自动识别驱动类名，但你手写配置的话要注意用新类名。

还有 ake 一个典型的错误是：MySQL 服务没启动，或者用户名密码不对，报Access denied for user 'root'@'localhost'。这种情况先到命令行里用 root 账号手动登录 MySQL，确认密码正确，再看服务是否在运行。不要一上来就怀疑代码，SQL 连接这块 90% 是环境问题。

4.3 分页查询数据重复与错乱

分页翻页时发现数据重复或总数对不上，说到底就是 LIMIT 和 ORDER BY 的组合问题。最常见的原因有两个。

第一个是多表 JOIN 后分页，JOIN 出的结果集行数和主表行数不一致，导致 LIMIT 切出来的分页结果莫名其妙。比如一条教师记录在排课表里有 3 条关联，JOIN 后同一教师就出现了 3 行，LIMIT 每页 10 条时可能只出来 3 个不同教师，翻页时同一教师反复出现。解决方案是：不要 JOIN 完才分页，要么先分页得到主表 ID 集合，再用 WHERE id IN (...) 关联查子数据。这种思路面试也经常问，值得练。

第二个是 ORDER BY 的列不唯一，比如按 create_time 倒序，如果很多记录在同一秒创建，MySQL 的排序顺序不稳定，翻页时会偶发重复或漏数据。解决办法是排序字段加一个唯一字段，比如ORDER BY create_time DESC, id DESC。只要 id 是主键唯一，整体排序就没歧义。

4.4 登录拦截器把静态资源拦掉的尴尬

很多同学第一次写完拦截器，启动页面发现样式全丢了，白板一片。打开浏览器控制台，一堆 404 的 CSS 和 JS 请求。真相是拦截器把 /css 和 /js 的路径也拦了，用户在登录之前访问这些静态资源就被强行重定向到登录页，当然加载不到。

解决方式就在拦截器注册那里，excludePathPatterns 里把静态目录全部排除。这里要注意一点：Spring Boot 的默认静态资源路径是/static/**、/public/**、/resources/**这些，排除的时候要写全。还有，如果你在 JSP 页面里用的静态资源路径是相对路径，可能因为请求 URL 层级不同而指向错误位置，最好用${pageContext.request.contextPath}加绝对路径前缀。

另外，登录接口本身如果用的是 POST/login，要注意在拦截器排除路径列表里写清楚，不排除的话，你连登录请求都发不出去。

4.5 教师和课程的 JSON 循环引用问题

如果你不搞前后端分离而用 JSP，这个坑一般踩不到。但如果你给项目加了某个返回 JSON 的接口，比如课表查询返回 JSON 数据给前端 JS 渲染，那就要小心一个经典问题：Teacher 对象里有一个 List<Course>，Course 对象里又有一个 List<Teacher>，Jackson 序列化时互相引用直接栈溢出。

解决办法很简单，在实体类的关联字段上加@JsonIgnore，或者用@JsonManagedReference和@JsonBackReference控制序列化方向。对于这个项目，我建议展示教师的信息时不需要在 JSON 里返回他的课程列表，直接在 DTO 或 VO 层组装你需要的数据格式，这样反而更清晰。实体类、DTO、视图对象分离，这个问题就能绕开一大半。

4.6 答辩前必做的自测清单

项目做完到答辩之前，我个人建议按下面这个清单完整过一遍，能避免 90% 的现场事故。这直接关系到你演示的信心和分数。

第一，从零开始部署测试。把数据库删掉，重新执行建库脚本，从初始数据开始跑。逐一点一遍：登录、教师新增、编辑、删除、分页、筛选、排课、课表查看、密码修改、退出登录。看看有没有字段没展示、查询条件失效这类低级问题。

第二，检查异常输入。比如新增教师时工号填重复的，排课时选同一时间段，登录时输入错误密码，看系统会不会给出友好提示，而不是白屏报错。这一点非常重要，很多评委喜欢现场输入极端数据来测试你的代码质量。

第三，检查空数据状态。如果某张表里没有数据，页面能不能正常显示“暂无数据”的提示，还是抛 500。你至少要在数据库中建一条数据再删掉，测试列表页在空数据下是否正常。

第四，检查打包流程。在本地用mvn clean package打出可执行 jar，然后java -jar xxx.jar启动，确认项目能脱离 IDEA 独立跑起来。不然现场演示用的是你笔记本上 IDEA 的临时环境，换台电脑就启动不了，会很尴尬。

第五，备份演示数据。演示前准备好至少 10 条教师数据和 5 门课程数据，包含不同职称、不同院系，方便现场演示搜索和筛选功能。

第六，预演一遍讲解词。控制在 10 分钟以内，先讲项目背景和功能结构，再讲技术栈和数据库设计，最后做功能演示。中间穿插讲一两个你解决过的问题，比如分页优化或拦截器配置，这会让答辩老师觉得你是真正在做项目，而不是搬代码。

最后说两句实际体会

教师信息管理系统做下来，我个人最大的体会就是：毕设项目不在于选题多炫，而在于你有没有把一个有限范围的系统做完整、做扎实。从需求梳理到表结构设计，从登录鉴权到多对多排课，这中间每个环节都踩过了自己的坑，而正是这些坑堆出了你对 Java Web 开发的理解。

决定动手之前，先把数据库表结构画明白，把角色流程走一遍，后面写代码会顺很多。我见过太多同学一上来就建项目、写 Mapper，结果没两天就回来返工表结构。设计这种事，前期多花一天，后期省一周。等跑通核心链路以后，再按 ECharts、Excel 导出的方向一点点加分，流程会非常稳。

这个选题后续还能扩展的方向也很多，比如加一个课程评价功能，或者按学期生成教学工作量统计表。你如果准备拿它往简历上写，就把排课模块做成亮点，把表和表之间的关联关系讲清楚，面试价值马上不一样。代码写到吐的时候，想想答辩时指着数据库设计页面，把每一张表、每一个字段讲清楚的那种感觉，值得的。