Java Web人事信息管理系统设计与实现：从选题到答辩完整指南-代码聚汇网

Java Web人事信息管理系统设计与实现：从选题到答辩完整指南

烂人不配爱·2026-08-31·阅读 24 GEO检测（免费）

Java Web人事管理系统SSM

|难度：普通|阅读约 41 分钟

这道题目我太熟了，这些年帮过的学生里，十个有八个拿到的都是“基于Java Web的某某管理系统”，人事管理系统又是其中最经典的一个。很多人一看题目就头大，觉得“人事”这俩字特别虚，不知道该从哪儿下手。但实际上，这个题目能成为计算机毕设里的常青树，恰恰是因为它既不过分复杂，又能把Java Web开发的核心知识点串起来——数据库设计、Servlet/JSP交互、前端Ajax、权限控制、报表统计，样样都能沾上，而且企业里确实有现实对应物，答辩的时候也好讲。

这篇文章就围绕“基于Java技术的人事信息管理系统的设计与实现”这个题目，把从选题、技术选型、数据库设计、功能实现、部署调试到论文答辩的完整链路拆开讲一遍。不管你是刚拿到题目还没头绪，还是已经写了几个页面但卡在权限或部署上，这篇内容应该都能给你一个比较清晰的路线图。我自己在带学生和实际开发的过程中踩过不少坑，也会一并写出来，帮你少走点弯路。

1. 这个毕设题目到底在考什么

1.1 人事管理系统为什么能成为毕设常青树

先说个很多人没想明白的问题：为什么每年毕业设计题库里，人事管理系统、工资管理系统、教务管理系统这些东西层出不穷？因为这些系统有一个共同特征——业务边界清晰。

人事系统管的是什么？员工信息、部门岗位、考勤、请假、薪资、招聘、培训，核心就是围绕“人”在企业生命周期里的数据流转。这个领域没有特别深奥的算法，也没有高并发的性能压力，它的重点在于“数据的结构化组织”和“业务流程的闭环”。这正好踩在本科毕设的审美点上：数据显示得分、交互得分、业务逻辑得分，而不会因为选题过大导致做不完。

换句话讲，人事管理系统考察的从来不是你会不会写复杂的业务代码，而是你有没有能力把一个真实世界的管理问题抽象成软件系统的功能模块，再用你学过的Java Web技术把它实现出来。这个抽象能力，才是评分老师最看重的东西。

1.2 隐藏的评分维度：不只是“能跑”

很多学生以为毕设做完、能启动、点几个页面截图就完事了。实际经验告诉我，答辩老师的注意力通常放在以下四个维度上：

需求完整度：系统是否覆盖了人事管理的主要业务场景。只有员工增删改查，没有考勤、没有部门管理、没有权限区分，很容易被认为是“半成品”。
工程规范性：是否遵循了分层架构（表现层、业务层、数据访问层），是否用了合理的编码规范，是否处理了异常和非法输入。这一段直接反映你在公司实习或做课设时养成的习惯。
系统安全性：密码是否明文存储、是否有登录拦截、是否有越权访问漏洞。即使是个毕设，这些点也常常被追问，答不上来会减分。
技术表达的深度：论文和答辩中，你是否能说清楚某个功能的实现原理。比如“审批流是怎么走的”、“权限是怎么控制的”，而不是只停留在“我调了一个接口”。

1.3 题目拆解：四个关键词背后的需求全景

把题目“基于Java技术的人事信息管理系统的设计与实现”拆开看，每个词都有猫腻：

“基于Java技术”：划定了语言红线。你可以用JSP/Servlet，可以用SSM，也可以用Spring Boot，但核心逻辑不能是Python或C#写的。
“人事信息管理系统”：规定业务域。系统必须围绕员工信息、部门岗位、考勤、薪资、合同等概念展开。
“设计与实现”：意味着论文中必须同时有“设计”（架构、数据库、UML建模）和“实现”（代码、页面、功能截图）。
“Java Web环境”：暗示项目是一个B/S架构（浏览器/服务器）应用，需要部署在Tomcat等容器里，而不是一个纯Java控制台程序。

把这四个点想明白了，你才知道代码要写什么，论文要写什么。很多人做毕设做到一半跑偏，往往就是因为一开始没做过这道拆解题。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 技术选型的底层逻辑：JSP、SSM还是Spring Boot

2.1 主流技术栈对比：各有各的活路

在选技术栈之前，先记住一个原则：毕设的核心是稳，不是炫。在答辩现场能讲清楚、能稳定运行，比你用了一万个新框架重要得多。下面是目前Java Web毕设领域最常见的三套方案对比：

技术方案	典型组成	上手难度	适合人群	答辩风险
JSP + Servlet + JavaBean	JSP页面、Servlet控制器、JDBC连接数据库	较低	基础一般、时间紧张	容易显得老旧，但逻辑透明
SSM（Spring + SpringMVC + MyBatis）	IoC/DI管理对象、SpringMVC做请求分发、MyBatis操作数据库	中等	有一定框架基础的同学	配置繁琐，经常在环境上翻车
Spring Boot + MyBatis/JPA	自动配置，内嵌Tomcat，开发效率高	中等	想兼顾工作和毕设效率	老师可能会问“和SSM有什么区别”，需要准备

如果学校指定了技术栈，那就按学校来，别自作聪明换框架。如果允许自己选，我的建议是：对框架熟悉程度不够的学生，完全没有必要为了显得高级而去硬上Spring Boot + Vue的前后端分离。毕设答辩现场，你很难向一个突然走过来的评委解释为什么一个管理网站要把前端和后端拆成两个项目。传统JSP方案虽然看着老，但它天然的“请求来了，服务端渲染页面返回”模型，和人事管理系统这种以表格、表单为主的业务场景非常匹配，评委也容易理解。

2.2 选SSM时最容易忽略的配置细节

如果你还是决定用SSM（很多学校教材主推这个），那么下面这几个配置是常见重灾区：

MyBatis映射文件路径：mapper-locations没配好，启动时会出现“Invalid bound statement (not found)”错误。
Spring与SpringMVC的扫描包冲突：Spring容器扫描了@Controller，SpringMVC又扫描了一遍，经常导致事务和AOP失效。
数据库连接池参数：driverClassName、url、username、password四件套写错任何一个，启动都会报错，而且报错信息往往不直观。

有一种调试技巧分享一下：遇到Spring、SpringMVC相关的错误，先去检查控制台最顶部的异常，而不是看最底部。因为框架整合类的问题，经常在启动早期抛错，真正的根因被后面一大堆堆栈信息淹没了。

2.3 前端技术组合：JSP + JQuery + Bootstrap依然是王道

人事系统的前端交互，无外乎表格展示、表单校验、弹窗确认、Ajax局部刷新这么几类。很多学生喜欢在这里上Vue + Element UI，技术本身没问题，但要注意：如果你用的是JSP，Vue的组件化和JSP的服务端渲染混在一起，经常会踩到变量名冲突和模板语法冲突的坑。

我的实际推荐是：JSP做页面骨架，Bootstrap负责样式，JQuery负责Ajax和DOM操作。这套组合的好处是每一层职责清清楚楚，页面代码贴到论文里也好展开讲。等到你确实把业务逻辑都跑通了，还有大把时间，再考虑引入Vue重写某几个核心页面作为加分项。

说到这，正好提一句热词里那个“前端js+jquery如何实现设置审批流”。这个问题的本质是：把审批流程的步骤配置做成一个前端交互组件，然后通过Ajax把数据提交给后端。常见做法是，用JQuery动态生成一排表单或卡片，每个卡片代表一个审批节点，支持“添加节点”“删除节点”“调整顺序”三个操作。最后把所有节点数据组装成JSON，$.ajax提交到Servlet或Controller，服务端再把它解析写库。在人事系统里，这通常对应“请假审批流程配置”或“入职审批流程配置”模块，做出来之后直接就是一个答辩亮点。

2.4 一个关于“运行环境”的老实建议

开发环境上，不要用太高版本的JDK。曾经有个学生装了JDK 21，结果他用的MyEclipse版本过老，项目代码用了旧语法，一连串编译错误，他在环境上浪费了两周。Java Web毕设比较稳妥的环境组合是：JDK 1.8 + Tomcat 8.5/9 + MySQL 5.7，这套组合经过太多项目验证了，遇到问题网上答案一搜一大把。如果你的机器只装得了新版JDK，那也请在项目设置里把编译级别调成1.8，并且留意Tomcat版本与JDK的兼容性。

3. 数据库设计与表结构：一张员工表背后的管理学

3.1 核心表清单：先想清楚“人”在系统里怎么流动

人事管理系统的数据库设计，建议从“一张员工表”开始，然后问自己几个问题：

员工属于哪个部门？
员工担任什么职位？
员工如何登录系统？密码放在哪里？
员工的考勤记录怎么存？
员工的工资怎么算？算完放哪？
员工请假、加班、入职审批怎么记录流程？

顺着这些问题，你自然会得到一套表结构。我一般会把核心表分成三组：组织架构类（部门表、岗位表）、员工基础类（用户表、员工表、合同表）、业务过程类（考勤表、请假表、薪资表、审批记录表）。

3.2 建表SQL演示：员工表与部门表

下面给一个最核心的员工表和部门表的SQL示例，注意看字段类型、主外键和注释的设计习惯：

sql复制CREATE TABLE `department` (
  `id` INT(11) NOT NULL AUTO_INCREMENT COMMENT '部门ID',
  `name` VARCHAR(50) NOT NULL COMMENT '部门名称',
  `manager_id` INT(11) DEFAULT NULL COMMENT '部门负责人ID',
  `description` VARCHAR(255) DEFAULT NULL COMMENT '部门描述',
  `created_time` DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='部门表';

CREATE TABLE `employee` (
  `id` INT(11) NOT NULL AUTO_INCREMENT COMMENT '员工ID',
  `emp_no` VARCHAR(20) NOT NULL COMMENT '工号',
  `name` VARCHAR(30) NOT NULL COMMENT '姓名',
  `gender` CHAR(1) DEFAULT NULL COMMENT '性别（M/F）',
  `birthday` DATE DEFAULT NULL COMMENT '出生日期',
  `id_card` VARCHAR(18) DEFAULT NULL COMMENT '身份证号',
  `phone` VARCHAR(20) DEFAULT NULL COMMENT '手机号',
  `email` VARCHAR(50) DEFAULT NULL COMMENT '邮箱',
  `dept_id` INT(11) DEFAULT NULL COMMENT '所属部门ID',
  `position` VARCHAR(50) DEFAULT NULL COMMENT '职位',
  `entry_date` DATE DEFAULT NULL COMMENT '入职日期',
  `status` TINYINT(1) DEFAULT '1' COMMENT '员工状态（1在职 0离职）',
  `education` VARCHAR(20) DEFAULT NULL COMMENT '学历',
  `address` VARCHAR(255) DEFAULT NULL COMMENT '住址',
  `emergency_contact` VARCHAR(50) DEFAULT NULL COMMENT '紧急联系人',
  `emergency_phone` VARCHAR(20) DEFAULT NULL COMMENT '紧急联系电话',
  `remark` VARCHAR(255) DEFAULT NULL COMMENT '备注',
  `created_time` DATETIME DEFAULT CURRENT_TIMESTAMP,
  `updated_time` DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_emp_no` (`emp_no`),
  KEY `idx_dept_id` (`dept_id`),
  CONSTRAINT `fk_employee_dept` FOREIGN KEY (`dept_id`) REFERENCES `department` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='员工信息表';

这里有几个体现“专业度”的细节：

emp_no设置了唯一索引，保证工号不会重复。
gender用CHAR(1)存“M/F”而不是中文，这是典型的柯里化存储思维，代码里再转换成“男/女”。很多学生会直接把“男”“女”存进数据库，也不是不行，但答辩时容易被问“如果让你把性别改为英文或数字枚举你怎么处理”。
status用TINYINT存0和1，而不是直接存“在职/离职”。这样后续做离职员工列表筛选时，一条SQL就能搞定。
外键约束一定要加，不然连表查询时数据对不上，后期排查会非常痛苦。

3.3 考勤表、薪资表的设计陷阱

考勤表和薪资表是另一个重灾区。很多学生设计的考勤表是一天一条记录，结果一个月30天，50个员工就是1500条数据，本身倒也没什么，但统计的时候查询条件容易写歪。这里给出一种更合理的简化设计：考勤汇总表按“员工+月份”为维度，记录出勤天数、迟到次数、早退次数、请假天数、加班时长。明细表可以暂时不做，做了反而容易因为数据造不全而显得空洞。

薪资表同理，不要每次发工资都重新算，而是把“应发工资、五险一金、个税、实发工资、发放月份”作为一条快照记录下来。这样回看历史月份时，直接查表就行，逻辑简单又真实。

3.4 数据库设计最常见的三个低级错误

字段类型瞎用：涉及到金额的字段用FLOAT或DOUBLE，结果算工资时出现一大堆小数点，应该用DECIMAL(10,2)。
字体和排序规则不一致：MySQL建库建表时有用utf8的、有用gbk的，连接字符串又有用utf8mb4的，导致查询结果乱码或报错“Illegal mix of collations”。毕设项目一律统一成utf8mb4，连接URL加characterEncoding=utf8。
不设外键：我理解有些学生担心外键影响删除，但毕设系统里数据体量很小，外键约束带来的“数据一致性保障”远大于性能损失。答辩的时候老师看到外键，基本会认为你“懂数据库”。

4. 功能模块实现的分工与顺序：别一上来就写员工管理

4.1 为什么要从登录和权限开始

拿到需求后，绝大多数学生的本能反应是：先写员工信息表，然后做一个员工列表页，接着做增删改查。我的经验是：先写登录和权限，再写业务模块。原因有三：

登录模块会逼着你搞定“数据库连接、用户表设计、密码加密、会话管理”这一套基础设施。这些基础不打好，后面写什么模块都别扭。
人事系统天然有“管理员”“HR”“普通员工”三类角色。先定义好角色，后面每个页面的按钮都会带着权限判断，写起来思路更清晰。
论文里第一章就是系统需求和用例分析，登录和权限是其中最重要的用例之一。先实现它，后面写论文只需要拿实际截图说话。

登录模块的代码结构推荐这样分：

UserController/Servlet：接收用户名密码，解析请求参数。
UserService：负责业务校验（用户是否存在、密码是否正确、账户是否禁用）。
UserDAO/Mapper：查询用户表，返回用户信息及角色ID。
PasswordUtil：负责MD5加盐或BCrypt加密，明文密码在内存里待的时间越短越好。

具体的登录逻辑，很忌讳把所有代码写在doPost()里直接查库然后session.setAttribute()完事。哪怕只是毕设，把Controller、Service、DAO分层写出来，不仅自己好维护，答辩时老师问“你的架构是怎么设计的”，你也能拿出一条清晰的处理链。

4.2 员工信息管理的CRUD：不只是四个按钮

很多学生写完“员工新增、员工列表、员工编辑、员工删除”就觉得完成了。实际上，员工信息管理模块至少还可以扩展到：

多条件组合查询：按姓名、部门、学历、入职时间范围组合过滤，SQL里用WHERE 1=1 + <if>动态拼接（MyBatis的话用<where>标签）。
分页：前端展示第几页、每页多少条，后端用LIMIT offset, size，JSP里做页码导航。
数据导入导出：用POI导出Excel，用EasyExcel导入Excel。这个在HR场景里非常真实，如果你会做，直接就是一个加分项。
离职操作：离职不是删除员工记录，而是把status置为0。这个过程可以触发离职日期填写、交接人设置、社保减员等后续提示。

一个比较现实的问题是，很多学生造数据时偷懒，员工表就放了五六条假数据，页面看起来特别空。要想展示效果好，写一个循环脚本生成几十条真实感强的数据（中文姓名、对应手机号、合理的入职日期），在答辩演示时会明显更有说服力。

4.3 审批流设计：把“流程状态机”讲清楚

审批流是这个系统里最有深度的功能之一，因为它是“人事信息管理系统”区别于普通CRUD系统的关键。这里拿最简单的请假审批来举例。

一张请假单，它的状态流转一般是：

提交申请（状态：待审批）
直属主管审批（如果通过，状态变为：主管已通过；如果驳回，状态变为：已驳回）
HR/部门经理审批（状态变为：审批通过或审批驳回）
流程结束

在数据库层面，可以设计一张approval_record表来记录每个节点的处理情况：

sql复制CREATE TABLE `approval_record` (
  `id` INT(11) NOT NULL AUTO_INCREMENT,
  `business_type` VARCHAR(20) NOT NULL COMMENT '业务类型（leave/entry/salary）',
  `business_id` INT(11) NOT NULL COMMENT '业务单据ID',
  `node_name` VARCHAR(50) NOT NULL COMMENT '审批节点名称',
  `approver_id` INT(11) DEFAULT NULL COMMENT '审批人ID',
  `approve_status` TINYINT(1) DEFAULT '0' COMMENT '审批状态（0待审 1通过 2驳回）',
  `approve_comment` VARCHAR(255) DEFAULT NULL COMMENT '审批意见',
  `approve_time` DATETIME DEFAULT NULL COMMENT '审批时间',
  `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='审批记录表';

实现审批流时，后端的关键是从“流程节点列表”中找出“第一个待审批节点”，当前用户只能处理且只能看到自己名下的待办。前端JQuery动态操作审批节点顺序，提交后后端按顺序保存节点。这套逻辑讲清楚之后，论文的“流程设计”章节基本不用愁。

4.4 考勤和薪资里那些容易被追问的算法

考勤模块最简单也最有效的实现方式是：管理员按月份批量生成考勤记录，也可以导入打卡Excel。然后系统根据班次时间和打卡记录自动计算“迟到/早退/缺勤”。这里面涉及到一个判断逻辑，比如：上班时间是09:00，打卡时间在08:30-09:05之间算正常，在09:05-10:30之间算迟到，10:30之后算缺勤。把这些判断条件抽到一个方法里，而不是在JSP里写一堆if，这样代码质量会好看很多。

薪资模块要能解释清楚“应发工资”怎么来的。我建议做这样的公式：

应发工资 = 基本工资 + 岗位工资 + 绩效工资 + 加班工资 - 迟到扣款 - 缺勤扣款

然后“实发工资 = 应发工资 - 五险一金个人部分 - 个税”。个税计算可以用一个简单分段函数，不用引第三方库。这段逻辑在论文里可以写“个人所得税计算算法”，既显得你有业务思维，又不会真的难到做不出来。

5. 部署调试中的实战踩坑：从端口冲突到内存溢出

5.1 Tomcat端口和发布路径问题

第一次把项目部署到Tomcat时，最常见的状况是Port 8080 was already in use。这个问题的原因往往是之前启动Tomcat后没有正常关闭，或者开了多个IDE实例。解决方案很简单，Windows下打开命令提示符：

bash复制netstat -ano | findstr 8080

查到占用端口的PID后：

bash复制taskkill /F /PID 你的PID

另外很多人部署后访问地址带了很长的项目名，比如http://localhost:8080/hrms_war_exploded/。如果你希望它以根路径访问，可以在IDEA的Artifacts设置里把Application context改成/，或者在Tomcat的conf/server.xml里配置虚拟路径。毕设演示时，用简洁的URL访问会让系统看起来更正式。

5.2 OutOfMemoryError：内存溢出不是个玄学问题

热词里出现了java: outofmemoryerror: insufficient memory，这其实也是Tomcat部署中很经典的报错。在毕设里最可能的原因是：你写了一个循环查询，每次查完结果都没释放，内存被撑爆；或者数据量不大但JVM启动内存太小。处理办法分两步：

临时解法：在IDEA的VM options里加-Xms256m -Xmx512m，给Tomcat也调整启动内存。
根因排查：检查代码里是否有一次性把全表数据select *加载到内存、然后循环再查的写法。比如查员工列表时，在循环里逐个查部门名称，数据量一多就会很慢甚至OOM。解决方式是用LEFT JOIN一次性查出部门名称，而不是在循环里发SQL。

5.3 中文乱码：整个毕设最讨厌的问题

中文乱码的根源就一句话：数据在传输的每一环，编码都要一致。排查链通常有四层：

JSP页面顶部是否设置了pageEncoding="UTF-8"。
数据库连接URL是否带了characterEncoding=utf8。
数据库表字段是否用的utf8mb4。
Tomcat的server.xml中Connector是否设置了URIEncoding="UTF-8"。

如果某个环节漏了，就会出现“数据库里存的是中文，页面显示问号”或“页面提交后后端收到的全是乱码”。建议从一开始就统一，不要等出问题了再一个一个环境翻。

5.4 Ajax请求拿不到数据：先看成功回调和数据格式

使用JQuery + Ajax和JSP后端交互时，最典型的错误是：

URL写错：相对路径导致的404，这个在部署后尤其常见。
返回的不是JSON：后端返回了字符串或页面片段，前端data字段只能拿来直接显示，却去访问data.success，结果一直undefined。
GET/POST不一致：后端接口只支持POST，前端的$.ajax没写type: 'POST'，结果405。

调试Ajax有个技巧，就是先在浏览器F12的Network面板里看请求的响应体，确定后端到底返回了什么，再去改前端代码。很多学生一报错就去看后端控制台，其实问题可能压根没到后端。

5.5 Session失效和跨页面权限控制

登录状态的守卫，很多学生只做了“判断session是否为空，为空就跳回登录页”这一层。但这会漏掉一个很常见的场景：用户直接输入URL访问管理页面。如果每个页面都手动检查一遍Session，代码会很啰嗦。推荐用Filter（过滤器）统一处理：

java复制public class LoginFilter implements Filter {
    public void doFilter(ServletRequest req, ServletResponse resp, FilterChain chain) {
        HttpServletRequest request = (HttpServletRequest) req;
        HttpServletResponse response = (HttpServletResponse) resp;
        Object user = request.getSession().getAttribute("loginUser");
        String uri = request.getRequestURI();
        if (user == null && uri.endsWith(".jsp") && !uri.contains("login")) {
            response.sendRedirect("login.jsp");
            return;
        }
        chain.doFilter(req, resp);
    }
}

这个Filter在web.xml里配置一下拦截路径，就能让整个系统登录失效时自动跳转。这个点放在论文里写，也是实打实的一小节“系统安全设计”。

6. 论文撰写与答辩演示：代码写完只是完成了一半

6.1 论文结构怎么搭才不露怯

毕设论文的常规结构是：绪论、需求分析、系统设计、系统实现、系统测试、总结。但很多学生的论文之所以被批“像流水账”，是因为他们每一章都只是堆功能描述。想让论文有区分度，注意这几个关键点：

需求分析里一定要有“用例图”和“用例描述”。不要只画图，至少写2到3个核心用例的详细描述，包括参与者、前置条件、正常流程、异常流程。
系统设计里要有“架构图”和“功能模块图”。架构图重点体现分层，功能模块图体现系统由哪些模块组成，两者不能混淆。
数据库设计要有“ER图”和“核心表结构说明”。表结构别全贴SQL，挑五六张核心表说明字段和作用即可。
系统实现里要“原理+代码+界面截图”三件套。每个核心功能，先用文字描述实现思路，再贴关键代码片段，最后放截图。代码不要贴大段大段，只贴关键逻辑。

6.2 画图工具怎么选

画ER图和架构图，建议直接用draw.io（现在叫diagrams.net）或者ProcessOn。它们都有免费版本，导出的图片清晰度高，插入Word里不会糊。不推荐用Word自带的形状硬画，效率太低，而且画出来的图很难看。

另外，很多学生提交论文时才现画图，容易留下粗糙的痕迹。最好的做法是：每实现完一个模块，顺手就把对应的时序图、流程图、页面跳转图画出来。这样论文到后期只需要组装，不需要熬夜补图。

6.3 演示现场最容易翻车的三个细节

我参加过不少线上的毕设答辩，也帮学生演练过，发现演示环节翻车的往往不是系统功能本身，而是这些细节：

演示数据太假。员工姓名叫“张三”“李四”，出生日期全是1900年，这种数据不仅不真实，还会让评委对项目的认真程度打问号。
没有准备测试数据以外的演示脚本。很多学生演示时即兴操作，结果录入了一个非法数据导致页面报错，然后慌了。正确做法是提前准备好一份“演示脚本”：先登录admin演示员工查询，再跳转普通员工视角演示自助请假，最后切到HR视角演示审批通过，每一步都在什么状态下、该点什么按钮，提前写好。
没有考虑第二个浏览器。演示多角色系统时，需要同时打开一个admin账号和一个普通员工账号。很多学生在现场慌乱地退出再登录，时间就浪费了。提前准备一个浏览器开普通账号，一个无痕窗口开管理员账号，切换角色演示流畅且专业。

如果项目里实现了审批流，这里还有一个“演示保护”建议：审批流千万别在答辩现场从头构造数据。提前把“请假申请-主管审批-HR审批-审批完成”整个流程的数据存好，到现场只需要打开列表页展示状态流转即可。因为现场从零走审批，意味着你要同时操作两个账号，步骤一多，出意外的概率就指数上升。

6.4 如果被问到“系统的不足和未来改进方向”

这个问题几乎是答辩必问。不要答“没有不足”，那是给自己挖坑。也不要答“功能太少”，那是自我否定。建议准备几条既真实又不太伤分的内容，比如：

“当前审批流配置还比较固定，后续可以考虑引入更灵活的流程引擎，支持自定义审批路径。”
“薪资计算目前只支持固定公式，后续可以支持不同岗位套用不同的薪资模板。”
“目前系统是传统B/S架构，后续可以考虑做移动端适配，让员工在手机上提交请假和查看工资条。”

这些改进方向都是人事系统自然延伸，既承认了当前系统的局限性，又体现了你对行业应用的理解。

最后：做毕设的姿态，比代码本身更重要

我见过太多学生在这个题目上栽跟头，不是因为技术太难，而是因为心态上把毕设当成一个“要交的作业”。你有没有认真想过这个系统真实世界里会被谁用、怎么用、遇到过什么问题？有没有想过人事专员每天的工作流程是怎样的？这决定你做出来的系统是“能跑的演示品”还是“真正有逻辑的产品”。

如果让我给一条最实用的建议，那就是：从拿到题目的第一天开始，就用一个真实的HR视角去审视每个功能。想象你是一家50人小公司的HR，你每天需要录入新员工、给员工调岗、月底算考勤、发工资、审批请假单、办理离职。顺着这个视角，你的需求分析自然丰满，你的页面设计自然贴合实际，你的答辩讲稿也会更有底气。

做那个愿意在数据库设计阶段多画一张ER图的人，做那个愿意为员工表多造五十条真实数据的人，做那个愿意在答辩前演练三遍演示流程的人。这个题目能做成什么样，从来不取决于技术上限，而取决于你愿意为它投入多少对“真实世界”的理解。