企业官网建设流程全解析

每年三四月份，总会有一批同学在“毕设选什么题”上反复横跳。如果你也翻遍了往届题目清单，最后目光停在“SSM+Java人力资源管理系统”这几个字上，那么这篇东西大概率能帮你把从选题、开发到论文答辩的路一次捋顺。

这个方向我太熟了——我当时就是用 SSM 框架，从零手写了一套包含员工管理、部门管理、请假审批、公告发布等模块的人力资源管理系统，前后踩了不知道多少坑。这篇不会给你贴概念文档，而是把整个过程中值得认真对待的决策点、设计思路、编码细节和填坑记录都摊开讲清楚。看完你至少能少走两周弯路，也能知道论文里每一章到底该写什么才算有分量。

1. 毕设选题的逻辑：为什么“人力资源管理系统”是个稳中带秀的选择

1.1 电商、图书、小程序……我当时对比过的几条路线

不管在论坛还是群里，每年都会被问“毕设做什么题目好”。大家翻来覆去推荐的其实是三类：电商系统、泛化的管理系统、微信小程序应用。

电商系统听起来高大上，但问题在于“大象太重”。商品、订单、购物车、支付、库存、物流、优惠券，每个模块都能枝生出很多分支。更麻烦的是支付环节绕不开第三方平台或模拟支付方案，很多同学最后只能做一个很假的支付流程，答辩时被问“你的订单状态机怎么设计”“支付回调怎么保证幂等”，当场就卡壳。

图书管理系统和超市收银系统这类，问题恰恰相反：太常见。评审老师一年要看好几十份同题目的论文，看开头就能猜到结尾，基本就是单表或几张表的增删改查，业务深度撑不起来。

人力资源管理系统被我看中，是因为它的复杂度刚好落在“及格线之上，努力能冲到良好”的位置：有明确的角色区分，有审批流，有主数据管理，有检索统计，还有公告发布这种常规功能。它不是那种做到一半发现根本收不了尾的项目，也不是做完之后答辩没话讲的项目。

1.2 模块取舍：别让系统背上太多野心

拿到题目后我做的第一件事，不是打开 IDE，而是先划范围。企业级的 HR 系统功能树可以拉很长：组织架构、人事档案、考勤、请假、加班、薪资、招聘、培训、绩效、社保公积金……要是真照这个规模做，一个学期连个稳定的原型都跑不完。

我当时定下来的模块只有六个：

• 登录与权限控制（区分系统管理员与普通员工）
• 员工档案管理（入职登记、信息维护、离职状态、逻辑删除）
• 部门管理（部门增删改查、负责人设置）
• 请假审批（员工发起、管理员审批、状态流转记录）
• 公告管理（公告发布、列表查看、详情）
• 综合查询与统计（员工组合检索、部门人数统计）

这里要特别说一句：为什么要砍掉薪资模块。薪资表面上是一张工资表，但一旦要算实发金额，就会牵扯五险一金比例、个税阶梯、绩效系数等一堆业务规则。很多同学最后只能把薪资做成“手动填数字的 CRUD”，答辩时被问“你的税后工资计算规则是什么”，根本答不上来。如果非要做薪资，建议只保留工资项录入和月度汇总，不做自动计算。

相反，请假审批这种“有状态流转”的模块反而是加分项。它能体现你对业务过程的理解，代码上会涉及状态枚举、审批历史、权限隔离这些真实系统的要素，论文里也有得写。

2. SSM 技术栈在毕设层面到底怎么运转

2.1 Spring IoC到底给你省了多少事

SSM 这三兄弟的分工，很多同学一开始是模糊的。我的理解一直很朴素：Spring 管对象创建和依赖关系，SpringMVC 管 HTTP 请求的路由，MyBatis 管数据库访问。

先看 Spring IoC。没有框架的年代，Servlet 里要自己 new 一个 Service 对象，Service 里又要 new DAO。所有对象的生命周期都得自己管理，代码耦合度高得吓人。Spring 引入后，容器成了“对象托管中心”，谁依赖谁，只要写注解或 XML 声明就行。

举个例子：EmployeeController 需要调用 EmployeeService，EmployeeService 需要操作 EmployeeMapper 接口。我只需要在字段上加 @Autowired，容器就把初始化好的对象注入进来。各层之间的耦合度降下来，Controller 只负责接收参数、调 Service、封装结果；Service 只负责业务逻辑和事务边界；Mapper 只负责 SQL。这个分层结构本身在论文里也能画成一张很漂亮的“系统分层架构图”。

AOP 在这个项目里也有不可替代的作用——事务管理。比如“批量导入员工信息”，第 10 个人成功了，第 11 个人手机号格式错误，那前面 9 条数据必须全部回滚。这种场景如果手动在业务代码里写 commit 和 rollback，很容易漏掉一个分支。用 Spring 声明式事务后，业务方法上标注 @Transactional，抛出 RuntimeException 就自动回滚。

2.2 SpringMVC一次完整请求的流转

刚接触 SpringMVC 时，我对它的认知仅仅是“Controller 里写几个方法，URL 就能映射过来”。后来为了准备答辩，才把完整流程补上了：

前端发 HTTP 请求，DispatcherServlet 作为前端控制器接收；通过 HandlerMapping 找到对应 Controller 方法；执行前经过拦截器链；方法返回后经 HandlerAdapter 处理；如果是 REST 接口，直接通过 @ResponseBody 把对象序列化成 JSON 返回前端。

在 HR 系统里，我全部用的是 @RestController 返回 JSON，前端用 Ajax 请求，没上 JSP 服务端渲染。这样前后端交互协议非常清爽，答辩时也能讲出一套“前后端接口约定”。你不必把每个类的源码都背下来，但 DispatcherServlet、HandlerMapping 这两个概念一定要能说出来，答辩提问概率极高。

2.3 MyBatis：SQL和Java对象之间的胶水

MyBatis 的核心作用是把 Java 对象和数据库表记录映射起来。它不帮你凭空生成 SQL，而是把 SQL 的书写和维护变得更可控。

人力资源系统里最常见的一个需求，是员工列表的组合筛选：按姓名模糊查询、按部门下拉筛选、按入职时间范围查询。如果写原生 JDBC，就得在 Java 代码里手动拼接 SQL 字符串，条件一多就乱。

用 MyBatis 后，SQL 写进 Mapper XML，动态条件用 和 标签控制。数据库中下划线字段如 create_time 和 Java 属性 createTime 之间的映射，只需要开启 mapUnderscoreToCamelCase 配置就行。

这里有一个我比较坚持的经验：带动态条件、多表关联的查询，统一放 XML；简单单表 CRUD 用注解。两种方式配合使用，代码可读性最高。千万别在 Service 层里手动拼 SQL 字符串来替代，后期参数一多就是灾难现场。

3. 数据库设计：整个项目里最值得慢下脚步的一步

3.1 权限模型：为什么我不建议直接上 Shiro 或 Spring Security

一说到权限控制，网上九成推荐是“引入 Shiro”或“引入 Spring Security”。我犹豫了很久，最后还是决定自己写一个最轻量的 RBAC 模型。

原因是：这个项目只有两种角色，管理员和普通员工。引入一套完整权限框架后，你要理解过滤器链、授权管理器、安全上下文、注解权限控制这些概念。概念本身很好，但对一个小型毕设来说，学习成本高、排查问题难，而且答辩时老师不一定买账。

我当时的方案非常朴素：用户表带 role_id 字段，1 是管理员，2 是普通员工。登录后把角色放进 session，前端按角色渲染菜单；后端再加一道 SpringMVC 拦截器，判断请求路径是否越权。这种“双重校验”虽然代码量多一些，但每一行你都能讲明白它的作用——答辩时这种“我知道自己在做什么”的感觉太重要了。

3.2 核心表的设计与字段规划

画完 E-R 图后，我最终确定的表结构如下：

拿员工表和请假单来举个例子，建表语句大致长这样：

CREATE TABLE tb_employee ( id INT PRIMARY KEY AUTO_INCREMENT, emp_no VARCHAR(20) NOT NULL UNIQUE COMMENT '工号', name VARCHAR(30) NOT NULL COMMENT '姓名', gender TINYINT DEFAULT 0 COMMENT '1男 2女', birth_date DATE, phone VARCHAR(20), email VARCHAR(50), dept_id INT, position VARCHAR(30), entry_date DATE, is_deleted TINYINT DEFAULT 0 COMMENT '0正常 1删除', create_time DATETIME DEFAULT CURRENT_TIMESTAMP );

CREATE TABLE tb_leave ( id INT PRIMARY KEY AUTO_INCREMENT, employee_id INT NOT NULL, leave_type VARCHAR(10) COMMENT '事假/病假/年假', start_time DATETIME, end_time DATETIME, reason VARCHAR(255), status TINYINT DEFAULT 0 COMMENT '0待审批 1通过 2驳回', approver_id INT, approve_comment VARCHAR(255), create_time DATETIME DEFAULT CURRENT_TIMESTAMP );

3.3 密码安全细节：加盐MD5的完整解法

用户表里我特意设计了一个 salt 字段。密码不是直接 MD5 加密，而是为每个用户生成一个随机盐值，存到 salt 字段里，最终密码字段存的是“盐值 + 原始密码”做两轮 MD5 后的结果。

为什么这么绕一圈？因为无盐 MD5 生成的固定密文，攻击者可以直接用彩虹表比对反推明文。加了随机盐之后，即使两张用户表的密码哈希碰巧一致，也无法推断出相同密码；整个数据库泄露，破解难度也高很多。

这不算高深技术，但在论文“系统安全设计”小节里非常加分。答辩被问“数据安全怎么处理的”，你至少能答出三个层面：密码加盐哈希、后端参数校验、逻辑删除保护历史数据。

3.4 逻辑删除：保住历史关联的钥匙

删除员工时我没有用 DELETE 语句物理删除，而是将 is_deleted 设置为 1。原因特别实在：员工一旦物理删除，过去请假单里的 employee_id 就变成“查无此人”，关联数据全断了，后续做任何统计都会失真。

逻辑删除之后，前端查询默认过滤 is_deleted=0 的数据；但历史链路查询、离职员工追溯依然能通过 employee_id 关联到原档案。这个设计虽然是老生常谈，但在毕设里能认真做的人真不多，属于“答辩里值得主动提出来讲”的点。

4. 编码实录：登录、员工管理、请假审批的关键代码路径

4.1 登录认证与 Session 方案

登录模块的流程本身不复杂：输入用户名密码，后端查出用户，校验加密后的密码，检查账号状态，通过则写入 session。

public User login(String username, String password) { User user = userMapper.findByUsername(username); if (user == null) { throw new BizException("用户不存在"); } String hashed = md5WithSalt(password, user.getSalt()); if (!hashed.equals(user.getPassword())) { throw new BizException("密码错误"); } if (user.getStatus() == 0) { throw new BizException("账号已被禁用"); } return user; }

登录成功之后，把用户 id、角色、员工基本信息放进 session。为什么不需要 JWT？因为这个系统是典型的单体 Web 应用，页面和后端部署在一起，session 方式实现简单，也没有 token 过期、续期这些额外的处理逻辑。我在论文里专门写了一个“认证方式对比”小节，把 Session 和 JWT 的适用场景对比一下，这事就讲透了。

4.2 员工管理：分页查询、新增校验、逻辑删除

员工列表页的核心是“组合查询 + 分页”。组合查询用我前面提到的 MyBatis 动态 SQL 实现，分页则直接用了 PageHelper。

public PageInfo<Employee> queryPage(EmployeeQueryDTO dto) { PageHelper.startPage(dto.getPageNum(), dto.getPageSize()); List<Employee> list = employeeMapper.selectByCondition(dto); return new PageInfo<>(list); }

Mapper XML 里的动态查询是这个样子：

<select id="selectByCondition" resultType="com.example.entity.Employee"> SELECT * FROM tb_employee <where> <if test="name != null and name != ''"> AND name LIKE CONCAT('%', #{name}, '%') </if> <if test="deptId != null and deptId != 0"> AND dept_id = #{deptId} </if> <if test="entryDateStart != null"> AND entry_date &gt;= #{entryDateStart} </if> <if test="entryDateEnd != null"> AND entry_date &lt;= #{entryDateEnd} </if> </where> ORDER BY entry_date DESC </select>

新增员工时，除了必填项校验、手机号格式、邮箱格式校验之外，还要查一下工号 emp_no 是否重复。工号我设计为管理员手动填写，系统在提交时做唯一性检查，这是真实系统要求的数据一致性约束，不是纸上谈兵。

删除走逻辑删除，更新 is_deleted=1。这个细节前面的章节已经讲过，但在编码时一定要记住：删除的同时要判断该员工是否已有请假记录，如果有，只做逻辑删除不影响关联表完整性。

4.3 请假审批的状态流转与时间重叠判断

请假模块是整个系统里最像“业务流程”的地方。状态只有三种：0 待审批，1 已通过，2 已驳回。员工提交请假单，状态置为待审批；管理员在审批列表看到申请，点击通过或驳回，状态随之更新，同时插入一条审批历史记录到变更日志表。

状态流转的代码不算复杂，真正考验细节的是两个校验：

第一，开始时间不能晚于结束时间。这个前端就能拦，但后端也要做，因为接口可以被绕过。

第二，时间重叠。同一个员工在同一时间段，不能同时存在两条有效的请假单：

int count = leaveMapper.countOverlap(employeeId, startTime, endTime); if (count > 0) { throw new BizException("该时间段已有请假记录"); }

对应 SQL 是时间区间的经典重叠判断写法：

SELECT COUNT(*) FROM tb_leave WHERE employee_id = #{employeeId} AND status != 2 AND start_time < #{endTime} AND end_time > #{startTime}

这个写法的逻辑是：只要两条记录的时间范围相互穿插，就说明存在重叠。很多新手会写成 start_time >= 新开始时间 这种简单比较，很容易漏掉“跨段交叉”的场景。把这个 SQL 讲清楚，答辩时能体现你对边界情况的敏感度。

4.4 前端页面结构与接口约定

前端我用的经典三件套：HTML + CSS + JavaScript。样式框架选择了 Bootstrap，AJAX 用 jQuery，整体是左侧菜单栏加右侧内容区的后台管理布局。根据角色不同，前端加载的菜单项也不一样，管理员能看到“用户管理”“请假审批”等入口，普通员工只能看到“个人中心”“我的请假”“公告列表”。

前后端接口统一返回一个 Result 对象，包含 code、msg、data 三个字段。前端 JS 只需要判断 res.code == 200 就能决定刷新页面还是弹错误提示，省去了每个接口单独写错误处理的重复代码。这个小约定虽然简单，但让你的前后端协作清晰很多。

5. 联调部署与填坑记录：那些文档里不会写的事情

5.1 Maven依赖版本冲突现场

我刚开始启动项目时，控制台一直报 NoSuchMethodError。定位半天发现是 Spring 全家桶内部版本不一致——一个 jar 是 5.1.8，另一个 jar 是 5.3.9，类签名对不上，运行时直接炸。

这个问题在毕设项目里太常见了。网上找的依赖，一篇博客给的是老版本，另一个教程给的是新版本，拼到一起就是冲突。解决办法很简单：统一用一个 spring.version 属性，或者干脆找一个完整能跑通的 pom 骨架，把里面所有依赖版本对齐，不要逐个去“升级”。

5.2 MyBatis驼峰映射没生效

员工查询接口返回的 createTime 字段一直是 null，日志里 SQL 查询明明有值。排查了半天，发现是 mybatis-config.xml 里没开驼峰映射：

<settings> <setting name="mapUnderscoreToCamelCase" value="true"/> </settings>

这个开关没开时，create_time 这个列名无法自动映射到 createTime 属性。只要数据库字段命名和 Java 属性命名风格不一致，就一定会出现类似的诡异 Bug。建议项目初始化时就打开，并且全项目统一风格，不要在某个 SQL 里写别名，另一个 SQL 里靠配置，两边混用只会更乱。

5.3 中文乱码的全链路排查

中文乱码问题几乎是 SSM 新手必踩的坑，而且不是“配一个地方就完事”。我总结下来有三处必须同时设置：

• HTTP 请求编码：web.xml 里配置 CharacterEncodingFilter，强制 UTF-8。
• HTTP 响应编码：SpringMVC 的消息转换器里设置 UTF-8。
• 数据库存取编码：连接 URL 加上 characterEncoding=utf8，建库时默认字符集设为 utf8mb4。

这三处缺了任意一个，都会在某类场景下冒出乱码。比如请求参数乱码，但数据库读出来正常；或者数据库插入乱码，但页面显示正常。表面问题一样，根源完全不同，所以我建议项目搭建的第一天就把这三处配齐。

5.4 JDK版本与Tomcat版本的隐性约束

还有一个高频坑：本地装了 JDK 17，但项目编译级别还停留在 1.8，Tomcat 启动时总是报模块相关的访问错误。花了大半天排查，最后换成 JDK 8 才消停。

SSM 这套技术栈的历史包袱比较重，很多依赖在 JDK 8 时代就成熟稳定了。毕设阶段，我不建议追求“最新环境”。老老实实用 JDK 8 + Tomcat 8.5/9.0 + Maven 镜像，开发体验反而顺。项目能稳定跑起来，比什么都重要。

6. 论文写作与答辩准备的进阶思路

6.1 论文结构：别把系统实现写成目录

我见过太多同学把论文“系统实现”章节写成包目录的复制粘贴，到处都是“ConfigController 类中有 xxx 方法”，通篇没有业务逻辑。这个写法是论文中的常见误区，也是最容易被扣分的点。

我的建议是每个模块都用“三段式”来写：

• 第一段，说清业务背景和设计目标；
• 第二段，描述业务逻辑的处理过程；
• 第三段，给出关键代码并解释解决什么问题。

拿请假审批举例，论文里的正确写法应该是：“员工提交请假单后系统校验时间区间，若与已有单据重叠则提示冲突；状态置为待审批，管理员可在审批列表进行通过或驳回操作，操作记录持久化到变更日志表，保证审批过程可追溯。”然后再配状态流转图或关键 SQL，解释为什么这样设计。

需求分析章节也别只写“本系统需要实现员工管理”这种空话，而是用角色、功能、输入输出这三要素把需求描述具体。例如：“普通员工登录后可查看个人资料、发起请假申请、查看审批结果；管理员可以维护员工档案、审批请假、发布公告。”这样的需求描述展开后，系统边界一下子就清晰了。

6.2 答辩场上被问到的问题，我整理成了一份清单

6.2.1 为什么不用 Spring Boot

这是我每次都会主动回答的问题。核心思路是：Spring Boot 的自动配置让开发更快，但也掩盖了很多底层细节。论文阶段做 SSM，能展示你对 SpringMVC 请求流程、MyBatis 配置原理、分层架构思想的理解。如果老师继续追问，可以补一句“我也学习过 Spring Boot，理解约定优于配置的思路”，既能体现知识面，又不否定主流技术。

6.2.2 密码到底是怎么存储的

回答要点：不存明文，加盐哈希，数据库连接保持安全。再补充一句“生产环境要求更高，可以用 BCrypt 或专门的密钥管理方案”，把上限也展示出来。

6.2.3 员工删除后历史数据怎么保持完整

这个问题的回答很简单，但前提是代码里真做了逻辑删除才行：“我采用逻辑删除，删除操作只是把 is_deleted 置为 1。这样请假模块在查询历史记录时仍能通过外键关联到原员工档案，离职员工的历史请假单不会丢失。”这种基于实际设计的答案，比背八股文有说服力得多。

6.2.4 PageHelper分页插件是不是必须的

可以诚实回答：它是一种轻量级分页封装，底层自动生成 limit 语句；如果手写分页，需要自己处理总记录数、总页数、当前页数据量。用 PageHelper 就是把这些工作接管了。这样回答既坦诚，又说明你明白原理，不是只会调用工具。

写在最后的一点个人体会

做一个 SSM 人力资源管理系统，我的最大收获不是背熟了框架 API，而是真切体会到了“设计先行、编码在后”的节奏。先把角色和业务流程想清楚，再把表设计好，最后写代码时思路会特别顺；反过来，先急着敲代码，后期改表结构、改接口的日子有多难过，做过一次就懂了。

如果时间只够规划两个月，我的建议是：前两周专心做需求分析和数据库设计，中间一个月写后端和页面，最后两周留给测试和论文。要是还有余力，可以给系统加一个 Excel 导出员工列表的功能，或者把前端换成 Vue 做一个简化版，作为论文“系统扩展”章节的素材。把基础模块跑稳，比什么都管用。