为什么我推荐用 SpringBoot Vue 写一套保险公司人力资源管理系统作为 Java 毕设每到毕业设计选题季后台消息里问得最多的就是老师Java 毕设到底做什么题目好这个问题我每年都要回答几十遍但大部分同学在选题上的思路其实都是错的——要么选个图书管理系统、学生管理系统这种增删改查大全答辩时候被老师一句你和别人有什么区别问得哑口无言要么选个深度学习、分布式秒杀这种超纲严重的方向做了三个月连 Demo 都跑不通最后痛苦到想退学。今天我要推荐的题目是基于 SpringBoot Vue 的寿险公司人力资源管理系统。这是一个我见过非常多次、也亲自指导过不少学生顺利完成的经典选题。它的技术栈就是目前 Java 后端招聘市场占有率最高的 SpringBoot Vue 前后端分离组合业务上则覆盖了人力资源管理的完整闭环同时因为加了寿险公司这个前缀让整个系统有了明确的行业属性避开了满大街都是的通用人事系统漩涡。这篇内容我会尽量写透为什么选它、系统要做什么、技术方案怎么定、数据库怎么设计、核心模块怎么实现、答辩怎么准备以及网上流传的附源码文档调试定制服务这类资源到底该怎么用、怎么避坑。无论你是 Java 期末大作业、课程设计还是正式毕业设计都值得仔细看完这一篇。顺便说一句如果你之前看过我的文章应该知道我不喜欢那种需求分析—概要设计—详细设计—总结的八股格式咱们就实打实地从做项目的角度聊把每个关键决策背后的原因都摊开来讲这样你拿到题目之后才能真正动起手来而不是只收获一篇收藏夹里吃灰的文档。1. 选题逻辑人事系统的复杂度恰好卡在能写清楚和有含金量之间1.1 为什么不是图书管理也不是电商秒杀先聊一个很多同学没想明白的问题毕业设计的题目难度到底应该怎么选答案很简单就一句话要选那种你自己能完整讲清楚每一个代码文件的用途的系统。毕业设计答辩时老师真正考察的不是你的系统有多炫酷而是这个系统是不是你自己做的、你懂不懂里面的原理、遇到问题你能不能排查。图书管理系统、学生管理系统确实简单但正因为太简单你随便找个教程敲一遍就能做完答辩时也根本展示不出深度而且每年全年级几百个人里一半都在做类似题目评审老师一看题目就开始打哈欠。反过来那些看起来非常高级的题目——比如基于微服务的电商秒杀系统、基于大数据的推荐系统、基于深度学习的图像识别——听着很唬人但绝大多数同学做出来的东西都是只搭了个壳子微服务拆了三个模块但每个模块都是空壳大数据拿了个现成数据集跑个 WordCount深度学习直接调用现成接口。这种项目一旦被老师深挖底层原理马上就露馅。所以我经常和学生们说毕设选题最怕的不是太简单而是能力配不上野心。人力资源管理系统恰好卡在一个非常舒服的位置上。它不是一个只有单表增删改查的玩具项目涉及员工档案管理、组织架构管理、考勤管理、薪资管理、招聘管理、培训管理、绩效管理等多个业务模块每个模块之间有清晰的数据关联前后端加起来能轻松到 20 张表以上代码量也足够撑起一篇像样的毕业设计论文。但这个系统的业务逻辑又不像电商秒杀那样有极高的并发要求、复杂的分布式事务它本质上是企业内部管理系统所有操作的量级都是公司内部员工这个范围技术上完全不需要引入微服务、消息队列、分布式缓存这些复杂组件一个单体应用 关系型数据库就能完美解决。也就是说这套题目的复杂度正好落在你踮踮脚能够到的区间能做出来也能讲清楚工作量看起来还不小论文也有东西可写。1.2 加上寿险公司四个字之后题目的辨识度完全不同了现在来说这个题目最聪明的地方——前缀寿险公司。你可能会觉得这不就是个噱头吗人事系统就是人事系统换个行业前缀有什么本质区别还真有。你仔细想想保险公司尤其是寿险公司的组织结构特点保险公司有着数量庞大的代理人队伍也就是我们常说的保险业务员这些代理人不属于公司正式员工但公司又要对代理人进行入司、考核、佣金结算、职级晋升等全流程管理同时保险公司内部还有大量的内勤员工两类人员的薪酬结构完全不同——内勤拿固定工资 绩效代理人拿佣金 业绩提成。这就导致了一个纯粹的通用人事系统放到保险公司场景下是水土不服的。通用人事系统只管正式员工的入转调离但保险行业还需要管理代理人的入司与解约、保单业绩的统计、佣金的计算与发放甚至不同职级的代理人还有不同的提成比例。这些需求都是带有鲜明行业特色的。所以在做这个系统的时候你不能只做一个员工信息增删改查而是要在通用人力资源模块之上增加代理人管理、业绩管理、佣金结算这些保险行业的特色功能。答辩的时候只要你能讲清楚为什么通用人事系统不能直接拿过来用、我们的系统为保险行业做了哪些定制化设计这就是一个非常有力的创新点比那些千篇一律的XX管理系统高出一个档次。从论文角度来说这个选题也天然自带研究背景你可以写保险行业数字化转型、保险公司人力资源管理的现状与痛点等等这些都是有真实材料可查的比空谈随着信息化技术的发展这种套话好写得多。1.3 就业角度SpringBoot Vue 是简历上最值钱的组合除了好做、有辨识度之外选择这个题目还有一个非常现实的考虑它直接对着国内 Java 开发岗位的主流技术栈。看一下现在的招聘市场就知道了Java 后端岗位的 JD 里SpringBoot 基本上是标配中的标配前端岗位里 Vue 的占有率在国内一直领先于 React。哪怕你投的不是前后端分离岗位面试官看到你简历上写着基于 SpringBoot Vue 的 XX 系统时至少不会因为技术栈陌生而把你过滤掉。而且人力资源管理系统这个业务场景在面试中的讨论度其实很高。面 Java 岗的时候面试官想考察你对业务场景的理解往往就是从你做过什么系统切入的。如果你做的是一个通用的商城系统面试官大概率会追问高并发、缓存、分布式事务这些让人头大的问题但如果你做的是 HR 管理系统面试官的提问方向会自然偏向权限设计、数据表设计、业务逻辑实现这些更贴近企业真实应用的内容这些都是你已经实打实做过的回答起来更有底气。我一直跟学生说毕业设计不要只把它当成一门课来应付它就是你的第一份工作经验。你的系统能写进简历能在面试中变成你和面试官对话的素材这套题目正好满足这个需求。2. 需求盘点一个合格的保险行业人事系统到底要管哪些事2.1 基础模块登录鉴权、权限控制、组织架构与岗位管理一个人力资源管理系统进门第一件事就是登录与权限。你要设计用户表、角色表、菜单表/权限表实现基于角色的访问控制RBAC系统管理员可以管理一切人事专员只能操作自己负责模块的数据普通员工登录后只能查看和编辑自己的个人信息提交请假、加班等申请。这里我用的是 SpringBoot JWT Vue Router 的前后端分离权限方案登录后后端签发 Token前端把 Token 存在本地存储里每次请求在请求头带上 Token后端用一个拦截器统一校验。在这个基础上组织架构模块要维护公司的部门树比如总公司—分公司—营销部—培训部这种层级结构岗位管理则要维护每个部门下的岗位信息比如部门经理、销售主管、保险代理人、组训专员等岗位并为每个岗位绑定薪资默认值。2.2 核心业务员工全生命周期管理这是整个系统的骨头。员工管理要覆盖从入职到离职的完整链路我把这一步拆成五个子模块员工档案维护员工的基本信息包括姓名、性别、身份证号、手机号、学历、入职日期、所在部门、所在岗位、用工类型正式编制 / 劳务派遣 / 代理人等字段。注意身份证号、手机号这类敏感信息的展示要做脱敏处理列表页只显示中间四位打星号的版本。入职登记新员工录入时自动生成工号并初始化账号密码账号默认就是工号密码默认是身份证后六位首次登录必须修改密码。转正管理记录员工的试用期起止时间转正操作是一个审批流程员工提交申请 → 直属领导审批 → 人事部门确认。调动管理记录员工跨部门、跨岗位的调动记录调岗之后部门字段和岗位字段会更新同时保留历史调动的档案记录。离职管理离职员工不直接删除数据而是打一个离职标记同时将账号状态改为禁用防止离职员工继续登录系统。这一块的难点在于状态流转一个员工在不同阶段有不同的状态试用期/正式/离职同时每一次状态变化都要有操作记录和时间戳方便追溯。2.3 保险行业特色模块代理人管理、业绩与佣金这是这个题目区别于普通人事系统的灵魂也是你答辩时的差异化亮点。代理人和内勤员工最大的不同在于代理人没有底薪或只有很少的底薪收入主要来自保单佣金。所以系统要做的是代理人入司管理录入代理人的入司时间、所属营销部门、推荐人增员人、职级如业务员、主任、经理等。保单业绩录入代理人每促成一张保单就要往业绩表里录一条数据。字段包括保单号、投保人、险种名称、保费金额、佣金比例、签单日期等。佣金自动计算根据保费的到账比例和佣金比例自动算出代理人该拿到的佣金并且支持按月度汇总。职级考核保险公司对代理人是有考核机制的比如季度业绩达到 20 万晋升主任连续两个季度不达标降级。系统里可以维护考核周期和业绩目标页面上一张图表展示每个代理人的业绩完成率。这个模块做完之后你这个系统的行业属性就立住了。评委会看到你不止会写 CRUD还能把业务规则落进系统里这比多写一个没用的模块要加分得多。2.4 辅助模块考勤、薪资、招聘、培训、绩效前几年我指导的项目里学生最常犯的一个错误就是把系统功能树画得特别大每个模块都做得很浅。功能列表洋洋洒洒十几项点进去全是只有一张空表格连增删改查都不完整。这种项目给老师的观感非常差因为它暴露了没做完的事实。所以我的建议是核心模块做深辅助模块做通。员工档案、代理人管理、佣金结算、权限控制这四个核心模块要做得非常细致考勤、薪资、招聘、培训、绩效这五个辅助模块可以做得简单一些但要保证功能链是完整可用的考勤管理人工补录打卡记录或者支持简单的迟到早退登记考勤数据作为薪资计算的输入之一。薪资管理月底由人事专员汇总生成薪资单薪资 基本工资 岗位工资 绩效奖金 佣金 − 五险一金 − 个税可简化为固定比例。薪资数据一旦确认归档就不可修改只能生成更正单。招聘管理维护职位需求、发布招聘信息、管理应聘者简历记录面试结果面试通过后一键转为员工草稿档案。培训管理维护培训计划记录培训参与人员和成绩。绩效管理定期录入员工绩效评分评分结果联动到薪资模块的绩效奖金部分。从论文篇幅的角度来说这些模块只需要每个模块写上一两页核心表结构和业务流程就能凑出一个非常充实的功能设计章节。2.5 非功能需求与数据安全考虑除了业务流程还有几个非功能需求是你在写文档的时候必须提到的系统需要有操作日志功能记录谁在什么时间操作了哪条数据需要支持 Excel 导入导出用于批量导入员工花名册和导出工资条所有接口的返回格式需要统一封装前端根据返回码统一处理异常敏感操作比如删除审批记录、修改佣金比例需要二次确认。这些听起来很小的需求恰恰是区分作业和系统的关键。3. 技术选型复盘SpringBoot Vue 这个组合赢在哪里3.1 后端SpringBoot 2.x MyBatis Plus省心且高效后端框架方面SpringBoot MyBatis Plus是当前中小型管理系统开发里最省心的组合没有之一。SpringBoot 的好处不用多说内嵌 Tomcat 免去外部容器配置自动配置机制让数据源、MyBatis、Redis 这些组件的集成几乎只需要一个依赖一个注解就能完成。对于毕设这种开发周期有限的项目SpringBoot 能把大量时间从配置地狱里解放出来让你专心写业务代码。MyBatis Plus 则是更进一步的生产力工具。它内置了通用 Mapper你不需要手写单表的增删改查 SQL只需要让自己的 Mapper 接口继承BaseMapperT就能直接调用selectList()、selectPage()、updateById()等方法它还内置了分页插件前端传一个页码和一个每页条数后端就能直接返回分页数据和总条数它的条件构造器QueryWrapper/LambdaQueryWrapper能让多条件组合查询写得非常优雅。有些同学可能还在纠结用 Spring Data JPA 还是 MyBatis在这里我不做太多争论直接给出我的结论毕设项目一律推荐 MyBatis Plus。JPA 的自动建表和 HQL 查询对新手来说太抽象出问题的时候难以排查MyBatis 写起来虽然直观但手写 SQL 的工作量在 20 张表的规模下确实偏大。MyBatis Plus 相当于在两者之间做了一个平衡而且它的代码生成器MyBatis Plus Generator可以直接根据数据库表结构生成实体类、Mapper 接口、Service 层基础代码这能帮你省下整整一个下午的时间去写那些毫无技术含量的重复代码。3.2 前端Vue 2/3 Element UI后台开发最成熟的组合前端选型上虽然 Vue 3 已经是主流但考虑到你在网上找的很多实例代码和视频教程仍然基于 Vue 2我建议你结合自己的熟悉程度选择。如果是从零开始学我更推荐直接上Vue 3 Element Plus Vite因为这是目前前端社区的方向而且 Vite 的开发体验确实比 Webpack 快很多。但如果你已经看过一些基于 Vue 2 Element UI 的教程那继续用 Vue 2 也完全没问题功能上没有任何缺陷。之所以选择 Vue 而不是 JSP/Thymeleaf 模板渲染核心原因只有一句话前后端分离是当前主流开发模式而且用 Android 或纯后端的同学也能快速上手 Vue 的基础语法。Vue 的双向绑定特性让你不需要像操作 jQuery 那样频繁操作 DOM数据变了页面自动更新Element UI/Plus 组件库则把表格、表单、弹窗、分页器、日期选择器、上传组件这些后台管理系统的高频组件全部做好了你只需要照着文档传参数就行。一个后端出身的同学花三天时间看完 Vue 的基础语法和组件用法就足以完成一个管理系统前端的所有页面。Vue 生态里还有一个很关键的东西——Vue Router 和 Vuex/Pinia 状态管理。你需要在路由配置里加入路由守卫拦截未登录用户需要根据登录用户的角色动态生成可访问的菜单需要在 axios 请求封装里统一处理 Token 过期、错误提示这些逻辑。这些都属于前端工程化的基本功写进简历里也是实打实的技能点。3.3 权限方案JWT 拦截器还是 Shiro/Spring Security权限设计是人事管理系统里绕不开的一个模块也是答辩老师很爱问的一个点。目前主流方案有三套我分别说一下适用场景方案优点缺点毕设推荐度JWT 自定义拦截器简单直观代码可控理解全面无状态 Token 吊销麻烦需要自己写刷新逻辑强烈推荐Spring Security JWT功能全面业界标准学习曲线陡峭配置复杂新手容易懵时间充裕可选Apache Shiro JWT轻量、易上手生态不如 Security社区活跃度下降不推荐对我来说JWT 自定义拦截器是毕设项目里最合适的方案。你只需要在登录接口里用 JWT 工具类生成 Token在 Spring 的拦截器里校验 Token 的合法性和过期时间把从 Token 里解析出的用户 ID 放到 ThreadLocal 或请求参数里往下传就行了。整个流程不超过 200 行代码但你能把无状态认证的概念讲得清清楚楚这比拿一个安全框架帮你把细节全部封装掉更容易在答辩时展示思考深度。后端做完接口权限控制之后前端还需要做按钮级控制不同角色看到的操作按钮不一样。这一步可以在路由守卫和自定义指令v-permission里实现根据后端返回的权限列表判断当前用户是否拥有该按钮的操作权限。3.4 前后端分离项目的目录结构规划最后一个在搭建工程时容易让新手纠结的问题项目目录怎么组织我的建议是建一个父工程下面拆两个子模块hr-server后端和hr-web前端。如果用的是 Maven父工程只要一个pom.xml聚合即可后端模块是标准的 SpringBoot 分包结构controller / service / mapper / entity / dto / config / common / utils前端模块就是标准 Vue 工程结构src/api / src/router / src/store / src/views / src/components / src/utils。后端分包的逻辑是按技术层次分包还是按业务模块分包我的经验是小型项目按层次分包中型项目按模块分包。你已经有 10 多个业务模块的前提下如果所有 Controller 都堆在同一个controller包里文件数量一多就很混乱。建议按业务模块分包例如hr-system、hr-attendance、hr-salary、hr-agent每个模块内部再分出 controller/service/mapper/entity这样后期扩展一个模块的时候只需要新建一个包不会干扰现有代码。4. 数据层设计核心表结构是怎么一步步拆出来的4.1 从业务模块倒推表清单做数据库设计时我习惯用的方法是从业务对象倒推而不是凭空去列表。每个模块里只要有独立业务意义的名词就是一张表。按照这个方法我们这个系统的核心表可以拆出以下 15 张左右模块表名关键字段系统管理sys_user用户名、密码、真实姓名、手机号、部门ID、岗位ID、状态、最后登录时间系统管理sys_role角色名称、角色编码、状态系统管理sys_menu菜单名称、父ID、路由地址、权限标识系统管理sys_user_role用户ID、角色ID系统管理sys_role_menu角色ID、菜单ID组织架构sys_dept部门名称、父ID、负责人、排序组织架构sys_post岗位名称、岗位编码、所属部门ID员工管理emp_employee工号、姓名、性别、身份证、手机号、部门ID、岗位ID、用工类型、状态、入职时间员工管理emp_employee_change员工ID、变更类型调动/转正/离职、变更前值、变更后值、操作人、操作时间考勤管理att_attendance员工ID、日期、上班打卡时间、下班打卡时间、状态正常/迟到/早退/缺勤薪资管理sal_salary员工ID、薪资月份、基本工资、岗位工资、绩效奖金、佣金、五险一金、个税、实发工资、状态招聘管理rec_resume姓名、电话、应聘岗位、学历、工作经验、面试状态、面试评价培训管理tra_train_plan培训主题、开始时间、结束时间、讲师、地点绩效管理per_performance员工ID、考核周期、评分、评价人、备注代理人模块ins_agent代理人工号、姓名、身份证、入司时间、职级、所属营销部门、增员人代理人模块ins_policy保单号、代理人ID、投保人、险种、保费金额、佣金比例、签单日期、回执状态代理人模块ins_commission代理人ID、结算月份、业绩总额、佣金总额、结算状态日志模块sys_log操作人、操作模块、操作类型、方法名、请求参数、IP、操作时间你可能会问为什么emp_employee和ins_agent是两张表而不是一张员工表加一个是否代理人字段这里其实是整个数据库设计里一个很值得聊的点。4.2 员工与代理人拆不拆两张表我的方案是主表冗余 从表补全这是数据库设计阶段一个绕不开的决策。方案的 A 是一张员工表加一个employee_type字段区分正式员工与代理人方案 B 是正式员工和代理人各自一张表。我最推荐的是A B 的中间方案保留一张emp_employee主表作为所有人员的底表里面只放公共字段姓名、手机号、部门、用工类型、状态同时建一张ins_agent从表专门存代理人的特有字段入司时间、职级、增员人、考核业绩目标。用工类型为代理人的员工在ins_agent表里有一条对应记录。这样做的理由有三个。第一登录和基础权限体系是统一的——无论内勤还是代理人都需要账号登录都在同一张用户主表对应第二代理人的行业专属字段不会污染通用员工表的字段设计后续如果你去掉保险行业特性来做一套通用人事系统只需要去掉ins_agent表和关联逻辑即可第三佣金结算和业绩统计都基于ins_agent表操作不会出现把内勤也拉进佣金计算这种低级 bug。这种公共主表 垂直拆分从表的模式在很多真实企业系统里都很常见答到数据库设计优化的时候你可以把这个决策当成一个论据来用。4.3 薪资表里为什么必须放快照而不是实时关联薪资表sal_salary的设计有一个很多新手容易忽略的点薪资记录在生成之后必须固定下来不能跟着关联表数据实时变化。举个例子张三 2024 年 3 月的薪资单里基本工资是 8000绩效奖金是 1500。到了 4 月份他的岗位工资调整到了 8500。如果你在薪资表里只存员工 ID发工资时再去员工表实时查询基本工资那么 3 月份的薪资单显示的基本工资就会变成 8500——这明显是错的历史薪资单必须反映当时发放时的数据。所以薪资表的设计一定要做数据快照生成薪资单时把基本工资、岗位工资、绩效奖金、五险一金、个税这些计算因子全部冗余存储到薪资记录里而不是只存一个员工 ID。佣金结算表ins_commission同理保单佣金比例要以签单时刻的规则为准哪怕后续总公司调整了提成比例历史佣金结算记录也不能变。这个设计思路理解透了之后你会发现自己数据库设计水平已经超过 80% 的同期同学了——很多人写毕设做到薪资模块功能是能跑但一问到历史数据追溯就答不上来而你完全可以用一套快照机制来讲清楚。4.4 公共字段与逻辑删除这是每个表都要做的事我在前面列表的时候没有展开每个表的公共字段这里单独强调一下。几乎所有业务表都应包含这五个字段create_time创建时间update_time更新时间create_by创建人update_by更新人deleted逻辑删除标记0 未删除 / 1 已删除create_time和update_time可以在 MySQL 里设置DEFAULT CURRENT_TIMESTAMP和ON UPDATE CURRENT_TIMESTAMP自动维护deleted字段则是配合 MyBatis Plus 的TableLogic注解实现逻辑删除这样执行deleteById时实际执行的是UPDATE ... SET deleted 1数据并没有真正消失离职员工的记录依然可以追溯。create_by和update_by怎么填这就用到了我在 3.3 节提到的登录用户 ID。在 Web 请求拦截器里把当前登录用户解析出来存入一个UserContext线程变量然后在 MyBatis 的 MetaObjectHandler 里自动填充创建人和更新人。这个属于 MyBatis Plus 的自动填充功能配置一次之后所有新增和修改操作都会自动带出操作人很省心。5. 关键模块的实现思路与代码骨架5.1 后端通用 CRUD 的标准写法MyBatis Plus 的 CRUD 写起来确实舒服。我以一个员工管理模块的列表查询为例展示一下标准写法。首先定义实体类省略大部分字段Data TableName(emp_employee) public class Employee { TableId(type IdType.ASSIGN_ID) private Long id; private String empNo; private String name; private String idCard; private String phone; private Long deptId; private Long postId; private Integer employeeType; private Integer status; TableLogic private Integer deleted; TableField(fill FieldFill.INSERT) private LocalDateTime createTime; TableField(fill FieldFill.INSERT_UPDATE) private LocalDateTime updateTime; }Controller 里的列表查询接口我用 MyBatis Plus 的分页插件PostMapping(/list) public ResultIPageEmployeeVO list(RequestBody EmployeeQuery query) { PageEmployee page new Page(query.getPageNum(), query.getPageSize()); LambdaQueryWrapperEmployee wrapper new LambdaQueryWrapper(); wrapper.eq(StringUtils.hasText(query.getName()), Employee::getName, query.getName()) .eq(query.getDeptId() ! null, Employee::getDeptId, query.getDeptId()) .eq(query.getStatus() ! null, Employee::getStatus, query.getStatus()) .orderByDesc(Employee::getCreateTime); IPageEmployee employeePage employeeService.page(page, wrapper); // 将实体转为 VO补充部门名称、岗位名称等冗余显示字段 return Result.ok(convertToVO(employeePage)); }这里的重点是「条件构造器」的写法LambdaQueryWrapper的第一个参数是一个布尔表达式为 true 时这个条件才生效这样拼接动态查询条件的时候就不需要手写一堆if分支拼 SQL代码干净很多。而返回的EmployeeVO是专门给前端看的视图对象里面除了员工基础字段还有部门名称、岗位名称这些冗余字段避免前端拿到一个deptId之后还得再发一次请求去查部门表。5.2 前端列表页与表单页的标准骨架前端我用 Vue 3 Element Plus 写一个典型列表页这基本就是后台管理系统前端的通用骨架template div classapp-container el-form :modelqueryParams inline el-form-item label员工姓名 el-input v-modelqueryParams.name placeholder请输入姓名 clearable / /el-form-item el-form-item label所属部门 el-tree-select v-modelqueryParams.deptId :datadeptOptions / /el-form-item el-form-item el-button typeprimary clickhandleQuery搜索/el-button el-button clickresetQuery重置/el-button /el-form-item /el-form el-table :datatableData border el-table-column propempNo label工号 width100 / el-table-column propname label姓名 width100 / el-table-column propdeptName label部门 width120 / el-table-column proppostName label岗位 width120 / el-table-column propstatus label状态 width80 template #default{ row } el-tag :typerow.status 1 ? success : info {{ row.status 1 ? 在职 : 离职 }} /el-tag /template /el-table-column el-table-column label操作 width220 template #default{ row } el-button link typeprimary clickhandleUpdate(row)编辑/el-button el-button link typedanger clickhandleDelete(row)删除/el-button /template /el-table-column /el-table el-pagination v-model:current-pagequeryParams.pageNum v-model:page-sizequeryParams.pageSize :totaltotal changegetList / /div /template然后配合src/api/employee.js里的 axios 请求封装import request from /utils/request export function listEmployee(data) { return request({ url: /employee/list, method: post, data }) }整个前端开发的过程本质上就是复制这个骨架 → 换一下字段名 → 调整一下组件的循环。前端页面多不可怕可怕的是你没有把骨架抽出来每一页都从零开始写。5.3 前端路由权限与按钮权限怎么落地前端的权限控制分两层。第一层是菜单权限用户在登录接口返回的数据里带着一个可访问路由列表前端在动态添加路由时只添加用户拥有的路由。实现方式是在路由守卫里调用后端接口获取菜单树用router.addRoute()动态注册路由同时把菜单树渲染成侧边栏导航。第二层是按钮权限比如删除员工这个按钮只有系统管理员和人事主管能看到。我推荐封装一个 Vue 自定义指令// directive/permission.js export default { mounted(el, binding) { const requiredPerm binding.value const userPerms store.getters.permissions if (!userPerms.includes(requiredPerm)) { el.parentNode el.parentNode.removeChild(el) } } }页面里使用时el-button v-permissionemployee:delete typedanger删除/el-button没有权限的用户渲染时这个按钮会被直接移除。注意这里是前端层面的权限控制后端接口依然要校验权限前端控制更多是体验优化真正的安全边界在后端。5.4 多表联查与复杂统计怎么实现人事系统里最复杂的一个查询大概是员工列表 部门名称 岗位名称 最近一个月考勤统计。这种页面如果全部用 LambdaQueryWrapper 来连表写起来其实挺别扭因为 MyBatis Plus 的 Wrapper 本质上只擅长单表查询。我的做法是复杂查询用自定义 SQL。在 Mapper 接口里写一个方法用Select注解或 XML 文件写多表联查 SQL返回一个自定义 VO 类型。select idselectEmployeeWithAttendance resultTypecom.hr.system.vo.EmployeeAttVO SELECT e.id, e.emp_no, e.name, d.dept_name, p.post_name, COUNT(a.id) AS attendance_days FROM emp_employee e LEFT JOIN sys_dept d ON e.dept_id d.id LEFT JOIN sys_post p ON e.post_id p.id LEFT JOIN att_attendance a ON a.employee_id e.id AND a.att_date BETWEEN #{beginDate} AND #{endDate} WHERE e.deleted 0 GROUP BY e.id, e.emp_no, e.name, d.dept_name, p.post_name /select这类复杂统计查询在薪资汇总、业绩报表里会大量出现所以建议你提前把 MyBatis 的 XML 映射文件这一套练熟。毕竟你在简历里有底气写熟练使用 MyBatis的前提是你真的能写出多表 join 的 SQL而不是只靠 Java 代码绕来绕去。6. 从搭建到部署本地跑通全流程的实操注意点6.1 环境准备清单开发之前先把环境确认一遍避免因为环境不一致浪费大量时间。我习惯给学生列一个表格让 ta 们逐项对照工具版本建议备注JDK1.8 或 11SpringBoot 2.x 兼容性最好Maven3.6配好阿里云镜像否则依赖下载能急死人MySQL5.7 或 8.0建库时统一 utf8mb4 字符集Node.js14Vue2/ 16Vue3Vite版本太老会导致依赖安装失败IDEIDEA VSCode后端用 IDEA前端用 VSCode两个编辑器配合数据库管理Navicat / DataGrip执行 SQL 脚本和查看数据数据库脚本是整套系统能否跑起来的命根子。你要确保拿到手的 SQL 是完整且按顺序执行的——先建库再建表最后灌基础数据内置管理员账号、默认部门、默认菜单权限数据。6.2 启动过程中最常见的四个第一次运行报错根据我之前接触过的学生反馈第一次跑这种前后端分离项目九成会遇到下面四个问题问题一MySQL 连不上。报错信息基本是Access denied for user rootlocalhost或者Communications link failure。前者是密码不对或权限问题后者是配置的 IP 端口不对或者 MySQL 服务没启动。排查路径先在数据库管理工具里试着用项目配置的账号密码连接一次如果管理工具能连上但项目连不上那就是配置文件的 URL 或密码写错了如果管理工具也连不上先检查 MySQL 服务状态。问题二端口被占用。SpringBoot 默认 8080 端口如果你机器上已经跑了其他服务启动会报Port 8080 was already in use。最简单的解决办法是在application.yml里改 server.port改成 8081 或自定义端口同时记得前端 axios 的 baseURL 要跟着改避免前端通了但请求全部 404的尴尬局面。问题三前端 npm install 报错。这类问题一半出在 Node 版本太旧或者太新一半出在没配置淘宝镜像或者镜像不稳定。建议先把 Node 切到和项目一致的版本看 package.json 里 engine 字段再执行npm config set registry https://registry.npmmirror.com然后重新npm install。如果仍然报错删掉 node_modules 和 package-lock.json 再装一次很多玄学问题这样都能解决。问题四跨域请求失败。浏览器控制台出现CORS policy: No Access-Control-Allow-Origin header。解决方案有三种任选其一后端加一个全局 CORS 配置类允许指定来源后端用网关/过滤器统一添加响应头前端在 Vue 的 devServer 里配置代理proxy把/api开头的请求转发到后端地址。对于本地联调我最推荐第三种——前后端分离项目用前端代理来解决跨域是最接近生产环境的做法。6.3 演示数据怎么构造才像真实系统很多同学项目做完了数据库里只有两条测试数据演示的时候表格空荡荡答辩效果大打折扣。演示效果是固定印象的第一来源所以你一定要花一两个小时把演示数据造得足够真实。具体来说部门树至少要有三层比如总公司 → 浙江分公司 → 杭州营销部员工数据至少要有 30~50 条姓名不要用张三、李四、王五这种测试味过浓的名字去网上找一个百家姓随机生成工具生成一批像陈立诚、周雅雯这种真实感强的名字考勤数据至少覆盖最近一个月的日期薪资数据保证最近三个月都有记录代理人业绩表要有最近半年的保单数据并且有高有低有完成率差异操作日志要有几十条真实操作记录。这样准备之后的演示效果和只有测试数据的空壳之间隔着二十个身位的距离。7. 源码、文档与调试定制服务的正确用法7.1 拿到源码之后的第一步不是改代码而是建立闭环现在网上很多资源打包出售的项目标题写着附源码文档调试定制服务。如果你买了这样一套东西我给你的第一个建议非常反直觉先不要急着在别人的代码上大改特改而是先把系统完整地跑起来把前端页面—后端接口—数据库数据这个闭环建立起来。具体来说你要做四件事按 readme 文档初始化数据库导入 SQL 脚本启动后端服务用 Swagger 或直接看后端日志确认接口能正常响应启动前端项目用内置管理员账号登录把系统所有页面走一遍记录你看到的每个菜单、每个功能在这个过程中把工程结构、核心表关系、关键接口都标注出来画一张自己的脑图。这四步做完你才算真正认识了这个系统。很多同学拿到源码就开始闷头改样式、换 Logo、改标题结果是页面长得是自己的但一问到业务逻辑还是一问三不知这种改造在答辩时是最容易翻车的——因为老师一眼就能看出代码风格和你实际水平不匹配。7.2 怎么把别人的系统改出你自己的特色如果你要在此基础上做出自己的差异化我的建议是优先做以下三个方向的改造性价比最高第一增加一个原系统没有的业务模块。比如原系统如果只有基础的入转调离和考勤那你可以加一个培训管理模块或者绩效管理模块。因为新增模块意味着你要自己设计表结构、写接口、做页面这部分的代码是你真正亲手写的答辩时你可以非常自信地讲这个模块是从表结构设计到前后端实现独立完成的。第二深化一个核心业务逻辑。比如原系统的佣金计算可能是很粗糙的保费 × 固定比例那你可以把它升级成不同险种不同佣金比例 阶梯式业绩提成 回执确认后佣金生效这套保险公司更真实的规则。这种业务规则的深化非常能体现你对行业的理解。第三完善非功能设计。比如给系统加上统一的异常处理、操作日志切面、Excel 导出功能、数据脱敏展示、登录验证码。这些内容单看每个都不复杂但它们是最能体现工程素养的部分也是很多课程设计、毕业设计普遍欠缺的。不要试图把所有 20 张表全部推倒重来那不叫改造那叫重写。你要做的是在一个完整可运行的系统上找到三四个你自己能讲得最透彻的点往深了挖这就足够了。7.3 论文、PPT、演示视频这些文档素材怎么准备附文档这个信息里包含的东西差别很大高质量的文档素材通常包括开题报告、任务书、中期检查表、毕业论文完整稿、答辩 PPT、演示视频。这些素材的价值在于它们是格式和结构的参考而不是让你直接提交的东西。我的建议是拿到论文文档之后先通读一遍重点关注它的章节安排和每章篇幅。然后把其中所有和实际代码不符的细节列出来比如表结构变了、功能名称变了、业务流程改了逐一修正之后再作为你自己的论文初稿。千万不要原样提交现在高校对论文查重和代码查重都非常严照搬别人成品文档的后果可能会很严重。正确做法是参考结构和写作思路内容用自己的语言重写配上你自己对系统的真实理解。整篇论文里最核心的系统设计和系统实现两个章节你要做到合上文档也能自己完整地讲出来。答辩 PPT 也是同样的道理建议控制在 12~15 页背景与意义 2 页技术选型 2 页需求分析 3 页系统设计 4~5 页实现展示 3 页总结与展望 1 页。演示视频控制在 5~8 分钟把登录、员工管理、佣金结算、考勤统计这几个核心界面走一遍即可不需要把每个页面都录进去。7.4 调试定制服务到底帮了什么忙最后说说调试定制服务这类服务本身。如果你是第一次独立开发前后端分离项目半年时间都不一定够用因为你会遇到的第一个问题可能就卡住一整天——比如 MySQL 8 的加密方式导致驱动连接失败比如 npm 依赖版本冲突比如前端请求到了后端但返回的数据结构和约定好的不一样。这些坑每一代新手都会踩而调试服务本质上是把这个踩坑时间大幅度压缩了。但我要提醒一句调试服务的正确使用方式是你先把问题定位到一定程度再让远程的人帮你确认和解决而不是直接甩一句运行不了让对方全权处理。你在等待远程协助的过程中至少要自己把报错日志、控制台信息、已经尝试过的步骤整理清楚。让服务方远程帮你敲一条命令、改一行配置很简单但你要从每一次解决问题的过程里学会这套项目的排错方法论。毕竟老师答辩时可不会让你分享远程服务商是怎么帮你把项目跑起来的——ta 问的是这条接口路径为什么这样设计你要能回答得上来。8. 写在最后的几句实在话关于这个题目想聊的内容基本都聊完了。我自己的感受是SpringBoot Vue 这套组合真的是毕设阶段性价比最高的选择——它不会让你在技术选型上翻车又足够你学到真正能用于工作的工程能力保险公司人力资源这个业务方向也不算冷门资料相对好找带行业属性的设计又能让论文和答辩都显得有深度。如果让我给一个更具体的建议做项目的过程中多写注释、多记心得、多截图这些都会成为你论文和 PPT 里最真实的素材。遇到报错千万不要慌用搜索引擎搜完整的报错信息、看异常堆栈的前三行八成的问题都能自己解决——这个过程本身就是做毕设最有价值的收获。祝你项目顺利答辩通过。