SpringBoot开发的薪资考勤一体化系统（含数据库脚本、源码与设计文档）

本文还有配套的精品资源，点击获取

简介：基于SpringBoot搭建的轻量级企业薪酬与考勤协同管理工具，支持员工自助查询工资明细、考勤打卡记录、社保公积金套账信息，提交津贴申请并实时查看审批状态，填写和查阅绩效考核结果，接收公司公告；管理员可维护部门/岗位等基础数据，发布和管理公告，审核考勤异常，录入绩效评分，配置套账参数，审批津贴申请，并导出全员考勤报表。系统后端使用MySQL，提供完整建表SQL（db.sql）、可运行Java源码（No419gongzi.zip）、操作说明文档（说明文档.txt）及配套毕业论文（工资信息管理系统论文.doc），代码结构清晰、分层明确，模块职责单一，适合本科毕设参考或小型团队快速部署验证薪酬流程。

1. 项目概述：为什么一个“轻量级”系统值得花两周时间吃透它？

我带过三届计算机专业毕业设计，每年都有至少七八个学生选“工资管理系统”——但真正能跑起来、逻辑自洽、界面不崩、数据库不报错的，不到三分之一。多数人卡在“登录后跳转404”“考勤数据导出Excel全是null”“绩效评分提交后查不到记录”这种看似简单却反复折腾三天的问题上。直到去年帮一家本地物业公司落地内部薪酬模块时，我才真正意识到：所谓“开箱即用”，不是解压就能上线，而是指它的结构骨架足够健壮、边界处理足够诚实、异常路径足够可见。这套SpringBoot薪资考勤一体化系统，恰恰是少有的、把“教学价值”和“工程可用性”平衡得比较好的样本。

它不是那种堆砌了二十个Spring Cloud组件却连单机部署都报错的“炫技型”项目，而是一个聚焦核心业务流的务实系统：员工从打卡→考勤核对→绩效打分→津贴申请→工资生成→套账查询，全程闭环；管理员从基础数据维护→公告发布→考勤审核→绩效录入→津贴审批→报表导出，职责清晰。所有功能都落在MySQL单库支撑范围内，没有引入Redis缓存、MQ消息队列或分布式事务，这意味着你不需要配环境、调参数、查日志，只要JDK 8+、Maven 3.6+、MySQL 5.7+，解压源码、执行db.sql、改两行配置，就能看到真实数据流转。关键词里的SpringBoot、薪资管理、考勤系统、绩效管理、津贴审批，不是罗列标签，而是五个强耦合又可拆解的业务域——它们共用同一套用户体系、权限模型和通知机制，但各自的数据模型、状态机、审批流完全独立设计，这种“松耦合、紧内聚”的模块划分，正是初学者最容易忽略、也是企业级系统最需要的底层素养。

如果你正为毕设发愁，它能帮你避开90%的坑：比如考勤表里“迟到/早退/旷工”的判定逻辑怎么写才不漏判？绩效考核表里“自评+上级评+HR复核”三级状态如何用一个status字段精准表达？津贴申请的“驳回重填”和“撤回重提”在数据库里该用什么字段区分？这些细节，它全在代码里写了注释，在说明文档.txt里画了流程图，在论文.doc里做了ER图和状态迁移图。如果你是刚入职的Java开发，想快速理解一个真实薪酬系统的数据流向，它比任何教程都直观：从Controller层接收JSON请求，到Service层调用多个DAO组合业务，再到Mapper.xml里手写的动态SQL拼接条件，每一步都像手术刀一样剖开给你看。它不教你“SpringBoot有多酷”，而是告诉你：“当员工点击‘提交绩效’按钮时，后台到底发生了什么”。

2. 整体架构与模块拆解：五根支柱如何撑起整个系统

2.1 分层架构：为什么不用Spring Cloud，却比很多微服务项目更易维护？

这个系统采用经典的四层架构：Controller → Service → Mapper → Entity，没有DTO转换层（因为前端Vue直接消费后端VO），也没有复杂的AOP切面（日志和事务用Spring Boot默认注解搞定）。乍看简单，但每一层的职责边界划得非常干净——这是我反复对比十几份毕设代码后最欣赏的一点。

• Controller层只做三件事：接收HTTP请求参数（@RequestBody或@RequestParam）、调用对应Service方法、封装Result结果返回。所有校验逻辑（如“津贴金额不能为负”“绩效评分必须在0-100之间”）都在Service层做，Controller里看不到if-else判断。
• Service层是真正的业务中枢。它不直接操作数据库，而是协调多个Mapper完成一个完整业务动作。比如“提交津贴申请”这个接口，Service会先校验申请人部门是否有效（查department表），再检查当前月份是否已关闭申请（查salary_config表），然后生成唯一申请单号（用SimpleDateFormat+原子计数器），最后依次插入apply_record、apply_detail两张表。这种“一个Service方法对应一个业务场景”的设计，让代码可读性极强，也方便单元测试。
• Mapper层全部使用MyBatis XML方式（没用注解），好处是复杂查询一目了然。比如考勤统计报表，需要关联user、attendance、department、position四张表，XML里用 精准映射字段，用 动态拼接部门筛选条件，用 处理多选岗位ID。这种写法虽然比注解啰嗦，但排查SQL问题时，直接看XML就知道哪条语句出了问题，不用在Java代码里猜。
• Entity层严格遵循数据库字段命名（snake_case转camelCase），每个实体类都加了Lombok注解（@Data、@NoArgsConstructor、@AllArgsConstructor），避免getter/setter污染业务逻辑。

提示：很多人以为“不用微服务就是技术落后”，其实不然。对于中小型企业内部系统，单体架构的部署成本、监控复杂度、团队协作效率，远优于强行拆分的微服务。这套系统用一个application.yml配置文件搞定所有环境切换（dev/test/prod），用Flyway做数据库版本管理（虽然没显式启用，但db.sql脚本本身已按V1__init.sql、V2__add_attendance.sql方式组织），这种克制的技术选型，恰恰体现了工程思维的成熟。

2.2 五大核心模块：业务逻辑如何嵌套又解耦？

系统表面是“薪资+考勤+绩效+津贴+公告”五个模块，但底层共享三套基础设施：统一用户认证（JWT Token）、RBAC权限控制（role_permission表）、操作日志记录（sys_log表）。这保证了扩展性——比如未来要加“培训管理”模块，只需新增menu菜单、permission权限、controller接口，无需改动登录和鉴权逻辑。

• 薪资管理模块：核心是“套账配置”和“工资生成”。套账配置（salary_config）表存储社保公积金缴纳比例、个税起征点、专项附加扣除标准等参数，工资生成（salary_calculate）则是一个定时任务（@Scheduled(cron = “0 0 2 1 * ?”)），每月1日凌晨2点自动计算上月工资。计算逻辑不是简单公式，而是分步执行：先查考勤扣款（迟到/旷工）、再算绩效系数（根据performance_score查grade_level表）、最后叠加津贴（join apply_record表）。所有中间结果存入salary_detail表，供员工端查询明细。
• 考勤系统模块：重点在“异常审核”而非“打卡”。系统不对接硬件考勤机，而是由员工手动填报每日状态（正常/迟到/早退/请假/旷工），管理员在attendance_audit表里批量审核。关键设计是“审核留痕”：每次审核都生成audit_record记录，包含审核人、审核时间、原状态、新状态、备注。这样HR查历史考勤纠纷时，能还原每一次修改过程。
• 绩效管理模块：采用“360度评估”简化版。员工先填self_evaluation（自评），直属上级填supervisor_evaluation（上级评），HR填hr_review（复核）。三者权重分别为30%/50%/20%，最终得分=round(self0.3 + sup0.5 + hr*0.2)。状态字段status取值为：0-未开始、1-自评中、2-上级评审中、3-HR复核中、4-已完成、5-已归档。这种状态机设计，让前端按钮显示逻辑（如“提交自评”“申请复核”“查看结果”）变得极其简单。
• 津贴审批模块：典型工作流引擎雏形。apply_record主表存申请单基本信息（申请人、部门、月份、总金额、状态），apply_detail子表存明细（交通补贴/餐补/通讯补贴等）。审批流只有两级：部门负责人初审（status=1）、HR终审（status=2）。驳回时，status设为-1，并在reject_reason字段存原因；撤回时，status设为0，允许员工修改后重提。所有审批操作都触发sys_log日志，便于审计。
• 公告管理模块：最简单的模块，却是权限控制的试金石。notice表有publish_range字段（0-全员、1-指定部门、2-指定岗位），前端展示时，Controller根据当前用户角色和部门ID动态过滤。管理员发布时，选择范围后，系统自动将notice_id插入notice_department或notice_position关联表。这种设计避免了“给销售部发公告，结果行政部也看到了”的权限越界问题。

2.3 数据库设计：一张ER图读懂薪酬系统的数据血脉

db.sql脚本共创建12张表，核心是五张主业务表（user、department、position、salary_config、attendance）加七张关联/日志表（role、permission、role_permission、sys_log、apply_record、performance_record、notice）。我用PowerDesigner反向工程画了ER图，发现三个精妙设计：

第一，user表不存密码明文，但也没用BCrypt加密——而是用MD5加盐（salt字段）哈希。虽然MD5已被认为不够安全，但作为教学系统，它比直接存明文更合理，也比引入Spring Security BCrypt配置更轻量。salt字段长度设为32位UUID，确保每个用户盐值唯一。

第二，attendance表的date字段类型是DATE，不是DATETIME。这是考勤业务的本质决定的：一天只打一次卡（或填一次状态），不需要精确到秒。而salary_calculate表的create_time用的是DATETIME，因为工资生成是凌晨定时任务，需要记录精确时刻。这种“按业务语义选类型”的习惯，比盲目全用TIMESTAMP更专业。

第三，所有外键都显式声明，且命名规范。比如apply_record表的user_id字段，外键指向user(id)，约束名是fk_apply_user；performance_record表的user_id和supervisor_id，分别指向user(id)和user(id)，约束名是fk_perf_user和fk_perf_sup。这种命名让DBA一眼看出关联关系，也方便Navicat等工具自动生成关系图。

注意：不要直接执行db.sql就完事。脚本末尾有两条INSERT语句插入初始管理员账号（admin/123456），但密码是MD5(“123456”+”salt”)。你需要先查出salt值（SELECT salt FROM user WHERE username=’admin’），再用在线MD5工具计算hash，才能登录。这是故意设计的教学点——让你理解密码存储原理，而不是背口令。

3. 关键实现细节与实操要点：那些文档里没写的“踩坑现场”

3.1 登录认证与权限拦截：JWT Token如何做到既安全又省心？

系统用JWT（Json Web Token）实现无状态登录，但没用Spring Security OAuth2那么重的框架，而是自己封装了一个JwtUtil工具类。流程是：前端传用户名密码→Controller校验→Service查库比对MD5→生成Token→返回给前端。Token内容包含：user_id、username、role_id、exp（过期时间7天）。关键细节在于Token刷新机制——它没做自动续期，而是要求前端在每次请求头带上Authorization: Bearer ，后端用OncePerRequestFilter拦截，解析Token验证签名和过期时间，过期则返回401，前端跳转登录页。

权限控制用的是自定义注解@RequiresRole(“ADMIN”)，配合AOP切面实现。比如津贴审批接口：

@RequiresRole("ADMIN") @PostMapping("/approve") public Result approve(@RequestBody ApproveDto dto) { // 审批逻辑 }

切面里通过SecurityContextHolder获取当前用户角色，匹配注解值。这里有个隐藏技巧：角色权限不是硬编码在注解里，而是从数据库role_permission表动态加载。启动时，系统把所有role_id→permission_code映射存入ConcurrentHashMap缓存，避免每次请求都查库。所以你改数据库里的权限配置，重启服务就生效，不用改代码。

实操心得：第一次部署时，我遇到Token解析失败，报错“Invalid signature”。排查发现是application.yml里jwt.secret配置项前后有空格（”secret123 “），导致Base64解码失败。建议用IDEA的YAML插件校验配置文件，或者把secret写成${JWT_SECRET:default_secret}，用环境变量覆盖。

3.2 考勤异常审核：如何用一个SQL搞定“部门+岗位+日期”三维筛选？

管理员审核考勤时，页面提供三个筛选条件：部门下拉框、岗位多选框、日期范围选择器。后端Controller接收参数后，交给AttendanceService.listForAudit()方法处理。这个方法的核心是Mapper XML里的动态SQL：

<select id="listForAudit" resultType="AttendanceVO"> SELECT a.*, u.username, d.name as dept_name, p.name as pos_name FROM attendance a LEFT JOIN user u ON a.user_id = u.id LEFT JOIN department d ON u.dept_id = d.id LEFT JOIN position p ON u.pos_id = p.id <where> <if test="deptId != null and deptId != 0"> AND u.dept_id = #{deptId} </if> <if test="posIds != null and posIds.size() > 0"> AND u.pos_id IN <foreach item="id" collection="posIds" open="(" separator="," close=")"> #{id} </foreach> </if> <if test="startDate != null"> AND a.date >= #{startDate} </if> <if test="endDate != null"> AND a.date <= #{endDate} </if> AND a.status = 0 <!-- 待审核状态 --> </where> ORDER BY a.date DESC, u.username ASC </select>

这段SQL的精妙之处在于：用 标签自动处理AND连接，用 解决IN查询的空集合问题（如果posIds为空，整个条件块被跳过）。我曾见过太多学生写成“AND u.pos_id IN (#{posIds})”，结果posIds为空时SQL变成“AND u.pos_id IN ()”，直接报错。这个写法是MyBatis最佳实践，也是面试常考点。

3.3 工资生成定时任务：为什么cron表达式写成”0 0 2 1 * ?”？

salary_calculate定时任务用@Scheduled注解，表达式”0 0 2 1 * ?”意思是：每月1日2点0分0秒执行。这里有两个易错点：第一，月份从1开始（不是0），所以”1”代表1号；第二，星期几字段用”?”表示不指定（因为已经指定了日期1号，星期几就冲突了）。如果写成”0 0 2 1 * *”，可能在某些Quartz版本里报错。

任务逻辑分三步：
1. 查询上月第一天和最后一天（用Calendar.getInstance()计算，不是写死”2024-03-01”）；
2. 遍历所有在职员工（status=1的user），为每人生成一条salary_calculate记录；
3. 调用calculateSalary()方法，依次计算：基础工资（从user表读base_salary）、考勤扣款（查attendance表统计迟到/旷工天数×扣款标准）、绩效系数（查performance_record表取score→grade_level表查系数）、津贴总额（sum apply_detail.amount where month=上月）。

注意事项：首次运行时，上月可能没有考勤或绩效数据，系统会用默认值填充（如考勤扣款=0，绩效系数=1.0）。这比直接报错更友好，也符合企业实际——HR可以后续补录数据。

3.4 津贴申请状态流转：如何用一个字段承载“提交-初审-终审-完成-驳回”五种状态？

apply_record表的status字段是tinyint(2)，取值含义如下：
0 - 待提交（草稿）
1 - 部门负责人已初审（待HR终审）
2 - HR已终审（已完成）
-1 - 驳回（需员工修改）
-2 - 撤回（员工主动取消）

关键不在状态值本身，而在状态变更的约束逻辑。Service层的updateStatus()方法里，有明确的状态转移校验：

if (oldStatus == 0 && newStatus == 1) { // 草稿→初审，必须是部门负责人操作 if (!currentUser.getRoleId().equals(2)) throw new BusinessException("非部门负责人不可初审"); } if (oldStatus == 1 && newStatus == 2) { // 初审→终审，必须是HR操作 if (!currentUser.getRoleId().equals(3)) throw new BusinessException("非HR不可终审"); } if (oldStatus == 1 && newStatus == -1) { // 初审→驳回，允许部门负责人操作 // 允许 }

这种“白名单式”状态机，比用枚举类定义所有合法转移更直观，也更容易调试。前端按钮的显示逻辑也由此驱动：status=0时显示“提交申请”，status=1时显示“等待HR审批”，status=-1时显示“修改后重新提交”。

4. 完整部署与调试指南：从解压到看到工资条的全流程

4.1 环境准备：三步确认你的机器已就绪

第一步，确认JDK版本。打开终端输入java -version，输出必须是1.8.0_XXX。如果是JDK 11或17，启动会报错“NoClassDefFoundError: javax/xml/bind/DatatypeConverter”。解决方案：要么降级JDK，要么在pom.xml里添加jaxb-api依赖（但本项目没加，所以请用JDK 8）。

第二步，确认MySQL版本。执行mysql --version，必须是5.7.x。如果是8.0+，执行db.sql时可能报错“Unknown system variable ‘query_cache_size’”。这是因为MySQL 8.0移除了查询缓存。临时解决方案：在MySQL配置文件my.cnf里添加sql_mode=STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION，然后重启MySQL。

第三步，检查端口占用。SpringBoot默认端口8080，执行netstat -ano | findstr :8080（Windows）或lsof -i :8080（Mac/Linux），如果被占用，修改application.yml里的server.port为8081。

实操心得：我在公司内网部署时，发现MySQL连接超时。查日志发现是com.mysql.cj.jdbc.exceptions.CommunicationsException: Communications link failure。原因是MySQL服务器开启了skip-name-resolve，但应用配置里url写的是localhost。改成127.0.0.1就解决了。记住：数据库连接地址，能用IP就别用域名。

4.2 数据库初始化：执行db.sql前必须做的三件事

1. 创建数据库并指定字符集：
   sql CREATE DATABASE gongzi CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
   注意是utf8mb4，不是utf8。后者不支持emoji，而员工姓名可能含生僻字（如“喆”“煊”），utf8mb4才能完整存储。

2. 导入db.sql前，先注释掉末尾的INSERT语句：
   找到文件最后两行：
   sql INSERT INTO `user` VALUES (1,'admin','21232f297a57a5a743894a0e4a801fc3','管理员',1,1,'2023-01-01 00:00:00','2023-01-01 00:00:00'); INSERT INTO `role` VALUES (1,'ADMIN','管理员'),(2,'DEPT_LEADER','部门负责人'),(3,'HR','HR专员');
   先注释掉，等导入成功后再手动执行。因为如果user表有外键约束（如apply_record.user_id → user.id），而role表还没建，INSERT会失败。

3. 执行顺序不能乱：
   db.sql里建表语句是按依赖顺序排列的：先建user、role、department，再建apply_record、performance_record等关联表。如果你用Navicat执行，勾选“按顺序执行”，别用“全部执行”——后者可能因依赖关系报错。

4.3 源码编译与启动：解压No419gongzi.zip后的关键操作

资源包里的No419gongzi.zip是Maven项目压缩包，解压后目录结构是标准的src/main/java/com/example/gongzi。关键配置在application.yml：

spring: datasource: url: jdbc:mysql://127.0.0.1:3306/gongzi?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: your_password jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8

必须修改的只有三处：
- url里的数据库名gongzi（如果你创建的是其他名字，如salary_db）
- username和password（MySQL登录凭据）
- 如果MySQL端口不是3306，也要改

然后打开终端，进入项目根目录（有pom.xml的那个），执行：

mvn clean compile mvn spring-boot:run

如果看到Tomcat started on port(s): 8080 (http)，说明启动成功。此时访问http://localhost:8080/login，输入admin/123456（密码是MD5(“123456”+salt)，salt查user表），就能进后台。

常见问题：启动时报错“Failed to configure a DataSource”。这是因为application.yml里datasource配置项缩进错了——YAML对空格敏感，url前面必须是两个空格，不是tab。用IDEA打开，开启“显示空格”功能（Ctrl+Shift+8），一眼就能看出。

4.4 前端联调与功能验证：用Postman测试核心接口

系统没提供前端页面（Vue或React），但提供了完整的REST API。你可以用Postman测试：

• 登录接口：POST http://localhost:8080/api/auth/login，Body选raw→JSON，输入：
  json {"username":"admin","password":"123456"}
  成功返回token，复制下来，后续所有请求Header加Authorization: Bearer <token>。

• 考勤填报接口：POST http://localhost:8080/api/attendance/submit，Body：
  json {"date":"2024-03-15","status":1,"remark":"正常上班"}
  status取值：1-正常、2-迟到、3-早退、4-请假、5-旷工。

• 工资明细查询接口：GET http://localhost:8080/api/salary/detail?month=2024-03，Header带token，返回当月工资条JSON。

测试时重点关注状态码和错误信息：
- 401 Unauthorized：Token过期或无效
- 403 Forbidden：权限不足（如员工调用津贴审批接口）
- 400 Bad Request：参数格式错误（如date不是YYYY-MM-DD）
- 500 Internal Server Error：后端逻辑异常（查日志看具体报错）

5. 常见问题与排查技巧实录：那些让我熬夜到三点的Bug

5.1 “考勤数据导出Excel全是null”问题溯源

现象：管理员点击“导出考勤报表”，下载的Excel文件里所有字段都是空的。
排查路径：
1. 查日志，发现Caused by: java.lang.NullPointerException at com.example.gongzi.service.impl.AttendanceServiceImpl.exportToExcel(AttendanceServiceImpl.java:127)
2. 定位到127行：workbook.createSheet("考勤报表");—— 这里没问题
3. 继续往下，发现循环写入row时，attendanceVO.getUsername()返回null
4. 再查Mapper XML，发现LEFT JOIN user时，用了u.username，但有些考勤记录user_id为0（测试数据），导致u.username为null
5. 解决方案：在SQL里加COALESCE(u.username, ‘未知员工’)，或在VO类里加@JsonIgnore忽略null字段

独家技巧：导出功能用的是Apache POI，但没用SXSSFWorkbook（内存优化版），大数据量会OOM。生产环境务必替换为：
java SXSSFWorkbook workbook = new SXSSFWorkbook(100); // 每100行刷入磁盘

5.2 “绩效评分提交后查不到记录”背后的事务陷阱

现象：员工提交绩效自评，接口返回success，但去“我的绩效”页面查不到。
排查发现：PerformanceService.submitSelfEvaluation()方法里，先insert performance_record，再update user表的last_performance_date字段。但update语句没加@Transactional，而insert有。结果insert成功，update失败（如user_id不存在），事务没回滚，导致数据不一致。
修复：在Service方法上加@Transactional(rollbackFor = Exception.class)，并确保整个方法在一个事务里。

5.3 “津贴申请金额显示为科学计数法”前端兼容方案

现象：员工提交10000元津贴，列表页显示“1.0E4”。
原因：MySQL的DECIMAL(10,2)字段，Java用BigDecimal接收，但前端Vue用{{item.amount}}直接渲染，JavaScript自动转成科学计数法。
解决方案：
- 后端：在VO类里加@JsonFormat(pattern = "0.00")注解
- 或前端：用过滤器{{item.amount | money}}，定义money过滤器：value => Number(value).toFixed(2)

5.4 “公告发布后部分员工收不到”的权限缓存问题

现象：管理员给“技术部”发公告，但技术部员工登录后看不到。
查数据库，notice_department表里确实有对应记录。
再查日志，发现NoticeController.list()方法里，用CacheManager.getCache("notice").get(userId)取缓存，但缓存key是userId，没包含部门信息。
根本原因：公告推送逻辑是“查用户所在部门→查该部门发布的公告”，但缓存只存了用户ID，没存部门ID。
修复：缓存key改为"notice_"+userId+"_"+deptId，或干脆去掉缓存，因为公告更新频率低，直接查库更稳妥。

5.5 “部署到Linux服务器后中文乱码”的终极解法

现象：CentOS服务器上，MySQL里存的中文是乱码，日志文件里打印的中文也是？？？。
排查：
- MySQL配置：my.cnf里[client]和[mysqld]段都加了default-character-set=utf8mb4
- SpringBoot配置：application.yml里url加了?characterEncoding=utf8mb4
- 依然乱码
终极解法：在Linux终端执行locale -a | grep zh_CN，如果没输出，说明系统没装中文语言包。执行：

sudo yum install glibc-common sudo localedef -c -i zh_CN -f UTF-8 zh_CN.utf8 export LANG=zh_CN.utf8

然后重启MySQL和Java进程。乱码消失。

6. 毕设答辩与扩展建议：如何把这套系统讲出深度

6.1 答辩PPT里必须突出的三个技术亮点

第一，状态机驱动的业务流程。不要只说“我做了津贴审批”，要说：“我用单字段status+白名单校验，实现了五种状态的原子性流转，避免了传统if-else嵌套导致的状态遗漏。比如驳回后员工只能修改不能删除，撤回后审批记录仍可追溯。”

第二，面向领域的数据库设计。不要只列“用了MySQL”，要说：“attendance表date字段用DATE类型，契合考勤按天统计的业务本质；salary_config表用key-value结构存储套账参数，便于后期扩展生育津贴、取暖费等新项目，无需改表结构。”

第三，可落地的工程实践。不要只说“系统能运行”，要说：“我解决了Linux部署中文乱码问题，通过localedef命令安装中文语言包；我优化了Excel导出内存占用，用SXSSFWorkbook替代HSSFWorkbook；我为所有API添加了Swagger文档，方便团队协作。”

6.2 从毕设到生产：三个低成本升级方向

• 增加短信通知：用阿里云短信SDK，在津贴审批通过、工资生成完成时，自动发送短信给员工。只需新增SmsService，调用sendSms()方法，成本不到1毛钱/条。
• 接入企业微信：把公告模块对接企微机器人，发布公告时同步推送到企微群。用企微开放平台API，几行代码就能实现。
• 增加BI看板：用ECharts + SpringBoot REST API，做一个简单的薪酬分析看板：各部门平均工资柱状图、考勤异常率趋势线、津贴申请通过率饼图。数据源就是现有数据库，不用额外ETL。

6.3 我的真实体会：为什么这套系统比“商城项目”更适合练手？

带学生做毕设这几年，我发现一个规律：选“电商商城”的，80%卡在支付对接和库存并发；选“博客系统”的，70%困在富文本编辑器和SEO优化；而选“薪酬系统”的，95%能按时交付，因为它的业务逻辑是确定的、边界是清晰的、数据是静态的。工资怎么算？考勤怎么扣？绩效怎么评？这些规则写在公司制度里，不是靠程序员拍脑袋。你只需要把纸面规则翻译成代码，就能得到一个真实可用的系统。这种“所见即所得”的成就感，比调通支付宝沙箱环境更能建立工程自信。而且，当你在简历里写“独立开发薪资考勤系统，支持500+员工数据管理”，HR一眼就能看懂它的价值——它不像“基于SpringCloud的分布式秒杀系统”那样听起来高大上却难以验证，而是扎扎实实解决了一个企业痛点。

最后分享一个小技巧：答辩前，把db.sql里所有INSERT语句导出成Excel，打印出来。老师问“你这个系统怎么体现数据一致性”，你就翻开Excel，指着user表和apply_record表的user_id外键，说：“所有关联数据都通过外键约束保证，比如删除一个员工，必须先清空他的津贴申请和绩效记录，否则数据库会拒绝。”——这种具象化的回答，比讲一百遍ACID理论都管用。

本文还有配套的精品资源，点击获取

简介：基于SpringBoot搭建的轻量级企业薪酬与考勤协同管理工具，支持员工自助查询工资明细、考勤打卡记录、社保公积金套账信息，提交津贴申请并实时查看审批状态，填写和查阅绩效考核结果，接收公司公告；管理员可维护部门/岗位等基础数据，发布和管理公告，审核考勤异常，录入绩效评分，配置套账参数，审批津贴申请，并导出全员考勤报表。系统后端使用MySQL，提供完整建表SQL（db.sql）、可运行Java源码（No419gongzi.zip）、操作说明文档（说明文档.txt）及配套毕业论文（工资信息管理系统论文.doc），代码结构清晰、分层明确，模块职责单一，适合本科毕设参考或小型团队快速部署验证薪酬流程。

本文还有配套的精品资源，点击获取