每年毕业设计季都会有一批同学带着"员工信息管理系统"这个题目来找我，前两年我还没太当回事，觉得这种经典CRUD系统想翻车都难。直到有个同学开题后第二周跑来问我说，Spring Boot启动报错找不到数据源，我远程一看，他连MySQL都没装，配置文件里却写了大半天连接参数——那一刻我才意识到，这个"简单"的项目，其实处处都是坑。
这篇内容就是围绕"基于Java+Spring Boot+MySQL的员工信息管理系统"整个开发流程来写的，从表结构设计、环境搭建、核心功能实现，到答辩前的收尾自查，每一条都是我自己带项目时反复被问到的问题。适合正在做这个题目的学生，也适合第一次用Spring Boot做完整Web系统的开发者参考。我尽量把踩过的坑、排查的思路和为什么这样做都讲清楚，而不是只丢给你一堆配置代码。
1. 开工前别急着写代码：先确定表结构和权限模型
很多同学拿到题目第一反应就是"先建个Spring Boot工程再说"，这个顺序其实是错的。员工信息管理系统这种题目，业务逻辑不复杂，但它有一层隐藏的复杂点——权限模型和家长式评审的偏好，都在表结构里就定下了。表设计一旦跑偏，后面的业务代码全是白写。
1.1 员工表、部门表、用户表三张核心表怎么设计才不返工
员工信息管理系统最基础的表就是员工表，但"员工"和"系统用户"不能混在一张表里。我见过不少同学的源码，员工表里放着password字段，登录就用员工工号去查，这种设计答辩时很容易被问倒。合理的做法是拆成两张表：员工表（employee）存真实的职员信息，用户表（sys_user）存登录账号和角色，中间用employee_id做关联。
员工表里至少要有：工号、姓名、性别、出生日期、手机号、邮箱、部门ID、岗位、入职日期、在职状态、创建时间、更新时间。这里工号不要用自增主键，建议单独设置一个业务工号字段（比如emp_no），这样即使数据库主键是雪花或自增，业务上依然能稳定地区分员工。部门ID关联部门表，这样部门调整时只要改关联，不用动员工数据本身。
用户表就是经典的id、username、password、role、employee_id、status。密码必须存加密后的值，我推荐用BCrypt，Spring Security自带这个算法，不需要额外引包。
部门表更简单：id、dept_name、parent_id、manager_id。如果你的毕设题目只是入门带CRUD，那这些都够用了，不需要搞组织架构树。但表结构里这两个字段建议留着——有些评委喜欢追加提问"部门如果要分级怎么处理"，你有了字段就能现场演示。
1.2 权限模型建议用最朴素的角色判断，不要上Spring Security全家桶
员工信息管理系统如果是本科毕设，权限需求基本就是"管理员和普通员工两种角色"。这种情况我最推荐的就是用一个拦截器或者AOP，在请求进入Controller之前判断一下session里的角色，管理员能访问管理接口，普通员工只能查看自己的信息。这样代码简单、可控，答辩时说逻辑也清楚。
有同学一上来就整合Spring Security加JWT，结果光配置类就写了几百行，登录逻辑和权限表达式绕来绕去，最后演示时一个注解配错，接口全部403，反而把自己逼到墙角。不是说Spring Security不好，而是毕设场景里它的复杂度超过了题目本身的复杂度。系统设计讲究匹配需求，这一点在答辩时也是一个加分理由——你是有意为之，不是不会用才不用的。
当然，如果你做的是比较完整的企业级版本，用Spring Security也是可以的，但一定要确保自己清楚每个过滤器和配置项的作用，不然评委深挖一个"为什么这里要放行"你就卡住了。
2. 环境搭建与工程初始化：版本匹配是个隐形大坑
这个环节是翻车率最高的地方，比写业务代码还容易出问题。很多同学报错后第一时间就去查代码，其实问题大概率出在版本不匹配上。
2.1 JDK、Spring Boot、MySQL、Maven的版本搭配怎么选最稳
我给你一个在多个环境中验证过、几乎不会出问题的组合：JDK 8 或 JDK 17 搭配 Spring Boot 2.7.x，MySQL用5.7或8.0，Maven用3.6以上，MyBatis用MyBatis-Plus 3.5.x。这个组合的优点是网上遇到的人最多，你遇到任何报错，搜索一下都能找到答案；缺点是技术上不算最新，但对毕设来说足够。
如果你的学校预装了更高版本的JDK（比如JDK 21），建议优先考虑Spring Boot 3.x。Spring Boot 3要求JDK 17起步，同时把javax包改成了jakarta，很多老教程里的代码直接复制会编译报错。这种问题查起来特别费时间，因为报错信息不会直接告诉你"是包名不对"，而是给你一堆找不到符号或ClassNotFound。所以如果你跟着网上教程学，先看一下教程用的Spring Boot版本，再决定JDK版本，千万别混着来。
MySQL 8.0要注意驱动配置：com.mysql.cj.jdbc.Driver而不是旧的com.mysql.jdbc.Driver，同时URL里建议加上useSSL=false和serverTimezone=Asia/Shanghai，不然会踩时区或SSL证书的坑。我在项目里遇到不下五次这种问题，其实都不是你代码写得不对，就是驱动和URL配置问题。
2.2 用Spring Initializr生成工程时，依赖到底该勾哪些
我建议从头到尾只引入最核心的几样：Spring Web、MyBatis（或MyBatis-Plus）、MySQL Driver、Lombok。这四个就能撑起整个业务了，其他像Spring Security、Validation、Swagger这类，如果你不是特别熟，完全可以后补，免得一开始把依赖搞得太复杂。
Lombok是省代码神器，但有个细节：有些学校的IDE环境没装Lombok插件，代码里用了@Data、@Slf4j注解后编译直接失败。遇到这种情况不用慌，把注解去掉，手动写getter/setter和logger就行。更稳妥的做法是，开工前先确认一下你的IDE是不是已经集成了Lombok，IDEA新版基本都自带，但Eclipse没那么省心。
工程目录结构我建议按controller、service、mapper、entity、common、config这几层来分。entity放数据库映射实体，common放统一返回结果和异常处理。有些同学喜欢把所有类都堆在一起，运行没问题，但答辩时评委看一眼工程结构就会觉得你缺少工程化意识。
2.3 配置文件里的坑：端口占用、时区、日志别等爆了才看
application.yml里最容易忽略的参数我列一下：
- server.port默认是8080，如果本机被其他程序占了，你启动日志会报
Port already in use。排查方法很直接：netstat -ano找到占用进程PID，然后去任务管理器结束它，或者在配置里换个端口（比如8088）。有些同学卡在这里一个小时，其实就是杀一下进程的事。 - mybatis-plus的mapper-locations配置要写对路径，常见写法是
classpath*:/mapper/**/*.xml。路径错了启动不会报错，但一调用查询就会报Invalid bound statement，这个错误在后文排查里会专门聊。 - 日志级别建议先设成DEBUG跑几天，特别是有SQL输出的需求时，MyBatis的SQL日志能让你快速定位是SQL写错了还是参数传错了。正式提交前再调回INFO，这个细节很多人忽略。
3. 核心功能落地：登录鉴权、员工CRUD、分页查询的实现细节
表结构和环境都准备好了，接下来才是真正的业务代码。这个系统的功能离不开下面这几个模块，我按实现顺序来讲。
3.1 登录模块：为什么不要用AOP做登录校验
登录模块很多教程会直接用Spring Security解决，但我们前面说了，要做朴素版本，那就必须处理一个问题：怎么在每个接口里拿到当前登录用户？
我的做法是写一个LoginInterceptor实现HandlerInterceptor，在preHandle方法里检查session或Token，通过则放行，否则打回登录页。简单来说：登录取session，访问接口时拦截器读session，读到就放行，没读就跳转或者返回JSON。这个套路既清楚又好讲。
为什么不用AOP？因为AOP适合对特定方法做增强，而你登录校验是需要作用于"几乎所有Controller方法"的，用拦截器配置addPathPatterns和excludePathPatterns就可以灵活排除掉登录接口、静态资源这些路径。AOP写起来还要自己定义切点和环绕逻辑，拦截器天然就是HTTP层面的事，语义更准确。
密码校验用BCryptPasswordEncoder的matches方法，注意前端传过来的密码是明文，数据库里是密文，直接查询是查不出来的——这也是为什么很多同学做登录时明明账号密码都对，却一直登录失败的原因之一。
3.2 员工CRUD的Service层：事务注解和业务校验不能省
新增员工时，工号不能重复、手机号格式要校验；修改员工时，部门ID要存在；删除员工时，要判断有没有关联的用户账号——这些都是评审喜欢问的"业务完整性"问题。实现起来就是在Service里加判断逻辑，然后调用Mapper，记得在涉及多表写入或更新的方法上加@Transactional。
事务的作用，打个比方：执行两个操作，第一个成功、第二个失败时，系统应该回滚到最开始的状态，而不是留下一条"半成品"数据。比如新增员工的同时要创建用户账号，账号这条写入失败了，员工那条就应该撤销掉，不然数据就对不上了。@Transactional加在public方法上就行，但要注意它只对RuntimeException生效，如果你代码里捕获了异常没往外抛，事务是不会回滚的——别问我怎么知道的，这个问题我排查过整整一个晚上。
删除员工时更要注意，如果该员工ID在用户表里被引用，外层再执行删除就会报主键外键冲突。处理方式有两种：业务上不允许直接删除，改成"离职状态"，这种叫逻辑删除；或者先删用户表再删员工表。毕设场景推荐第一种，更贴近企业实际情况，答辩还能多说一层"数据留痕"的考虑。
3.3 分页查询的三种实现，以及为什么推荐MyBatis-Plus的分页插件
分页展示是员工管理系统里老师们必然会问的一个模块。实现方式主要有三种：手写MySQL的LIMIT offset, size配合PageHelper，或者使用MyBatis-Plus内置的分页插件。
手写LIMIT的问题在于，你要自己去计算offset和total，还要写Count查询，逻辑本身不复杂，但每个列表页都要写一遍就非常枯燥，而且很容易漏掉排序和条件判断。
MyBatis-Plus的Page对象加上分页插件，接口变成selectPage(page, wrapper)，返回结果里直接带records、total、current、size，前端拿过去直接渲染就行，省心很多。唯一要注意的是，分页插件必须配置PaginationInnerInterceptor，很多人只引入了MyBatis-Plus依赖却忘了加这个配置，结果分页SQL根本不会生效，查出来永远是全量数据，列表页面显示就出问题。
分页查询的排序问题也容易出坑。按入职时间倒序排列是常见需求，orderByDesc("hire_date")写在wrapper里没毛病，但如果你用字符串拼接排序字段，就要严防SQL注入。这种安全细节评委很喜欢问，答辩前看一眼自己的代码，别让order by参数直接拼SQL进去。
3.4 统一返回结果：前端和后端少扯皮的关键
写接口的时候建议定义统一返回类，比如Result<T>，里面包含code、message、data三个字段。成功时code为200，失败时code为500，登录失效为401。这样前后端对接时有一个固定的数据契约，前端不用每个接口都判断不同的返回结构。
这个设计看着多了一点点代码量，但对整体项目质量的提升是肉眼可见的。答辩演示的时候，你能明确说清楚"这个项目里所有接口都是统一返回格式"，本身就体现出了工程规范意识。
4. 实测中反复踩过的几个Bug：完整的排查链路，不是直接给答案
下面这4个问题是我在实际项目带写中几乎百分之百会遇到的高频坑，我不直接给最终答案，把排查过程写出来，你以后真的遇到了就能照这个思路一步步缩小范围。
4.1 启动失败："Invalid bound statement (not found)"到底错在哪
现象：工程能启动，首页能访问，但一点"员工列表"按钮，后台日志里蹦出一行org.apache.ibatis.binding.BindingException: Invalid bound statement (not found): com.example.mapper.EmployeeMapper.selectPage。新手第一反应是"Mapper接口方法写错了？"，但其实这个报错的意思是MyBatis在运行时找不到Mapper对应的SQL语句，根本原因通常是三种：Mapper接口和XML文件没有对应上、XML文件的namespace写错、或者XML文件根本没被扫描到。
我那次排查的步骤是：第一步，打开target目录看XML文件是否被打包进classes里。不看不知道，一看发现target/classes/mapper目录是空的，而XML文件就躺在src/main/resources/mapper下面。第二步，看pom.xml，发现没有把resources目录下的xml文件在build阶段include进去，导致Maven打包时把XML过滤掉了。第三步，在pom.xml的build节点里加上<resources>配置，指定src/main/resources下**/*.xml也要被打包，重启后问题消失。
这个错还有一个隐蔽变种：你用了MyBatis-Plus的注解SQL，结果一个方法名在Mapper接口里有，XML里没有，也报这个。如果你项目里混合使用注解和XML，优先统一用一种方式。AnnotationSQL写起来快，但复杂SQL堆在注解里可读性差，我建议核心的增删改查用MyBatis-Plus自带方法，复杂统计查询才用XML写。
4.2 明明密码正确，登录却一直"用户名或密码错误"
这个问题的排查链路很有意思。现象：注册之后用注册的账号密码登录，后端一直返回"用户名或密码错误"。很多同学第一反应是不是密码加密方式不对，于是在加密/解密代码之间来回断点打了一下午。
我当时的排查思路是：先把登录接口请求参数打出来，发现前端的password确实是明文，后端拿到后先调用BCryptPasswordEncoder.matches方法去和数据库里的密文比对，返回false。然后把注册时加密后的结果和数据库里存的值做比对，发现数据库的值比注册时打印的密文长惨了，而且内容还不一样——这才是关键。
原来数据库字段设置的VARCHAR(60)，BCrypt出来的密文长度正好是60位，按理说不会截断。但当时那个库是UTF-8字符集，字段又用的是60，看起来没问题。再一看，真正原因是注册接口里密码在进入Service之前又被某段代码做了一次base64或重复加密，等于你拿"第二次加密后的密文"去和"一次加密的结果"对比，永远匹配不上。当时是代码里有一个过时的MD5加密工具方法，注册走的是新代码、登录走的是老代码，两边的算法不一致。
所以遇到登录失败先别急着改密码算法，先在校验入口打日志，把"用户传入值"和"数据库密文"两段都打出来，看它们各自是什么格式、长度多少，再判断是编码问题、算法不统一还是压根查错了用户。日志排查法永远是这些诡异问题的最快解法。
4.3 分页接口返回total正确，但records总是空
这是一个特别容易让人懵的问题。现象：调用分页接口，返回的total是10，说明Count查询统计到了数据，但records数组是空的，页面上一个员工都不显示。total对但records空，说明SQL查询本身出问题了，而不是没有数据。
排查流程：先看MyBatis日志里打印的查询SQL，我那次打印出来是SELECT * FROM employee LIMIT ?，问号那里参数绑定成了0，其实应该绑定成5才对。往前追查，发现前端的请求参数是current=1，size=5，但后端接收分页参数的DTO字段名写的是pageNum和pageSize，和前端传的current、size对不上，导致current默认被解析成0，limit起始位置就是0。0在数据库里查出来的其实是"第一行开始"，看着应该有数据啊——再一查，原来那条SQL前面还被动态拼接了一个WHERE status = ?的条件，status参数没传进来，默认是null，MySQL的WHERE status = NULL永远不成立，所以records为空。
这个排查的收获点在于：total和records是两条SQL查出来的。Count语句可能因为没带WHERE或参数不同而统计到数据，而真正的列表SQL如果条件不对，就会返回空。以后遇到"总数有值、列表为空"的矛盾现象，基本可以判断是LIST SQL的条件或参数问题，而不是数据本身不存在了。
4.4 启动时数据源初始化报错：URL、密码、驱动顺序，哪个最容易被忽视
这个报错往往在工程启动第三秒就崩了，SprinBoot打出一大段红字，核心一行是Cannot connect to MySQL。第一次遇到这问题的人90%会去改密码，还有一部分人改端口，但其实最常见的坑是：服务没启动。我跟你说，步骤必须是这样：
第一步，检查MySQL服务是否真的在运行。Windows下任务管理器看mysqld进程，或者命令行执行mysql -uroot -p测试能不能连进去。连都不连通，代码里配置一百遍也没意义。
第二步，检查URL里的参数。jdbc:mysql://localhost:3306/employee_db?useSSL=false&serverTimezone=Asia/Shanghai&characterEncoding=utf8这几个参数看着啰嗦，少了任何一个都可能出现连接超时或乱码问题。数据库名要存在，不然会报Unknown database。
第三步，检查pom.xml里有没有引入MySQL驱动。有些新手从教程里复制了配置文件，却漏掉了依赖，Spring Boot的自动配置在看到Driver类不存在的时候不会报"缺少依赖"，而是报一串很长的Unable to determine a suitable driver class。
排查的顺序一定是：驱动依赖、MySQL服务、URL参数，最后才是账号密码。因为前三个问题占了80%以上的失败原因，你先把它们排除掉，再去怀疑密码心情都会好很多。
5. 答辩前收尾自查：演示数据、异常处理和演示脚本要提前跑三遍
功能写完之后，很多同学以为就结束了。但是验收答辩的时候，下面这类"最后一分钟翻车"每年都会上演：数据库连的是本机，到了答辩教室网络变了连不上；演示时新增员工工号重复，后台直接报500错误堆栈；或者翻页时因为mock数据太少看不出效果。这些都需要在收尾阶段提前处理掉。
5.1 数据库初始化脚本和演示数据要单独整理成SQL文件
不要再手动往数据库里插数据了，把你的建库、建表、初始数据整理成一个init.sql，放在项目根目录的sql/文件夹下面。里面有几点要注意：建表语句要写清楚字段注释，数据要覆盖典型场景——比如员工状态要有在职、离职两种，部门至少要有三四个，员工总数最好插个二三十条，这样分页效果才明显。
演示数据还有一个细节：入职日期不要全集中在同一天，分散一些，这样才能演示按时间排序的功能。工号也不要一律连续编号，稍微错开，方便演示模糊查询。
如果你的数据库是MySQL 8，注意字符集写成utf8mb4，否则中文注释可能乱码。初始化脚本写好后，在干净的机器上从零执行一遍，确保两分钟内能从空库到全量数据，这个时间控制很关键。
5.2 全局异常处理器要给用户友好提示，而不是一坨报错堆栈
评委点击按钮时最怕看到的页面就是白屏加一大串红色异常日志。解决办法是写一个@RestControllerAdvice全局异常处理器，把Exception统一捕获，返回Result的错误格式。
这里有个容易被忽略的点：主动抛出的业务异常（比如"工号已存在"）最好单独定义个BusinessException，在全局处理器里单独处理，返回提示信息。数据库层面的异常（比如唯一键冲突）不要直接抛给用户，而要捕获后转成业务提示，比如"工号重复，请检查"。这个细节体现了你对系统可用性的理解，属于答辩加分项。
5.3 演示脚本：先走主流程，再走分支，演练三遍不嫌多
正式演示前，写一个演示脚本。也就是说，你想好用哪几个账号登录、要新增什么员工、搜索什么关键词、翻到第几页，提前在脚本里写清楚。很多人答辩时手忙脚乱，不是因为项目不行，是因为现场演示路径没排练过。
建议主流程是：管理员登录、查看员工列表、新增员工、编辑员工、搜索员工、分页翻页、最后删除。再准备一个副流程：普通员工登录、只能查看自己信息、访问管理员接口被拦截。这两个流程能覆盖掉绝大部分功能点，评委无论问哪个角落，你都能在系统里找得到对应面。
我还会建议准备一个"演示时尽量不出错"的小技巧：新增员工时输入一个不容易撞车的手机号和工号，不要在演示现场敲一长串容易被自己输错的内容。这个看起来像玄学，但真的能救命。
6. 关于这份毕设的经验总结
每个毕业季都会重复一样的故事：选题时觉得简单，中期被各种环境问题折磨，答辩前又开始焦虑。员工信息管理系统这个题目能成为经典，正是因为它覆盖了Web开发最核心的几个环节——表结构设计、用户认证、CRUD、分页、事务、异常处理。把这些做完做扎实，你获得的不是一个"应付答辩"的Demo，而是一个能让你自信讲出"为什么这样做"的完整项目。
我个人带完这么多项目后的体会是：这个题目的上限和下限差距极大。下限是堆一堆Controller加上Mapper就交差，上限是你把每个设计决策都讲出道理来——为什么拆三张表、为什么用拦截器而不是注解、为什么删除用逻辑删、为什么异常要全局捕获。评委听到的不是"我会用框架"，而是"我懂工程"，这个区分度在答辩时非常明显。
最后分享一个我常用的时间分配建议：表格和权限模型的设计花一天，环境搭建最多两天，核心功能写一周，剩下的时间全部用来调Bug和准备答辩演示。别把前两步拖太久，也别在最后一天才开始准备演示脚本。按这个节奏走，这个毕设应该可以进展得很顺利。
