企业官网建设流程全解析

做毕设选题的时候，很多人一看“人力资源管理系统”这七个字，第一反应就是“又是烂大街的CRUD”。实际上，把人力资源和寿险行业的业务特征绑定起来，这套系统的技术含量和答辩亮点就完全不一样了。寿险公司的人力资源管理，跟普通企业的最大差异在于组织架构复杂、代理人队伍庞大、佣金薪酬结构特殊，这些业务特性会直接影响数据库设计、权限模型和薪资计算模块的实现方式。这篇文章就把我当时做这个基于JAVA和Spring Boot的寿险公司人力资源管理系统的完整思路拆开来讲，从选题判断、技术选型、数据库设计，到核心模块实现、部署交付的坑，一次性说清楚。不管是正在纠结毕设选题，还是已经选了类似题目不知道怎么往下推的，这篇都能给你一个可以直接上手的参照。

1. 寿险公司HR系统的业务特殊性在哪，选题价值怎么判断

人力资源管理系统本身不是什么新鲜东西，市面上开源的一抓一大把。但如果把场景切到寿险公司，整个系统的设计重心会发生明显偏移，这些偏移才是你这个毕设区别于“图书管理”“超市进销存”的真正价值点。

1.1 寿险行业的人力结构决定了“组织架构”要单独设计

普通企业的人力资源系统，部门表通常就一个parent_id递归下去完事。但寿险公司不一样，它的组织体系是一套非常典型的多级树形结构：总公司下面是省分公司，省分公司下面是中心支公司，再往下还有支公司、营销服务部。营销服务部下面还挂着大量的保险代理人，而这些代理人很多不是劳动合同制员工，是代理制人员。

如果你毕业设计里的人力资源管理系统只是做个简单部门分类，答辩时老师一问“你这个组织架构怎么支持寿险公司省、市、县三级管理？”你答不上来，系统就被判定为“没有业务场景适配”。所以我在设计组织架构表的时候，专门加了一个org_level字段，区分总公司、分公司、中心支公司、支公司、营销服务部这五级，同时为代理人员设计了一个user_type字段，区分正式员工和代理制人员。这个设计看起来只是多了两个字段，但背后反映的是你对寿险行业人力特征的判断。

1.2 薪酬模块里的“佣金计算”是HR系统的行业分水岭

普通企业的人力资源系统，薪资模块一般就是基础工资加绩效再加扣款，公式固定。寿险公司的人力薪酬则要处理保险代理人的佣金，佣金又跟保单的险种、缴费年限、月度业绩考核挂钩。你不可能在每个员工的salary表里手动填一个“佣金”字段了事，那这个系统就成了Excel表格换个壳。

我当时把薪资模块拆成了几个层次：固定薪资部分（基本工资、岗位津贴、保险扣款）走常规计算公式，佣金部分单独建了一张佣金发放表，记录佣金批次、业务员编号、考核月份、佣金金额。这样设计的好处是，答辩的时候你可以讲清楚“保险公司的薪酬是由固定部分和浮动佣金组成的，浮动部分来源是业务系统，与HR主数据松耦合”，这个说法在业务理解层面一下就立住了。

从选题价值来说，同一套Spring Boot技术栈，做“超市管理系统”和做“基于业务场景的寿险HR系统”，前者的天花板是CRUD熟练度，后者的天花板是业务理解力。毕设评分里，项目创新性和业务复杂度占的比重通常比较高，这就是一类“海绵级”好拆解也相对不容易撞车的题目。

1.3 别小看HR系统的“用户权限”需求

如果去调研寿险公司内部信息的保密要求，你会发现它的权限管控比普通企业严格得多。省分公司的人力专员不应该看到总公司的战略薪酬数据，支公司的柜员和总部的薪酬主管在同一个系统里，面对的数据范围完全不同。所以这套系统我把RBAC（基于角色的访问控制）当成一个核心模块来认真做，而不是简单判断“有没有登录”。

做这个模块，我被问到最多的问题就是“Spring Security和Shiro到底选哪个”。我在这一版里用的是Spring Security加JWT，理由后面会展开说。总之，不要等到做权限模块的时候才头疼，选题阶段就要想清楚，HR系统的价值有很大一部分就体现在权限设计上。

2. 技术选型与项目初始化：Spring Boot 3 + JDK 17的判断思路

技术选型这块，我的原则是“不追新到没资料，也不用快到被淘汰”。很多同学一上来就问“Spring Boot 3行不行”、“JDK 17要不要升”。我的回答是：如果你的毕业设计从零开始做，直接上Spring Boot 3加JDK 17，没有悬念。

2.1 为什么不用Spring Boot 2而是直接上3.x

Spring Boot 2.7虽然还在企业里大量存在，但它已经停止商业支持了，这个阶段做新项目再选2.x有点逆流。Spring Boot 3（对应Spring Framework 6）要求JDK 17起步，JDK 17是LTS版本，资料和学习曲线在整个Java生态里是最平滑的。

真正要注意的不是版本本身，而是Spring Boot 3带来的几个迁移影响。首先，以前很多代码里写javax.servlet、javax.persistence这种包名，现在全部要改成jakarta.*，如果你的参考代码是两三年以前的，复制粘贴后会出现大量红色编译错误，这不是你代码错了，是API坐标换了。其次，Spring Boot 3的自动配置文件从spring.factories变成了META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports，如果做自定义starter才会碰到，毕设一般用不到，但面试时可以提到。

我当时搭建项目用的是Spring Initializr官网直接生成的Spring Boot 3.x工程，依赖选了Web、Validation、MyBatis、MySQL Driver（如果要用MySQL 8的话）、Lombok和Spring Security。这里有一个小提醒：Initializr生成的groupId和artifactId最好一次写对，后面改起来虽然不麻烦但很影响心情。我习惯把项目名写成hr-management，包结构用com.xxx.hr.

2.2 MyBatis-Plus：简化和克制之间的平衡

有人在这个项目里喜欢用Spring Data JPA，也不是不行。但我个人更推荐MyBatis-Plus，原因有两个：第一，HR系统里大量的单表查询、条件分页、逻辑删除，MyBatis-Plus官方的BaseMapper直接给你把CRUD包好了，能省大量重复SQL；第二，你后续如果需要展示自己会写复杂SQL，比如多表关联查员工工资记录，自己写的Mapper XML又有地方发挥，两头都站得住。

MyBatis-Plus有一个比较坑的地方是字段自动填充和逻辑删除有配置要求。比如你在员工表里放了create_time和update_time，希望插入和更新时自动写入时间，需要在实体类字段上标@TableField(fill = FieldFill.INSERT)和@TableField(fill = FieldFill.INSERT_UPDATE)，同时自己实现一个MetaObjectHandler。如果不配，数据库时间字段就一直是null，看起来“功能没做完”。

2.3 数据库和连接层的选型细节

数据库我选了MySQL 8.0，字符集用utf8mb4，排序规则用utf8mb4_general_ci，这个选择几乎没什么争议。连接池用HikariCP，Spring Boot 2.0之后默认就是它，不需要额外配置。但要注意MySQL驱动的依赖坐标，在Spring Boot 3里用的是com.mysql:mysql-connector-j，而不是旧版的mysql:mysql-connector-java。这个坑，网上还能看到很多老教程写错。

初始化项目阶段我额外做了一件事：把统一的统一返回体（result code, message, data）、全局异常处理器、跨域配置一次性写好。这个动作强烈建议放在做任何业务功能之前，因为后面几十个接口都要返回统一格式，你如果一个一个手动写，改起来能把人改疯。统一返回体用泛型类ApiResult ，全局异常用@RestControllerAdvice，跨域配置用WebMvcConfigurer的addCorsMappings，这些代码Spring Boot都有标准写法，照常抄就行。

3. 系统架构与数据库设计：RBAC权限模型和组织架构的落地

数据库设计是这类毕设的重头戏，也是答辩时最容易被深挖的部分。我设计表的时候，遵守了一个原则：先画业务关系图，再动SQL。HR系统的核心实体没有多复杂，但关系和约束比较多，捋不清楚后面全是坑。

3.1 员工、部门、岗位、用户的四表关系

员工表staff_info是主数据，字段包括：staff_no（工号，唯一索引）、name、gender、birth_date、id_card、phone、email、dept_id（关联部门表）、position_id（关联岗位表）、hire_date、probation_end、work_status（在职/离职/停薪留职）、user_type（正式员工/代理人员）、salary_card（工资卡号）等。

部门表sys_dept的核心是parent_id和org_level，这两个字段决定了组织架构的树形展示和权限分层。岗位表sys_position相对简单：position_name、position_code、position_level，比如“初级组训岗”“省级分公司总经理”这些，在寿险体系里岗位职级体系很成熟，直接对应即可。

员工表和用户表的关联是很多人都处理不好的地方。有的系统给员工表直接加上username和password字段，看起来省事，但实际上员工和系统登录用户不是一一对应的。代理人可能不登录系统，而系统管理员可能不是员工。所以我拆了两张表：staff_info存员工主数据，sys_user存登录账号，两张表用staff_id关联，并允许sys_user.staff_id为null（管理员账号）。这个设计在答辩时讲出来，老师会觉得你的边界感很清晰。

3.2 RBAC五表模型的具体实现

sys_user、sys_role、sys_menu、sys_user_role、sys_role_menu，这五张表是经典RBAC模型。sys_menu包括菜单ID、父菜单ID、菜单名、路由地址、权限标识（比如hr:employee:add）、类型（目录/菜单/按钮）。权限标识至关重要，因为Spring Security的方法级权限注解（@PreAuthorize）就是靠这个字符串去匹配的。

JWT在RBAC里的作用不能只停留在“登录后发个token”。我在登录认证过滤器里，每次请求都会解析token，取出用户ID，然后查询该用户的角色和权限集合，放入SecurityContext。注销登录时把token加入黑名单（用Redis的SETNX设置过期时间），这样避免了JWT无法在后端主动失效的天然缺陷。寿险公司的HR系统对账号安全、操作审计有要求，所以角色权限这块一定要做扎实。

3.3 薪资、佣金、考勤这些“流程表”怎么和主数据表衔起来

薪资表salary_employee每个月一条记录：staff_id、salary_month、base_salary、position_allowance、bonus、social_security、housing_fund、personal_tax、real_salary、create_by、create_time。佣金表commission_records对应代理人员：agent_id（还是staff_id）、commission_month、policy_count、premium_amount、commission_rate、commission_amount、settle_status。

考勤如果要做，我建议做轻量级：请假单表leave_request（staff_id、leave_type、start_time、end_time、reason、approve_status），不搞复杂的打卡算法。寿险公司外勤人员和内勤人员的考勤逻辑差异非常大，外勤经常不在办公室，打卡系统做深了收不住。毕设的核心是展示流程闭环，请假审批走完“提交-部门审批-HR归档”就够了。

数据库里还有一个值得提前做的东西：字段注释。设计表的时候每个字段都写COMMENT，后面生成实体类、写文档、答辩展示都会顺畅很多。我见过太多人建表不写注释，三个月后自己都不知道salary_card是干什么的。

4. 核心功能模块的实战实现：从员工档案到薪资统计的完整链路

前端选型和交互不影响后端核心逻辑，但做一个HR系统，前端也建议直接用Vue 3加Element Plus，因为表格、表单、弹窗、分页这些组件现成的，能快速搭出管理后台的观感。后端功能模块我按业务流程排列，每一步里都有一些实操细节值得说。

4.1 员工档案管理：批量导入花名册的真实痛点

员工档案的增删改查是标配，但真正拉开差距的是批量导入功能。寿险公司的人力专员手里经常是一份几千行的Excel花名册，系统里如果只能一条一条录入，实用价值直降为零。我用的是EasyExcel这个库，在导入接口里做三层校验：第一层是Excel模板格式校验，第二层是每行数据的字段校验（身份证号位数、手机号格式、必填项），第三层是重复校验（工号是否已存在、身份证号是否已存在）。

这三层校验的代码逻辑不算复杂，但有一个非常关键的设计：不能校验出错就中断整个文件导入，然后把几千行数据全部回滚。正确做法是逐行校验，把错误行号和错误原因收集到列表中，返回给前端展示，让用户只修正错误行后重新导入。这个交互和实现是生产环境最常见的要求，放进毕设里立刻显得有实战经验。

4.2 组织架构管理：树形表格和递归查询太值得写了

组织架构管理最重要的接口是“按层级加载部门树”。前端一进来先显示根节点，点击展开时通过deptId异步加载子部门。后端对应接口是GET /dept/{parentId}/children，返回当前父部门的直接子级列表。这种懒加载模式比一次性返回整棵树对数据库的压力小，而且前端交互更顺手。

还有另一个接口是“查询部门及其所有子部门的员工列表”。这个在HR系统里很常见：比如营销服务部经理要看见整个支公司下属所有团队的人。后端实现时，先递归收集部门ID集合，然后WHERE dept_id IN (...)就可以。我在这个功能里使用了MyBatis-Plus的LambdaQueryWrapper，递归时注意用Set去重，防止部门层级在数据异常时出现循环引用导致死循环。

4.3 请假审批流程：状态机思维和操作日志

请假审批我一开始想做复杂的流程引擎，后来及时踩了刹车：毕设最忌给自己挖大坑。用Flowable或者Activiti搭建工作流，学习成本和调试成本都是几何级增长，而且对于“提交-审批-归档”这种单线流程来说纯属大炮打蚊子。

我最终实现的方式是：请假表里维护approve_status字段，0待审批、1通过、2驳回、3已撤销。提交请假后状态为0，审批人调用审批接口时传入同意或驳回，同时记录操作日志表和审批记录表。这里的核心细节是：审批记录不能只存最终结果，要把每一次流转的动作记录下来，包括审批人、审批时间、审批意见。这样员工查看历史记录时会看到完整链路，答辩时也可以说“这是可追溯的审批流，满足企业合规审计要求”。状态机不一定非得用Spring StateMachine，用枚举加状态流转校验方法更直观，也容易跟老师解释清楚。

4.4 薪资模块：个税计算和佣金数据展示的逻辑细节

薪资模块的技术实现里，个税计算是最容易出事的部分。中国个税是累进税率，按年累计计税，从2024年之后的规则是每月预扣预缴，到年底汇算清缴。毕设系统不可能做完全真实的个税引擎，但至少要做到“按当月收入做初步计算”，并把起征点5000元和七级累进税率表放在后端代码里。

我实现的方案是：TaxCalculator工具类输入税前收入，输出个税金额，税率表用数组或者枚举定义。这个工具类虽然公式简单，但放对位置、注释写清楚，答辩时就可以讲“实际系统里个税应该由薪资系统与税务系统对接，我这里做了一个简化的预扣预缴引擎”。这段话比任何花哨的界面都能说明你的思考。

佣金数据展示方面，前端用一个单独的Tab页展示佣金列表，后端接口从commission_records表按月份、代理人号筛选。寿险HR系统里，正式员工的薪资和代理人的佣金是两套东西，系统里如果要看“工资总额统计”，需要按类型分开统计，不能混在一起。这个点很多学生做的时候不注意，答辩一被问就露馅。

4.5 统计看板：给答辩加分的仪表盘设计

系统首页放一个统计看板，展示在职员工总数、部门分布、学历分布、年龄分布、月度入职/离职趋势。这些统计接口用SELECT COUNT(*)加GROUP BY就能实现，但呈现效果却非常好。我建议后端用四个接口分别返回统计数据，前端用图表库渲染，不用搞复杂的联表SQL。ECharts是首选，柱状图、饼图、折线图各来一个，界面立刻就有“成品感”。

做这个模块有几个非常实际的细节：月份趋势图的数据天生就适合用GROUP BY hire_month去查，但要考虑没有入职记录的月份要不要填充0；部门分布图要注意org_level过滤，否则会同时统计出过多层级的部门导致饼图拥挤。这些小细节调好，演示的时候观感会非常舒服。

5. 部署交付最容易翻车的几个环节：打包、环境、讲解

毕设做得再好，部署不起来就是零分。我见过太多人代码写得没有问题，结果打包的时候JAR启动就报错，或者数据库连接串没改，到答辩现场系统白屏。这一节专门说部署和交付的实操经验。

5.1 Maven打包别用IDE的一键按钮，用命令行

在IDEA里点maven的package看起来人畜无害，但部署到服务器或者别的机器上时，经常出现“本地能跑，打出来JAR跑不了”的情况。我的建议是走命令行的全量打包：

mvn clean package -DskipTests

注意这里一定要加-DskipTests，否则单元测试如果写了但没跑通，打包直接失败。打包成功后，JAR文件在target目录下。很多人在这一步遇到的问题其实是前端资源没有打进JAR，如果你的项目是前后端分离的，需要把前端构建后的dist目录拷贝到Spring Boot项目的static目录下，再重新打包，才能一个JAR单机运行。如果你把前端和后端分为两个项目部署，那就不要往static里放，直接前端服务器配置代理指向后端端口。

5.2 外置配置和数据库版本不匹配的坑

Spring Boot的数据库连接配置默认写在application.yml里，如果你把配置打进JAR，换一台机器部署就必须重新打包。更合理的做法是，在JAR包同级的config目录放一个application-prod.yml，然后在启动命令里指定：

java -jar hr-management.jar --spring.profiles.active=prod

这样可以把数据库地址、Redis地址、JWT密钥这些敏感配置从代码里拆出去，演示时换数据库只需要改外部配置。MySQL 8.0的驱动连接串里要加serverTimezone=Asia/Shanghai，否则报时区错误。

5.3 答辩演示前把“关键数据预置”好

一个让人很崩溃的现场是：答辩老师来了，你想演示登录，结果刚创建的账号被锁了；你想演示薪资统计，结果数据表是空的，图表页白茫茫一片。所以答辩前一定要准备好Demo数据：至少创建三个角色账号（管理员、HR专员、部门经理），录20个以上员工档案覆盖多个部门，添加两个月的薪资发放记录，加几条请假审批单，保证每个菜单点进去都有数据可看。

预置数据的方式我建议写一个DataInitializer配置类，在应用启动时检查数据库是否为空，为空则自动插入种子数据。这个类在ApplicationRunner里执行，代码逻辑非常清晰，演示前启动一次项目数据就有了。

5.4 讲讲解的时候重点讲“为什么”，不要背操作步骤

答辩时很多学生喜欢演示完就开始讲“我点击这个按钮，然后数据就显示出来”。其实老师真正想听的是你设计的时候为什么这样选。你完全可以说：我登录校验为什么用JWT，是因为无状态认证更适合前后端分离；我权限模型为什么用RBAC五张表，是因为寿险公司组织层级复杂、角色差异大；我批量导入为什么逐行校验而不整体回滚，是为了贴近人事专员实际使用场景。

这些话只要在你的开发过程中真的想过，是不需要背的。这也说明，做项目的时候不要照着网上的代码无脑抄，每抄一个模块，多想一步“它为什么这样设计”，答辩状态会完全不一样。

6. 我做完这套系统后踩过最深的一个缓存坑，顺带聊聊日志规范

最后补充一个我在这个项目中实际踩过的、也是网上描写比较少的坑：@Cacheable注解在同一个类内部调用时失效的问题。比如SalaryServiceImpl里有一个计算个税的方法，用@Cacheable缓存了计算结果，结果我在同一个类的另一个公开方法里直接this.taxCalculate()，注解直接就失效了，每次调用都在重新算。原因是Spring的缓存代理是基于AOP的，内部方法通过this调用绕过了代理对象。解决办法很简单：要么把缓存方法拆到单独的Bean里，从外部注入调用；要么自己注入ApplicationContext，从容器里拿到代理Bean再调。我之前在网上看过很多人都推荐第二种“注入自己”，实际上最干净的做法还是拆Bean。

顺带说一下日志规范。SSM和Spring Boot项目里最常见的现象是System.out.println满天飞。这在毕设代码里非常扎眼，老师看到会先扣印象分。我当时直接在工具类里封装了一个基于Slf4j的日志工具，Controller和Service里所有关键步骤都用log.info和log.error输出，包括请求处理耗时、批量导入的错误条数、登录失败的用户名等。日志留下来对调试和答辩都很有价值，因为老师经常会问“你怎么排查问题”，这时候你就可以说通过日志链路排查。

这个项目从选题到部署完整走下来，我最深的体会是：毕设项目的评分高低，往往不取决于你用了多新的框架技术，而取决于你有没有把技术用在恰当的业务场景里。同样是人力资源管理系统，寿险公司的组织层级、佣金薪酬、严格权限这几个特性，就是你区别于其他人的核心亮点。如果让我再总结一次开发顺序，那就是：先梳理清楚寿险的业务边界，再定数据库表结构，接着写统一返回体和异常处理，然后按“认证授权 → 组织架构 → 员工档案 → 请假审批 → 薪资佣金 → 统计报表”的顺序逐模块推进。这套顺序每一步的产出都能自测，不会出现开发到一半推倒重来的情况。

如果你用的就是Spring Boot 3加MyBatis-Plus这一套组合，有条件的话可以把员工档案的批量导入、组织架构的懒加载树、基于JWT的登录鉴权这三个功能当成优先做扎实的对象。这三个功能每一个都有独立的业务价值，也是面试或者答辩时最容易被追问的部分。把这三点磨透了，整套系统的骨架就已经非常稳定，剩下的模块只是在这个骨架上充实血肉而已。