基于SSM与MySQL的人事信息管理系统设计与实现

简介围绕企业人事信息管理系统的毕业设计论文文档面向计算机相关专业毕业生、课程设计者及JavaWeb开发者可作为人事管理类选题的写作范本与技术实现参考。压缩包仅含1个doc文件大小约1.19MB正文涵盖中英文摘要、关键词、目录、绪论、相关技术、系统分析、系统设计与实现、参考文献等论文主体结构整体结构完整、目录层次清晰。技术方案以SSM框架为核心结合B/S结构与MySQL数据库围绕用户基础数据、薪资、福利、培训、任务和公告发布等模块展开需求分析与功能设计并涉及权限控制、数据备份恢复等内容。已有84人学习适合需要参考论文框架、模块划分、数据库设计思路与SSM项目论述方式的读者也可用于梳理企业人事信息管理系统的业务流程、功能边界和答辩材料。1. 从一张月底对不上的表说起一个小规模团队的人事岗月底要干的事其实很固定翻培训签到表核课时、对福利发放名单、把薪资的增减项一条条录进表格、再把新员工信息补进花名册。麻烦不在活多在于这些数据分散在十几张互相引用的表里改一个部门归属福利名单和薪资表都要跟着动动完还得人工核对一遍。这套基于 JavaWeb 的企业人事信息管理系统走的是 SSM 框架加 MySQL 的路子把用户基础数据、薪资、福利、培训、任务、公告六块业务收进同一个后台管理员登录后统一增删改查员工侧只能看到与自己相关的记录。对要交毕设或课设的人来说它是一份结构完整、模块边界清楚、能跑起来也能讲明白的参考对刚把手工作业往线上搬的小团队来说这套模块划分和表结构可以直接拿去改。下面按需求分析、选型、总体设计、库表落地、核心实现、避坑、验收的顺序把整套方案摊开讲。2. 系统分析与技术选型SSM 加 MySQL 在这个体量下为什么够用人事系统的特殊性在于它不追求高并发追求的是「数据别错、权限别乱、流程别断」。日活几十到几百人写操作集中在月初月末读操作零散分布在日常。这个负载特征决定了选型的第一原则不是先进而是可控框架要能看懂、出错要能定位、部署要能在一台普通机器上跑起来。2.1 三类可行性判断技术、经济与运行技术可行性上Java 的语言特性在这里是实打实的便利——强类型让实体类字段和数据库列对得上编译期就能拦下一批拼写错误面向对象让「员工」「部门」「薪资单」这些概念能直接映射成类业务代码读起来接近业务描述。配套的 SSM 生态成熟遇到的问题基本都能在公开文档里找到答案独立开发者不需要从零造轮子。经济可行性上这类系统的开发成本几乎只有人力一台能装 JDK 和 MySQL 的笔记本就够开发期不需要额外服务器测试和演示阶段用本机部署即可。数据库文件增长到百万级记录之前普通配置的机器都能扛住。运行可行性上B/S 结构把升级成本压到了最低——改完代码重新部署一次所有使用者刷新浏览器就是新版本不用挨个装客户端。对人事这种「用的人不多但换人频繁」的场景这一点比功能多两个按钮重要得多。提示可行性分析不是走流程的三段话写进文档时要给出具体的量级判断比如「预计记录量十万级以内、并发用户不超过 50」这样选型理由才站得住。2.2 性能指标怎么写成可验收的条目原始需求里列了易用性、可扩展性、健壮性、安全性四项这四项如果只写形容词答辩时经不起追问。我的做法是把每项翻译成一条能演示的动作指标可演示的验收动作判定标准易用性让不熟悉系统的人完成一次「新增员工 分配部门」不看文档 3 分钟内完成可扩展性在不动原有表的前提下新增「招聘」模块原有功能回归测试全部通过健壮性在新增表单里提交空值、超长字符串、非法日期页面给出明确提示后台不抛 500安全性用员工账号手动拼管理员接口地址返回 403数据未泄露可扩展性这条尤其值得在设计阶段就落实。做法是把「字典表」独立出来部门、公告类型、培训类型、留言类型这些枚举值全部走字典表配置以后加一个部门或者加一种公告分类只加数据不改表结构也就不会牵动已有的查询代码。健壮性靠的是统一的参数校验和全局异常处理而不是在每个 Controller 里写 try-catch。校验放在 Controller 入口异常兜底放在一个ControllerAdvice里业务层只管正常路径。这样某一次误操作最多是弹一个红字提示不会把整个会话打断。2.3 SSM 与 MySQL 的选型对照为什么不是 SSH为什么不是纯 SpringMVC为什么数据库不选 Access——这几个问题在答辩里出现频率很高先摆一张对照表。方案优势在这个项目里的短板SSHStruts2 Hibernate生态老、资料多配置繁琐改一个映射要动多个 XMLHibernate 全自动 ORM 对复杂查询不够灵活纯 SpringMVC JDBC轻、透明没有事务和依赖注入的封装重复代码多维护成本高SSMSpring SpringMVC MyBatis分层清晰MyBatis 的 SQL 可手写可控制需要手写 Mapper前期配置略多MyBatis 相对 Hibernate 的关键差别在于 SQL 掌控权。人事系统里的薪资计算、培训课时统计这类查询往往要跨三四张表做聚合还要按月份、部门动态过滤条件完全交给自动生成往往写不出理想语句。MyBatis 把 SQL 放在 XML 里条件拼装用if控制出了问题直接把 SQL 打到日志里粘进客户端就能复现这比猜框架生成了什么语句高效得多。数据库侧的横向对比同样简单Access 适合单机小数据量扛不住多用户并发写SQL Server 和 Oracle 功能强但部署成本和授权成本对这个体量没有必要MySQL 占用空间小、安装配置简单、支持事务与索引且社区资料充足。金额字段统一用DECIMAL(10,2)而不是浮点类型避免薪资累加出现 0.01 的误差——这类细节后期补起来很麻烦一开始定好字段类型能省掉一轮返工。3. 总体设计与数据库四层链路、六个模块与七张表设计阶段的产出物应该能直接指导编码而不是写完就锁进文档。这一章把架构分层、功能模块和数据库表三件事拆开讲每一件都给出能落到代码和 SQL 的具体形态。3.1 B/S 四层结构与一次请求的完整链路系统采用浏览器 / 服务器结构前端只负责展示和收集输入业务处理和数据访问都在服务端完成。整体分四层表现层JSP 页面加少量 JavaScript负责表单渲染、前端基础校验、表格分页展示。控制层SpringMVC 的 Controller接收请求、做参数校验、调用服务、返回视图或 JSON。业务层Service承载事务边界一个业务动作要么整体成功要么整体回滚。持久层MyBatis 的 Mapper 接口与 XML负责 SQL 与结果映射。一次「新增员工」的请求链路是这样的浏览器提交表单 → 登录拦截器校验会话 → Controller 校验参数合法性 → Service 开启事务先写员工表再按部门写一条初始薪资记录 → Mapper 执行两条 INSERT → 事务提交 → 返回列表页并刷新。把事务边界明确放在 Service 层是这套结构里最容易被忽略的一点。很多学生把两条 INSERT 分开在 Controller 里调用第一条成功第二条失败时数据库就留下脏数据而这类问题在演示时几乎不会被发现等到答辩老师问「如果中途失败怎么办」就答不上来了。3.2 功能结构管理员侧与员工侧的模块划分系统有两类角色功能入口按角色切分不做成同一套菜单靠隐藏来区分。管理员侧覆盖六个模块用户管理员工基础信息的增删改查支持按姓名、部门、入职时间筛选支持批量导入的字段校验规则。薪资管理按月录入基本工资、奖金、扣款实发金额由前三项计算得出支持按人按月份查询。福利管理福利项目名称、适用部门、福利内容、发放时间的维护。培训管理培训起止时间、天数、培训内容的登记以及按员工查询参与记录。任务管理任务分配、进度跟踪、完成情况记录。公告管理公告标题、类型、正文、发布时间的维护发布后员工侧可见。员工侧只保留四件事查看和修改个人基础信息、修改密码、查看自己的薪资与培训记录、浏览公告并留言。这个划分对应到菜单上就是两棵独立的树。做成两棵树而不是一棵树加权限隐藏是因为后者的漏洞太常见——菜单藏了但接口还在员工账号手动拼一下 URL 就能进管理员页面。接口层的角色判断必须独立于前端菜单存在这一点在第 4 章的拦截器里会具体写。3.3 E-R 设计实体、属性与联系的画法E-R 图用 Visio 画就够长方形表示实体椭圆表示属性菱形表示联系。系统里的核心实体是员工、部门、薪资、福利、培训、任务、公告七类联系关系上员工与部门是多对一员工与薪资、培训、任务是三组一对多福利与部门是多对一公告与管理员是一对多。画图时容易犯的错是把外键当成属性塞进实体里画出来就是一堆「部门ID」的椭圆图上一团乱。正确做法是只画业务属性外键关系用菱形联系表达字段落库时再补bumen_types这类列。另一处常错是遗漏联系上的属性比如员工参加培训这个联系本身带有「培训天数」这个属性它既不属于员工也不属于培训项目应该挂在联系上落库时作为培训表的独立字段。3.4 表结构落地七张核心表的建表语句从 E-R 图转到物理表命名上做了统一主键一律id外键用「实体名_types」或「实体名_id」时间字段统一datetime金额统一DECIMAL。下面挑最关键的员工表、薪资表、培训表三张给出建表语句其余福利、公告、留言、字典四张结构同理。-- 员工基础信息表系统的核心实体其余业务表都通过 yonghu_id 关联到它 CREATE TABLE yonghu ( id int NOT NULL AUTO_INCREMENT COMMENT 主键, yonghu_name varchar(32) NOT NULL COMMENT 姓名, yonghu_phone varchar(20) DEFAULT NULL COMMENT 联系电话登录账号, yonghu_password varchar(64) NOT NULL COMMENT 密码存MD5值不存明文, bumen_types int DEFAULT NULL COMMENT 部门对应字典表 dic_codebumen, juese_types int DEFAULT NULL COMMENT 角色1管理员 2普通员工, ruzhi_time date DEFAULT NULL COMMENT 入职日期, create_time datetime DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, PRIMARY KEY (id), UNIQUE KEY uk_phone (yonghu_phone) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT员工基础信息表; -- 薪资表只存基本工资、奖金、扣款三个原始值实发金额查询时计算 CREATE TABLE xinzi ( id int NOT NULL AUTO_INCREMENT COMMENT 主键, yonghu_id int NOT NULL COMMENT 员工ID, yuefen varchar(7) NOT NULL COMMENT 所属月份格式 2024-06, jiben decimal(10,2) NOT NULL DEFAULT 0.00 COMMENT 基本工资, jiangjin decimal(10,2) NOT NULL DEFAULT 0.00 COMMENT 奖金, kouchu decimal(10,2) NOT NULL DEFAULT 0.00 COMMENT 扣款, create_time datetime DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, PRIMARY KEY (id), UNIQUE KEY uk_user_month (yonghu_id,yuefen), KEY idx_yuefen (yuefen) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT薪资表; -- 培训表on_time 与 down_time 组合出培训区间day_number 单独冗余以便统计 CREATE TABLE peixun ( id int NOT NULL AUTO_INCREMENT COMMENT 主键, yonghu_id int DEFAULT NULL COMMENT 参与员工ID, on_time date DEFAULT NULL COMMENT 培训开始时间, down_time date DEFAULT NULL COMMENT 培训结束时间, day_number int DEFAULT NULL COMMENT 培训天数, cultivate_content varchar(500) DEFAULT NULL COMMENT 培训内容, create_time datetime DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, PRIMARY KEY (id), KEY idx_yonghu (yonghu_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT培训表;几个设计决定的说明。薪资表用(yonghu_id, yuefen)建唯一索引从数据库层面保证一个员工一个月只有一条薪资记录重复录入会直接报错比在代码里查一遍再插入可靠。培训表把day_number冗余存下来是因为按员工统计全年培训天数时如果每次都去减两个日期跨月跨年的计算容易出错索性在录入时算好存下。字典表的结构值得单独看一眼它是整套可扩展性指标的落地载体CREATE TABLE dictionary ( id int NOT NULL AUTO_INCREMENT COMMENT 主键, dic_code varchar(32) NOT NULL COMMENT 字段编码如 bumen、gonggao_type, dic_name varchar(32) DEFAULT NULL COMMENT 字段名称用于页面标签, code_index int DEFAULT NULL COMMENT 排序号控制下拉框顺序, index_name varchar(64) DEFAULT NULL COMMENT 选项显示文本如「技术部」, super_id int DEFAULT NULL COMMENT 父级ID支持二级分类, create_time datetime DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, PRIMARY KEY (id), KEY idx_code (dic_code) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT字典表;页面上的所有下拉框都从这个表查dic_code相同的记录归为一组。加一个新部门就是插一条数据加一种公告分类也是插一条数据。代价只有一个连接查询换来的是整个系统里不再出现硬编码的选项数组。4. 核心模块实现登录鉴权、用户管理与业务模块的代码落地实现阶段真正花时间的不是把界面画出来而是把「谁能做什么」「数据从哪里来」「出错怎么兜」这三件事写对。这一章挑四个有代表性的片段展开。4.1 登录与会话拦截两道关卡登录本身的逻辑很普通——比对账号、比对密码但权限控制必须放在拦截器里而不是页面上。先看拦截器// 权限拦截器注册在 springmvc.xml 中拦截 /admin/** 与 /employee/** public class LoginInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { HttpSession session request.getSession(); LoginUser user (LoginUser) session.getAttribute(loginUser); // 第一关会话里没有登录信息一律打回登录页 if (user null) { response.sendRedirect(request.getContextPath() /login.jsp); return false; } // 第二关角色越权判断。jueseTypes1 为管理员2 为普通员工 String uri request.getRequestURI(); if (uri.contains(/admin/) user.getJueseTypes() ! 1) { response.sendError(HttpServletResponse.SC_FORBIDDEN, no permission); return false; } // 员工侧接口只允许访问自己的数据具体过滤在 Service 层按 session 里的 id 做 return true; } }参数说明loginUser存在 Session 里只放 id、姓名、角色三个字段不放密码和证件号避免会话被读取后泄露敏感信息。jueseTypes从数据库读到后写入会话拦截时直接比对不查库减少每个请求一次额外查询。这里有个血泪教训早期版本把角色判断写在 JSP 里用c:if控制菜单显示接口完全不设防测试时用员工账号直接访问/admin/user/list就能看到全员数据。改成拦截器之后菜单显示依然保留但真正兜底的是这一段。前端控制是体验后端控制才是安全两者不能互相替代。密码存储上注册和修改密码时都走一次 MD5 加盐登录时同样处理后比对。虽然 MD5 单独用得谨慎但对课设级别的系统至少保证数据库里不出现明文密码答辩时这一条能讲清楚就够。4.2 用户基础数据管理分层调用与参数校验用户管理是使用频率最高的模块它的实现风格会被复制到后面所有业务模块所以第一遍就要写规范。Controller RequestMapping(/admin/user) public class UserController { Autowired private UserService userService; // 分页查询pageNum 从 1 开始pageSize 默认 10 RequestMapping(/list) public String list(RequestParam(defaultValue 1) Integer pageNum, RequestParam(defaultValue 10) Integer pageSize, String yonghuName, Integer bumenTypes, Model model) { PageInfoYonghu page userService.selectPage(pageNum, pageSize, yonghuName, bumenTypes); model.addAttribute(page, page); model.addAttribute(bumenList, dictionaryService.selectByCode(bumen)); // 查询条件回填翻页时不丢筛选状态 model.addAttribute(yonghuName, yonghuName); model.addAttribute(bumenTypes, bumenTypes); return admin/user_list; } // 新增先校验再落库校验不通过回填原表单避免用户重填 RequestMapping(value /add, method RequestMethod.POST) public String add(Yonghu yonghu, Model model) { if (StringUtils.isBlank(yonghu.getYonghuName())) { model.addAttribute(msg, 姓名不能为空); return admin/user_add; } if (!yonghu.getYonghuPhone().matches(^1[3-9]\\d{9}$)) { model.addAttribute(msg, 手机号格式不正确); return admin/user_add; } userService.insertWithInitSalary(yonghu); return redirect:/admin/user/list; } }对应 Service 里的事务边界Service public class UserServiceImpl implements UserService { Autowired private UserMapper userMapper; Autowired private SalaryMapper salaryMapper; Override Transactional(rollbackFor Exception.class) public void insertWithInitSalary(Yonghu yonghu) { yonghu.setCreateTime(new Date()); userMapper.insert(yonghu); // 回填主键MyBatis 的 useGeneratedKeys 配置生效 // 新员工入职时同步建一条当月薪资草稿避免薪资模块出现「查无此人」 Salary salary new Salary(); salary.setYonghuId(yonghu.getId()); salary.setYuefen(new SimpleDateFormat(yyyy-MM).format(new Date())); salaryMapper.insert(salary); } }两处细节值得说明。Transactional上的rollbackFor Exception.class不能省默认只在运行时异常时回滚校验类异常如果不声明就回滚不了。另一处是useGeneratedKeystrue keyPropertyidMyBatis 插入后会把自增主键写回实体后面建薪资草稿时才能拿到yonghu.getId()这个配置漏了的话yonghu_id会是 0。删除走的是「先提示再执行」的流程页面上点击删除先弹确认框真正提交后由 Mapper 执行删除并返回影响行数前端根据返回结果提示成功或数据已不存在。这个流程看着简单但删除前的关联检查不能少——删一个有薪资记录的员工要么阻止要么级联处理直接删主表会留下孤立数据。4.3 薪资与培训动态条件查询和计算字段的处理薪资列表要支持按员工、按月份动态筛选实发金额由三项计算。查询语句放在 Mapper XML 里!-- SalaryMapper.xml动态条件 计算列实发不落库避免改规则时全表刷新 -- select idselectSalaryPage resultTypecom.hrms.vo.SalaryVO SELECT s.id, s.yonghu_id, u.yonghu_name, s.yuefen, s.jiben, s.jiangjin, s.kouchu, (s.jiben s.jiangjin - s.kouchu) AS shifa FROM xinzi s LEFT JOIN yonghu u ON u.id s.yonghu_id where if testyonghuId ! nullAND s.yonghu_id #{yonghuId}/if if testyuefen ! null and yuefen ! AND s.yuefen #{yuefen}/if if testyonghuName ! null and yonghuName ! AND u.yonghu_name LIKE CONCAT(%, #{yonghuName}, %) /if /where ORDER BY s.yuefen DESC, s.yonghu_id ASC LIMIT #{offset}, #{pageSize} /select参数说明offset由 Service 层用(pageNum - 1) * pageSize算出后传入不要直接在 SQL 里做算术否则分页插件接管时会出问题。where标签会自动处理第一个条件前面的AND条件全空时不会生成非法语句。实发金额用表达式算而不建字段理由是薪资规则可能变比如以后加一项补贴落库的话历史数据要整体刷一遍。代价是每次查询多一次算术在十万级数据量下完全可以接受。金额相加必须依托DECIMAL类型如果字段是float1000.10 200.20会得到1200.2999...页面上看起来只差一点累加到全公司就是账对不上。培训模块的实现逻辑基本相同差别在统计查询。按员工汇总年度培训天数select idsumDaysByUser resultTypejava.lang.Integer SELECT IFNULL(SUM(day_number), 0) FROM peixun WHERE yonghu_id #{yonghuId} AND YEAR(on_time) #{year} /select用IFNULL包一层是因为该员工当年没有培训记录时SUM返回 null直接转 Integer 会在 JSP 上显示空白而不是 0用户会以为页面坏了。这类空值处理在统计类查询里几乎必然遇到统一在外层兜住比在 JSP 里写三元表达式清晰。公告、福利、任务三个模块的骨架与用户管理一致都是「列表带条件分页 新增校验 编辑回填 删除确认」差别只在字段和校验规则。实现时可以先写完用户管理再复制一份改字段比每个模块从零写快得多也更容易保持风格一致。4.4 数据安全与备份能讲清楚的三件事安全性在这个体量下不需要复杂方案但三件事必须有。第一是身份与权限分离前面拦截器已经覆盖登录验证身份拦截器验证权限两件事分开做。第二是输入校验所有表单提交在 Controller 入口做类型和格式判断防止超长字符串撑爆字段、防止日期格式错误导致 SQL 执行异常。第三是备份MySQL 自带mysqldump就够用定时任务每晚导出一次保留最近七份。# 每日备份脚本保留最近 7 天导出文件按日期命名 mysqldump -u hrms_user -p*** --single-transaction hrms /backup/hrms_$(date %F).sql find /backup -name hrms_*.sql -mtime 7 -delete--single-transaction的作用是在导出时开启一致性快照不会锁表业务查询不受影响。恢复时直接source对应日期的 sql 文件即可。这套方案在答辩里经得起问因为它有具体的命令、具体的保留策略不是一句「做了数据备份」带过。5. 避坑与排查五个最容易翻车的点下面五条都是这类项目里出现频率极高的问题按「现象 → 原因 → 解决」写遇到时对照排查能省下不少时间。5.1 环境与配置类问题现象一本地跑得好好的换台机器启动就报Communications link failure。原因通常是数据库连接串里写死了localhost:3306而目标机器的 MySQL 端口被改过或者服务根本没启动。解决方式是先单独用客户端工具连一次确认端口和服务状态再检查jdbc.properties里的url、username、password三项。另外 MySQL 8 的连接串要加serverTimezoneAsia/Shanghai和useSSLfalse少了时区参数会出现时间字段整体偏移 8 小时的现象这个坑非常隐蔽——数据看起来是对的只是差了八个小时。现象二页面能打开但所有列表都是空的控制台无报错。先看 MyBatis 的 SQL 日志有没有打出来如果打了 SQL 但结果为空多半是mapper扫描路径写错XML 根本没被加载接口调用时静默返回空集合。检查spring-mybatis.xml里mapperLocations的值路径中的classpath*:前缀不能丢*通配符要覆盖到所有子目录。第二处要查的是实体类字段名和数据库列名的映射mapUnderscoreToCamelCase没开的话yonghu_name映射不到yonghuName结果就是对象里全是 null。现象三中文写入数据库变成问号。三个环节都可能出问题数据库表的字符集、连接串的编码参数、JSP 页面的pageEncoding。逐个确认建库语句显式写DEFAULT CHARSETutf8mb4连接串加characterEncodingutf8JSP 头部声明% page contentTypetext/html;charsetUTF-8 %。三处统一之后还乱码的情况很少真遇到就查 Tomcat 的server.xml里 Connector 有没有配URIEncoding。5.2 数据与业务逻辑类问题现象四删除部门之后员工列表里对应的部门显示空白但数据还在。这是典型的关联删除没想清楚。部门存在字典表里员工表只用bumen_types存了个编号删掉字典项之后编号就悬空了。处理方式有两种选一种并写进文档要么删除前先检查是否有员工引用有引用就阻止删除并提示要么做逻辑删除字典表加一个del_flag字段删除只是置位查询时过滤掉。我一般选后者因为历史数据里的引用关系不能凭空消失物理删除会让报表统计出现无法解释的空洞。现象五新增员工时报Duplicate entry但页面上明明显示提交成功。原因是手机号上建了唯一索引重复提交时数据库抛异常而 Controller 里没有捕获异常被全局处理器吞掉后返回了一个默认页面。解决分两层前端提交按钮点击后立即置灰防重复点击后端在插入前先按手机号查一次存在就返回「该手机号已注册」的提示而不是让数据库报错。唯一索引不能因为怕报错就去掉它是最后一道防线正确的做法是让它在正常路径上不被触发。注意调试这类问题时把 MyBatis 的logImpl设为SLF4J并把日志级别调到 DEBUG能看到完整 SQL 和参数值。凭猜测改代码的效率远低于直接看语句。6. 验收与答辩用测试用例表和演示脚本证明系统真跑通了到了这一步功能写完了但「写完了」和「能验收」是两件事。我的习惯是先做一张测试用例表把每个模块的主路径和一条异常路径列出来逐条跑一遍并记录实际结果。这张表在答辩时比任何功能截图都有说服力因为它证明你系统性地验证过而不是碰巧点通了几个页面。编号测试项输入预期结果实际结果T01管理员登录成功正确账号密码进入后台首页菜单完整通过T02密码错误正确账号 错误密码提示「密码错误」停留登录页通过T03员工越权访问员工账号直接访问/admin/user/list返回 403不显示任何员工数据通过T04新增员工必填校验姓名为空提交提示「姓名不能为空」表单内容保留通过T05手机号重复已存在的手机号提示「该手机号已注册」通过T06薪资实发计算基本 5000、奖金 800、扣款 200列表显示 5600.00通过T07同一员工同月重复录薪资重复提交提示已存在不产生第二条记录通过T08公告发布后员工可见管理员发布一条公告员工侧公告列表出现该条通过演示脚本也要提前排。答辩时间通常只有五到八分钟按「登录 → 新增一个员工 → 给这个员工录一条薪资 → 发一条公告 → 切员工账号看公告和个人薪资」这条线走全程只用一个新造的数据前后呼应比随机点菜单有说服力。走之前把所有数据准备好尤其是部门、字典项这些基础数据演示时现场建会浪费时间还容易出错。被问到设计取舍时答案要落到具体场景。问为什么用 MyBatis 不用 Hibernate就答薪资统计要手写聚合 SQL问为什么实发金额不存字段就答规则可能变、避免历史数据重刷问安全性怎么保证就答拦截器加角色判断加一条「员工账号手动拼管理员地址返回 403」的现场演示。这些问题都有标准答案但用自己系统的具体字段和具体路径回答分量完全不一样。我最早做这类项目时吃过一次亏功能全写完了答辩前一天把数据库从本机迁到演示用的机器上结果字符集没对上所有中文全变乱码当场重导数据折腾了两个小时。从那以后我每次交付前都强制走一遍「换机部署 全量数据导入 按测试用例表跑一遍」的流程哪怕时间再紧也不跳过。这套流程看着笨但它能把九成的现场事故挡在答辩之前。希望帮到你。本文还有配套的精品资源点击获取