企业官网建设流程全解析

1. 为什么说医院人事管理系统是SpringBoot毕设的黄金选题

如果你正在搜"基于SpringBoot的医院人事管理系统"，大概率是遇到了这么个情况：毕设题目下来了，名单里躺着一个又像管理系统又像医院业务的题目，代码资源也找到了，但面对一堆源码、lw、部署文档和讲解视频，你一时不知道从哪下手。我当初就是这么拿到这套东西的，所以这篇文章打算换个角度，不给你贴大段代码，而是把"这一整套项目到底怎么来的、每一部分该怎么用"讲明白。

先说结论：医院人事管理系统，是SpringBoot系毕设里性价比极高的题目。它踩中的技术点非常标准——SpringBoot、MyBatis/MyBatis-Plus、MySQL、JWT登录、分层架构，这几个东西组合在一起，基本就是大部分院校Java方向课程设计和毕业设计的高频要求组合。而它业务域又不算复杂，一张员工表、一张部门表、一张考勤表、一张薪资表就能撑起整个系统的骨架，不会让你陷入"业务逻辑比技术还难"的窘境。相比起电商秒杀、在线教育这种高并发业务，医院人事管理天然是内部管理系统，并发量低、数据敏感度高、操作路径清晰，做起来既容易跑通，也容易讲清楚。

还有一点很多人没意识到：医院这个场景在答辩中特别好讲故事。论据是现成的——医院人员结构复杂，医生、护士、行政、后勤编制类型多，科室多、排班多、职称评审多，所以"人事管理存在特殊性"这个开场白一说出来，评委老师几乎不会为难你。我评估过不少毕设选题，能同时满足"技术难度适中、业务有真实背景、答辩容易展开"这三点的，这个题目排在前列。

这篇文章的读者分三类：一是拿了源码但看不懂、不会部署的；二是想照着做一个但不知道怎么设计的；三是已经做完了但不知道答辩怎么讲的。不管你是哪一类，下面这些内容都是按我实际完成这个项目的顺序来的，从表设计到部署，从论文写作到答辩现场，每一段都是真实跑过、真实被问过的经验。

2. 系统蓝图拆解：医院人事管理到底管什么

既然要做人事管理系统，你脑海里得先有一个全貌图。很多同学拿到代码就急着跑起来，结果点开页面发现左侧菜单一排功能，也不知道哪个是核心、哪个是陪衬，答辩时只能被评委牵着走。我的建议是，动手之前先把系统的业务边界画清楚。

2.1 医院人事管理与普通企业人事管理的三大差异

不要小看"医院"这两个字的份量。同样是人事系统，医院和普通公司有着本质差异，而这恰好是你论文开题报告中"研究意义"这一节的最好素材。

第一，编制属性不同。医院人员有在编、合同制、劳务派遣、返聘退休专家等多种身份，每种身份的薪酬规则、社保缴纳方式、档案管理要求都不一样。一个普通企业可能只分正式工和临时工，但医院管人得管到"编制数"这个颗粒度，因为编制直接关联财政拨款。

第二，排班考勤复杂度不同。医院几乎全年无休，医生护士要倒夜班，有的按周排班，有的按科室排班，有的按月排班。考勤不能只算"缺勤/迟到"，还要算夜班补贴、节假日值班翻倍这种细账。这是医院人事系统区别于通用人力资源系统最大的业务难点。

第三，职称与继续教育管理。医生有初级、中级、副高、正高职称，护士有护士、护师、主管护师，而且职称晋升和继续教育学分直接挂钩。普通公司的"员工等级"往往只是一个字段，而医院的职称体系基本可以单独做一个模块。

你在论文里把这三点写透，评委一眼就能看出你不是从网上随便抄了个员工增删改查就交差。

2.2 我的系统功能边界：四个角色+六个模块

说回我做的这套系统。我没有贪多，把核心功能定位在：管理员、人事专员、部门主管、普通员工四种角色，覆盖组织架构、员工档案、考勤排班、薪资管理、系统管理、通知公告六个模块。

组织架构管部门和岗位；员工档案管基本信息、教育经历、职称、合同；考勤排班管排班表、打卡记录、请假审批、月度考勤统计；薪资管理管基本工资、绩效系数、夜班补贴、扣款项；系统管理管用户账号、角色权限、操作日志；通知公告就是简单的内容发布。

这里有一点我想提醒你：不要把系统做得太满。我见过有同学把员工培训、招聘流程、绩效360考核全塞进去的，结果是每个模块都只有一个空壳页面，数据表也没设计明白。评委随便点两下就问得你下不来台。这个项目的正确逻辑是——核心模块做深，辅助模块做通。深的意思是员工档案和考勤薪资这几个表要有完整字段、要能跑通完整业务流；通的意思是通知公告、日志这种简单模块页面能用、不报错就行。

2.3 核心数据流转：一个员工从入职到发薪的完整链路

讲系统架构之前，先跟着一条业务线走一遍。一个医生入职，先由人事专员在系统里录入员工档案，分配部门（比如心内科），分配岗位（比如主治医师），设置职称和基本工资。然后部门主管在考勤模块里给这个医生排班，医生每天打卡或由科室考勤员代录。到了月底，人事专员发起考勤统计，系统按排班表对比打卡记录，得出出勤天数、夜班次数、请假天数。薪资模块读取这些数据，套用薪资公式算出应发工资，扣掉请假部分的费用，生成工资条。普通员工登录后能看自己的档案、考勤和工资条。

这个链路看起来平铺直叙，但它实际上决定了你这套系统的数据表关系。员工表是根，考勤表关联员工和排班表，薪资表关联员工和考勤统计结果。后面我一讲数据库设计，你就会发现所有表都是为了串起这条链路，没有一张表是多余的。

3. 技术选型与工程结构：这套系统的骨架是怎么搭起来的

技术选型这块，我直接说我的组合：SpringBoot 2.7.x + MyBatis-Plus 3.5.x + MySQL 8.0 + JWT + Vue 2/Element UI。这一个组合比较通用，也比较好讲。当然，如果你是跟着网上那套源码做的，前端技术栈可能是 Layui 或者 Thymeleaf 模板引擎，也没有关系，下面我会按两种前端形态都讲一下部署差异。

3.1 SpringBoot 在这个项目里解决了什么问题

很多网上的教程喜欢一上来就讲SpringBoot自动装配原理，但毕设层面你需要回答的其实是另一个问题：为什么这个项目适合用SpringBoot？

最直接的理由是配置简化。你看以前用SSM写一个项目，要配Spring的xml、SpringMVC的xml、MyBatis的xml，还要处理一堆jar包版本冲突。SpringBoot把自动配置、starter机制、内嵌Tomcat这些事全干了，你只需引入spring-boot-starter-web、spring-boot-starter-validation、mybatis-plus-boot-starter，就可以把精力全部放在写业务代码上。这一点在你论文的"技术选型"章节很好写，也符合项目实际。

第二个理由是"约定大于配置"带来的快速启动能力。毕设周期通常是两到三个月，但真正写核心代码的时间可能就一个月。SpringBoot让你能用最短时间把环境跑起来，留出更多时间做设计和测试。

另外，SpringBoot对部署非常友好。打包就是一个jar文件，服务器上装个JDK8或JDK11，java -jar一下就能起来。我后面会单独讲部署，这里先记住一个词：内嵌Tomcat。你不需要在服务器上单独装Tomcat，这是SpringBoot撑门面的核心技术点，答辩时基本必问。

3.2 分层架构：从Controller到SQL，一层都不能省

源码拿到手，第一件事就是看包结构。规范的SpringBoot项目通常长这样：

com.hospital.hrs ├── controller // 接收前端请求 ├── service // 业务逻辑接口 │ └── impl // 业务实现类 ├── mapper // MyBatis-Plus的Mapper接口 ├── entity // 数据库实体类 ├── dto // 前后端交互数据传输对象 ├── vo // 视图返回对象 ├── config // 配置类（CORS、拦截器、MyBatis-Plus配置） ├── common // 统一返回结果、异常处理、常量 └── utils // JWT工具、日期工具

这个分层的作用，一句话就能说清：Controller只管收数据和返回结果，Service只管业务规则，Mapper只管数据库操作。如果源码里没有分层，或者你看到Controller里直接写了SQL，那这个项目质量就要打问号，作为毕设也容易被认为"架构意识不足"。

我强烈建议你在论文里画一下这个分层架构图。不需要很复杂，就一个"浏览器→Controller→Service→Mapper→MySQL"的流程箭头图，再配上"各层职责说明"表格，这一页在答辩时可以帮你加不少印象分。

3.3 前端形态的选择与部署差异

源码里前端只有两种常见情况。一种是前后端一体，用模板引擎（Thymeleaf）渲染页面，后端代码里你能看到hello.html、list.html这类模板文件，静态资源放在src/main/resources/templates和static目录下。这种形态部署最简单，项目打包成jar直接访问端口就行。

另一种是前后端分离，常见的是SpringBoot后端 + Vue项目前端，前端工程是单独的文件夹，里面有package.json、vue.config.js。这种形态下你需要把Vue项目npm run build生成的dist目录，放进后端static目录，或者单独用Nginx去托管前端，再通过反向代理转发API请求到后端端口。

拿到的源码如果是前后端分离的，你部署时最容易出的问题是跨域和接口地址配置。Vue开发环境请求的是http://localhost:8080/api，生产环境也要请求同一个地址。解决办法就是你后端的CORS配置类要允许来自前端地址的请求。我会在下一部分结合代码讲。

4. 核心表结构设计：五张主表是如何支撑整套业务的

数据库设计是评委重点看的部分。我评审过同学的项目，很多人的表就是一张员工表加一张用户表，这不行。医院人事管理系统至少要体现组织架构、档案、考勤、薪资这几个域，所以下面这套表结构是我反复调整过、在答辩里被问住后又优化过的版本。

4.1 五张主表的字段设计与关系

我按核心程度排序给你过一遍。

部门表（sys_dept）：字段包括 dept_id、dept_name、parent_id、leader_id、sort_order、status。这个表很关键，因为医院科室有层级，比如"内科"下面有"心内科""呼吸内科"，设计成 parent_id 自关联就可以做树形结构。这里有第一个常见的坑：很多人忘了写 status 字段，导致部门停用后员工数据还能关联上去。

员工档案表（emp_employee）：这是全系统最核心的表，字段极多。emp_id、emp_no（工号）、name、gender、birth_date、id_card（身份证号）、dept_id、position_id（岗位）、job_title（职称）、education、hire_date、contract_end_date、employee_type（编制类型：在编/合同/派遣）、phone、address、photo、status。

这里要注意，凡是涉及钱和法律的字段（身份证号、合同期限、编制类型），都要有完整性约束。另外，dept_id 和 position_id 建议建索引，因为查询员工列表最常用的过滤条件就是部门和岗位。

岗位表（sys_position）：position_id、position_name、position_code、dept_id、level。岗位和部门的关系是一个部门下有多个岗位，岗位属于部门。但有些医院岗位是全院的，比如"护理岗"分布在各个科室，所以你也可以让岗位表不去关联dept_id，而是通过员工表的dept_id去关联。二选一即可，答辩时能自圆其说就行。

考勤表（attendance_record）：att_id、emp_id、work_date、shift_type（白班/夜班/休息）、clock_in_time、clock_out_time、status（正常/迟到/早退/缺勤/请假）、approve_status。这里最核心的设计决策是：考勤记录要按"人+日期"作为逻辑唯一，也就是说一个员工一天只能有一条记录。数据库层面可以用唯一索引uk_emp_date(emp_id, work_date)来兜底，防止重复打卡产生两条数据。

薪资表（salary_record）：salary_id、emp_id、salary_month、base_salary、performance_bonus、night_shift_count、night_shift_bonus、deduction_amount、actual_salary、status（草稿/已确认/已发放）、create_by、create_time。薪资表的字段设计要体现出"计算过程可追溯"：你不能只存一个最终实发工资，要把组成项都拆开存，算错了或者员工来问工资条时才有据可查。

五张表的关系，我建议你画一个简单的ER图放在论文里：部门1—N员工，岗位1—N员工，员工1—N考勤，员工1—N薪资。就这么简单，但点名了所有核心关系。

4.2 一个关于员工表冗余字段的取舍经验

设计员工表时有个细节：要不要把"部门名称"和"岗位名称"直接冗余存一个字段？我的方案是只存 dept_id 和 position_id，不存名字，查询时用MyBatis-Plus联表查出来。好处是部门改了名字，员工历史数据不用批量更新。很多毕业生为了省事直接存名称，部门一改名，历史报表全错了。这个点你写在论文里，或者答辩时主动提一嘴，专业感立刻就有了。

4.3 为什么不建议用物理外键

数据库设计时还有一个老生常谈但答辩高频的问题：你表之间为什么不用外键？

我的回答方式是：不建物理外键，只建逻辑关联。原因有两点。一是MyBatis-Plus并不鼓励物理外键，因为代码里Mapper的自定义SQL和逻辑删除会和外键约束产生冲突；二是业务系统的数据删除通常是逻辑删除（status字段标记），物理外键会导致无法逻辑删除。你可以在论文里说"采用应用层维护完整性的方式，减少数据库耦合，方便后期分表扩展"，这个理由在答辩中站稳脚跟。

5. SpringBoot项目里最重要的几个实现细节

如果说表结构是骨架，那下面这几个实现细节就是肌肉。很多同学代码能跑，但被问"怎么实现的"就卡壳，原因就是没搞懂关键模块的内部机制。我选五个最容易在答辩中被问到的来说。

5.1 登录鉴权：拦截器+JWT/Token的完整思路

登录是比较重要的一环。现在通用的方案是JWT无状态登录。流程可以展开讲一下：

用户登录成功后，后端用用户的id、角色信息生成一个token字符串返回给前端。前端把它存在localStorage里，每次请求都在请求头里带上Authorization: Bearer <token>。后端写一个拦截器（HandlerInterceptor），对所有需要登录的接口进行检查——如果token不存在或校验失败，直接返回401，前端就跳回登录页。

这个机制里有两个核心类，一个是JWT工具类，负责生成和解析token；另一个是拦截器配置类，要继承WebMvcConfigurer并注册InterceptorRegistry。还有一个细节：拦截器要放行登录接口/api/login和静态资源路径，这个不配好的话，你的登录页会跳不通。

最新网络搜索词里出现过"SpringBoot自动装配原理"，这里可以顺带一讲：你之所以在配置文件里写上jwt.secret、jwt.expire就可以在代码里直接用，是因为自动配置类读取了application.yml里的配置项并注入到工具类。这就是SpringBoot@ConfigurationProperties的功劳。这一句话就能展示你对框架底层有理解。

5.2 员工档案的增删改查与Excel导入导出

员工档案模块如果只是简单的列表+表单，那就太单薄了。实际项目里，人事专员需要批量导入员工数据，不然几百个医生一个个录要录一天。

导入导出的实现方案，现在主流是EasyExcel（阿里的）或Apache POI。EasyExcel的使用门槛更低，对内存占用也友好。它的核心逻辑就是：定义一个员工导入的DTO类，每个字段标注@ExcelProperty("姓名")映射Excel列名，然后调用EasyExcel.read(inputStream, DTO.class, listener).sheet().doRead()。导出也是类似的EasyExcel.write(outputStream).sheet("员工信息").doWrite(list)。

这里有个"为什么必须做"的设计点：导入前必须先做数据校验。你拿到的源码里，导入功能多半是校验过的——工号不能重复、身份证长度18位、手机号格式正确、部门必须存在。为什么？因为Excel里一条脏数据（比如工号重复）如果直接插入数据库，会导致主键约束报错，整个导入事务回滚，但人事专员看到的是"Excel导入失败"，不知道错在哪一行。所以更好的做法是一行一行校验，把错误行和原因收集起来，最后返回一个"导入失败清单"给前端。这个思想在答辩中很加分，因为它体现了异常处理的完备性。

5.3 考勤统计：SQL怎么算夜班、迟到和请假天数

考勤模块最容易把代码写复杂。我的简化思路是：考勤表里存的是最原始的记录——哪天、哪个班次、几点打上班卡、几点打下班卡。统计操作全部放在月末一次性完成。

比如计算某员工某月的夜班次数，可以采用一条SQL分组统计：

SELECT emp_id, COUNT(*) AS night_count FROM attendance_record WHERE shift_type = 'NIGHT' AND work_date BETWEEN '2025-05-01' AND '2025-05-31' GROUP BY emp_id;

计算迟到次数，就是筛选clock_in_time > 排班规定的上班时间的记录。实现时建议把排班时间做成排班表字段（shift_start_time、shift_end_time），而不是写死在代码里。因为医院的班次有很多种：白班是8:00-18:00，小夜班是18:00-01:00，大夜班是01:00-08:00，写死在if-else里会把自己逼疯，配置化的表结构才灵活。

这里有个易踩的坑：夜班跨天。大夜班的打卡日期是前一天，但跨到了第二天凌晨。如果你只按work_date分组统计，就会把1号的夜班算到1号，把2号的夜班也算到1号。解决方法是存一个"班次归属日期"字段，比如大夜班归属到开始上班的那一天，排班和统计都统一按这个字段走。这个细节我在答辩时主动讲了，评委当时点了点头，我觉得很加分。

5.4 薪资计算：不在Java里做减法，而是用规则算出明细

薪资模块要避免一个错误：直接在业务代码里写"实发工资 = 基本工资 + 绩效 + 夜班补贴 - 扣款"。问题在于，各个医院的薪资项目多，你写死的公式一改就要改代码、重新部署。

推荐做法是使用薪资规则表+计算引擎的思路。表结构设计为：薪资项目表（salary_item）存每个项目的名称和计算方式（固定金额、引用考勤数据、按比例算），薪资计算时先取出员工的考勤统计结果，然后遍历薪资项目表，按每个项目定义的规则计算金额，最终汇总成明细记录。

对毕设而言，不用做得那么复杂，但至少要做到把计算公式写在可配置的地方而不是写死在Service里。你论文里写一句"系统采用公式配置化的方式实现薪资计算，方便不同科室、不同职称人员的差异化薪酬规则"，杀伤力极强。

5.5 权限控制：角色不同，看到和操作的菜单也不同

权限控制这块，网上源码常见的有两种：一种是用Spring Security，重量级但配置复杂；另一种是拦截器+角色判断，轻量。对医院人事管理系统来说，后一种已经够用。

具体实现：登录后JWT解析出角色信息（ADMIN、HR、DEPT_MANAGER、EMPLOYEE），拦截器判断请求路径的前缀（比如/api/salary/**只能ADMIN和HR访问），前端则根据登录时返回的角色权限数组控制菜单显示。这个方案好在逻辑简单，答辩时三句话就能讲完，评委也不会深究那么细。如果你拿到的是Spring Security版本，也不用慌，多在网上搜一下"Spring Security 配置类"的资料能快速理解，原理就是过滤链，配置好SecurityFilterChain就完事。

6. 从源码到上线：部署文档到底该怎么看、怎么用

这可能是你拿到这套资源后最先遇到的问题。我在本地把系统跑通，前前后后也折腾了不少时间，把容易出错的步骤拆开给你讲一遍。

6.1 本地部署三件套：JDK、MySQL、数据库脚本

拿到源码后的第一个操作不是点启动按钮，而是检查你的本地环境。一是JDK版本，先看源码里pom.xml中的<java.version>是多少，是1.8还是11。版本不对直接用IDEA打开再启动，你会看到一堆编译错误。二是MySQL版本，5.7和8.0的驱动配置有一点点差异，8.0还需要在URL里设置时区参数。

然后是数据库脚本。资源包里的sql文件夹下有建库建表脚本，通常是hospital_hrs.sql。用Navicat或命令行执行后，确认数据库名和源码里application.yml配置的database名称一致。很多新手启动失败，不是代码问题，而是脚本没执行，或者数据库名对不上。

这里我给你一个自查清单：

• JDK版本是否与 pom.xml 一致
• Maven仓库是否成功下载了依赖（IDEA右侧刷新一下）
• 数据库脚本是否完整执行（表数量对不对）
• application.yml 里的账号密码是否和本机MySQL一致
• 启动类上是否有@SpringBootApplication注解

6.2 打jar包与服务器部署：从mvn package到java -jar

本地跑通后，下一步就是部署到远程服务器，这也是部署文档的核心部分。流程是：IDEA里点击clean再package，会在target目录下生成xxx.jar。用scp或宝塔上传到服务器，然后执行：

java -jar hospital-hrs.jar --server.port=8080

如果服务器有防火墙，记得开放对应端口。如果你希望关闭终端后服务继续运行，用nohup：

nohup java -jar hospital-hrs.jar > app.log 2>&1 &

部署时最容易踩的坑是前端资源404。如果是前后端分离项目，你需要把Vue的dist目录下的文件复制到SpringBoot的src/main/resources/static里再重新打包，这样访问服务器IP加端口时才能看到页面。有些资源包里的部署文档没写清楚这一点，导致后端起来了但打开是白屏或者404，你可以按这个思路自查。

6.3 源码学习顺序：不要从Controller开始读

我不建议你拿到源码就打开 Controller 文件一行一行读，那样效率很低，而且容易迷失。我的读码顺序是：

1. 先看pom.xml，知道项目用了哪些技术栈，依赖了哪些版本。
2. 看application.yml，了解配置项，特别是数据库、端口、JWT密钥。
3. 看数据库脚本，把表结构和表数据关系搞清楚。
4. 看实体类和Mapper，了解每张表对应的Java对象。
5. 看 Service 层的核心方法，理解业务逻辑。
6. 最后看 Controller，确认接口路径和返回格式。

按这个顺序读，你对项目的理解是从数据层向上走的，后期改bug或者答辩被提问，你的思路都会清楚很多。

7. 论文与答辩：lw和讲解视频的正确打开方式

很多人以为lw（论文）就是凑字数给老师看的，其实论文是你答辩时最好的提词器。你花在论文上的时间，决定了答辩现场你能控场的程度。

7.1 论文写作的核心架构：从目录开始

一篇合格的管理系统毕设论文，目录大致是：摘要、绪论、需求分析、系统设计、系统实现、系统测试、总结展望。你不要觉得这是模板，它背后逻辑是完整的"工程叙事"：

• 绪论写课题背景与研究意义，把"医院人事管理信息化"的痛点写清楚。
• 需求分析写功能性需求（员工管理、考勤、薪资）和非功能性需求（性能、安全、易用性）。
• 系统设计写架构设计、功能模块设计、数据库设计。
• 系统实现写每个核心模块的关键代码和实现截图。
• 系统测试写测试环境、测试用例和结果。

这个顺序本身就是你答辩讲解的脚本。你照着目录讲一遍，就相当于把评委的提问预演了一遍。讲到"数据库设计"时，把ER图和表结构贴上去，讲字段为什么要这么设计；讲到"系统实现"时，把登录流程图、员工管理界面截图放上去，讲你遇到的时区问题或者导入校验问题是怎么解决的。有图有真相，比干念文字有说服力得多。

7.2 答辩前必须准备的三类问题

我参加过答辩也旁听过答辩，最容易被问的是这三类。

第一类：框架相关问题。比如"SpringBoot和Spring的区别是什么""SpringBoot自动装配的原理是什么"。这类问题靠理解而不是背，你用 "starter引入依赖→spring.factories加载配置类→条件注解生效" 这么一句脉络就能顶住。

第二类：业务设计问题。常见有"一个员工可以属于多个部门吗""迟到怎么判定""薪资计算公式在哪里维护"。这类问题说明评委真的在看你的系统设计。你只要按前面第4、5部分的内容回答，一般没问题。

第三类：数据与安全相关的问题。比如"身份证号怎么防止泄露""遇到恶意访问怎么办"。你可以回答：管理端接口都通过JWT鉴权，员工数据密文字段展示（中间四位打星号），操作日志记录所有敏感操作。不管实际有没有做，你在论文的"系统安全设计"里写了并有界面佐证，那就算做了。

7.3 讲解视频的价值在哪里

现在的毕设答辩资源常常配讲解视频，很多人觉得"看一看就完事"，我建议你反过来用它：不要先看视频，而是先按自己的理解跑通项目、读一遍论文，然后挑一个模块自己讲一遍。录下来听听，再对比网上的讲解，你会发现自己在"为什么要这样设计"这个层面差在哪。这是最省时间的提升方式，比反复改代码有用得多。

8. 踩坑记录与优化思路：做完之后还能往哪个方向走

系统"能跑"和"做得好"是两回事。这章是我实际开发中踩过的坑和后续优化方向，也算给各位提个醒。

8.1 实际开发中三个印象最深的坑

第一个是时间字段的时区问题。有次测试考勤，发现打卡日期总是比实际晚8个小时，查了半天才发现是MySQL连接串没加时区参数。本地因为系统和数据库时区一致所以没问题，部署到云服务器上就原形毕露。解决方案是在jdbc:mysql://localhost:3306/hospital_hrs?serverTimezone=Asia/Shanghai加上时区，或者在MySQL连接参数里统一设置。

第二个是Excel导入中文乱码。前端上传Excel文件时编码不对，后端读出来姓名全是乱码。EasyExcel其实不会乱码，但如果你用POI且文件编码格式不规范，就会出问题。建议统一使用EasyExcel的UTF-8读取，前端设置responseType和处理导出时的编码头。

第三个是逻辑删除导致唯一索引失效。员工工号设了唯一索引，但逻辑删除后想再录一个同工号的员工，数据库层会报唯一键冲突，因为旧数据并没有真正删除。MyBatis-Plus的逻辑删除是更新deleted字段，唯一索引没法过滤掉deleted=1的记录。解决办法是让唯一索引包含逻辑删除字段（比如多个字段一起建唯一索引），或者干脆不物理复用工号。这个问题属于资深工程师才会留意的细节，踩过之后特别涨经验。

8.2 三个提升项目含金量的优化方向

如果还有时间，建议加这三个功能，工作量不大但能让项目从"普通毕设"变成"优秀毕设候选"。

一是操作日志模块。用AOP切面注解@Log("新增员工")记录所有操作，答辩时你能演示"每次登录和增删改都有迹可循"，安全性的印象分立刻上来。

二是考勤月度报表导出。把考勤统计结果用EasyExcel导成Excel表格，按部门汇总出勤率。这个功能不需要太复杂的逻辑，只是把已有的统计数据写到输出流，但演示效果很好。

三是简单的数据权限。部门主管登录后只能看到本部门的员工，而不是全部员工。这可以借助MyBatis-Plus的拦截器在SQL层面加上dept_id条件。实现难度不高，但能讲的空间很大，事务、安全、SQL拦截一块都能聊。

8.3 结尾的补充建议

回到最初的话题，这套系统确实是一个很典型的SpringBoot管理系统项目。你可以把源码当作业提交，但我更建议你把它当成一份"可运行的需求文档"——把表结构理一遍、把登录流程跟一遍、把考勤统计的SQL手写一遍，再在论文里把每个设计决策的"为什么"写清楚。等你做完这一步，评委问什么都难不倒你，而你也真正有了一行一行写给面试官看的项目经历。