企业官网建设流程全解析

简介：基于Java与MySQL的勤工助学管理系统设计与实现文档，适合高校计算机相关专业学生、毕业设计写作者以及需要了解SSM后台项目开发流程的初学者。内容聚焦当前高校勤工助学业务规模扩大、管理需求提升的实际场景，完整梳理了学生申请岗位、教师发布岗位、管理人员审核分配、数据统计与反馈等关键环节；技术上以Java为核心，结合MySQL数据库和SSM（Spring+SpringMVC+MyBatis）框架展开，概述了系统架构设计、数据库设计思路，并重点讨论了功能性、稳定性、安全性、扩展性、用户友好性和实时性等多项设计要求。整份资料为单个docx文档，压缩包大小约9.45MB，文档内包含完整的中英文摘要、目录、绪论、技术介绍、系统分析、系统设计等章节，内容组织规范，便于按章节查阅和参考。目前已有93人学习，适合需要快速把握同类管理系统完整设计脉络、撰写课程设计或毕业设计论文的读者使用。

1. 先别急着写代码：基于java勤工助学管理系统背后要交付什么

多数人拿到《基于java勤工助学管理系统设计与实现.docx》时，手上只有一份选题文档，里面画着用例图、E-R 图和几张页面原型，真正要交的却是一个能跑起来的 Java 后端系统。这类系统的业务模型很固定：学生浏览岗位、提交申请、上报工时，教师或辅导员审核，管理员维护岗位信息并完成工资结算。本质上是“岗位发布—申请—审核—结算”的信息管理闭环，也是 Spring Boot + MyBatis 这类组合最常见的练手场景。

它适合两类人：一类是正在做课程设计或毕业设计的学生，需要把数据库、后端接口和权限控制串成完整项目；另一类是刚学完 Java 基础、想找一个不依赖微服务也能讲清楚“业务到底怎么流转”的实战项目。别急着建表，先把角色和状态想清楚，否则后期每加一个功能都要改表结构。

2. 选型与分层：为什么 Spring Boot + MyBatis 是这类系统的默认答案

勤工助学管理系统并不复杂，但它要处理多角色权限、多表联查和金额计算，选型错了会让自己在答辩前夜翻车。我见过不少同学用 Spring Cloud 全家桶做课设，注册中心、网关、配置中心一个个起，最后演示时服务发现失败，连登录都进不去。对这种数据量几百条、并发几乎为零的课题，技术栈越稳越好。

2.1 为什么不是 JSP+Servlet，也不是 Spring Cloud：三选一的判断标准

先看 JSP + Servlet。它不是不能做，而是把前端页面和后端逻辑揉在一起，权限控制和 Ajax 交互都要手写很多样板代码，代码结构一旦膨胀，改一个功能要牵连好几个 JSP，答辩时很难讲清楚“分层设计”。Spring Cloud 则完全反过来了，微服务拆分、服务注册、配置中心对课设来说是负担，部署一台机器都费劲，更别说演示给评委看。

剩下的就是 Spring Boot + MyBatis。Spring Boot 内嵌 Tomcat，打包成 jar 就能跑，省去部署 war 到外置容器的步骤；MyBatis 把 SQL 写在 Mapper 里，多表查询和报表统计非常直观，也方便后期调优。最现实的一点是，这个组合的中文资料和坑位记录足够多，遇到问题检索一下基本能解决。

判断标准很简单：项目规模在十几个表以内、业务以 CRUD 和状态流转为主、需要写联表查询 SQL，就用 Spring Boot 单体加 MyBatis。不要为了简历好看硬上微服务，课设评委更关心你能不能把一条业务链路从头讲到尾，而不是你会几个组件名字。

2.2 包结构与调用链：controller / service / mapper 各管哪一段

包结构是课设答辩时最容易被打分的地方。一般按功能分包，而不是按层分包，我的习惯是这样：

com.example.ework ├── EworkApplication.java # 启动类 ├── common # 统一返回结果、全局异常、分页工具 ├── config # 拦截器注册、跨域配置、日期转换 ├── controller # 接收请求、参数校验、返回 JSON ├── entity # 与数据库表对应的实体类 ├── mapper # Mapper 接口，配合 resources/mapper/*.xml └── service # 业务逻辑：权限判断、状态流转、金额计算

Controller 层只做三件事：接收参数、调用 Service、封装返回结果。Service 层写真正的业务规则，比如“只能申请一次”“审核通过后才能上报工时”。Mapper 层只负责和数据库打交道，一个方法对应一条 SQL。

调用链可以用“学生申请岗位”来串：Controller 拿到 apply 请求后，从 Session 取当前登录学生 ID，传给 Service；Service 先校验该学生是否已经申请过这个岗位，再校验岗位是否还有剩余名额，最后调用 Mapper 插入一条状态为“待审核”的记录。这一条链路跑通，整个系统的分层逻辑就立住了。

2.3 JDK、Maven、MySQL 与依赖清单：版本搭错了第一步就启动失败

版本搭配是第一个坑，也是最容易让新手心态崩溃的坑。我推荐的组合是 JDK 1.8 + Spring Boot 2.7.x + mybatis-spring-boot-starter 2.3.x + MySQL 8.0，这个组合网上案例最多，遇到报错更容易搜到解决方案。

<parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.7.18</version> <relativePath/> </parent> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.mybatis.spring.boot</groupId> <artifactId>mybatis-spring-boot-starter</artifactId> <version>2.3.2</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <scope>runtime</scope> </dependency> </dependencies>

spring-boot-starter-parent 会统一管理 Spring Boot 相关依赖的版本，所以 web 依赖不用写版本号。mybatis-spring-boot-starter 比较特殊，Spring Boot 的 BOM 不管理它，必须自己指定版本。mysql-connector-java 在 Spring Boot 2.7 中由 parent 管理，scope 设为 runtime 表示只在运行期使用，编译不需要。

如果你用的是 JDK 17 或更高版本，大概率要选 Spring Boot 3.x，但那时依赖坐标里的 javax.servlet 会变成 jakarta.servlet，很多旧教程代码直接粘过来会报“程序包不存在”。课设想少踩坑，就老老实实 JDK 1.8 + Spring Boot 2.7。数据库连接配置放在 application.properties 里，主要注意 MySQL 8 的驱动类名要用com.mysql.cj.jdbc.Driver，并且 URL 加上serverTimezone=Asia/Shanghai，否则日期字段会出现时区偏差。

3. 登录、申请、审核、结算：把业务闭环跑起来的关键代码

系统能不能答辩通过，看的就是这条业务闭环是否完整。很多项目把登录和 CRUD 都写完了，但状态流转是乱的，比如学生被驳回后还能重复申请，或者审核通过的岗位又能第二次被申请。这些问题的根源都在于把业务规则散落在前端页面里，后端没有守住底线。

3.1 登录与访问控制：会话拦截器与“行级权限”的分工

勤工助学系统的用户分三种：学生、辅导员、管理员，登录后需要记录身份和角色。用 Session 存登录用户，再用 Spring 的 HandlerInterceptor 做访问控制，是最直接有效的方式。

public class LoginInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { HttpSession session = request.getSession(); User loginUser = (User) session.getAttribute("login_user"); if (loginUser == null) { response.sendRedirect("/login"); return false; } return true; } }

拦截器的逻辑很简单：每次请求进 Controller 之前检查 Session 里有没有用户，没有就跳回登录页。这里有个关键参数——放行路径，登录接口、静态资源（CSS/JS/图片）必须放行，否则登录页本身都加载不出来。

@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new LoginInterceptor()) .addPathPatterns("/**") .excludePathPatterns("/login", "/doLogin", "/css/**", "/js/**", "/images/**"); } }

拦截器只解决了“是否登录”的问题，解决不了“能不能看这条数据”的问题。学生登录后只能看自己的申请记录和工资单，不能把全表数据返回给前端，这是典型的行级权限场景。行级权限在 Java 后端里一般不靠拦截器实现，而是在 Service 层从 Session 拿当前用户 ID，拼进 SQL 查询条件。常见错误是前端把 studentId 当成参数传过来，后端不校验就直接用，学生把参数改成别人的学号就能越权看数据。正确做法是登录后把用户 ID 存进 Session，Service 层只信任 Session 里的值。

3.2 岗位申请与审核：一个状态字段如何撑起整个流程

岗位申请是这个系统的核心业务，状态字段通常叫 status，用数字表示流转阶段：0 待审核、1 审核通过、2 审核驳回，申请提交后学生可以撤回，再加一个 3 已撤销。整个流程就是围绕这一个字段做条件更新。

@Transactional public boolean applyJob(Long studentId, Long jobId) { int count = applyMapper.countByStudentAndJob(studentId, jobId); if (count > 0) { throw new RuntimeException("不能重复申请该岗位"); } int rows = jobMapper.reduceRemainHours(jobId); if (rows == 0) { throw new RuntimeException("岗位名额不足"); } Apply apply = new Apply(); apply.setStudentId(studentId); apply.setJobId(jobId); apply.setStatus(0); return applyMapper.insert(apply) > 0; }

申请方法里做了两层防护。第一层是应用层查重，先查这个学生有没有申请过该岗位，有就直接拒绝；第二层是数据库唯一索引，防备临界状态下两个请求同时通过第一层查重。reduceRemainHours这条更新语句用了条件更新，UPDATE job SET remain_hours = remain_hours - 1 WHERE id = ? AND remain_hours > 0，返回 0 表示没有可扣减的名额，Spring 事务保证扣名额和插申请记录要么都成功，要么都回滚。

面试时候经常被问“高并发下怎么防止重复申请”，如果能说出“应用层查重加数据库唯一索引兜底，而不是依赖 synchronized 锁”，会显得对并发控制有概念。单机部署时 synchronized 确实能挡住并发，但 Servlet 容器多实例部署时就失效了，数据库唯一索引才是最后一道防线。

审核的逻辑也走条件更新：UPDATE apply SET status = 1 WHERE id = ? AND status = 0。如果影响行数是 0，说明这条申请已经被处理过了，前端会提示“请勿重复审核”。这个模式叫乐观锁，不锁表也能防止状态被覆盖。

3.3 工时上报与工资计算：BigDecimal 和日期类型不能将就

学生通过申请后，需要上报工作时长。工时记录表里至少有开始时间、结束时间、工时数、审核状态。计算工资时最容易出问题的是两个地方：一是工时精度，二是金额精度。

public BigDecimal calculateSalary(List<WorkRecord> records, BigDecimal unitPrice) { BigDecimal totalSeconds = BigDecimal.ZERO; for (WorkRecord record : records) { BigDecimal seconds = BigDecimal.valueOf( Duration.between(record.getStartTime(), record.getEndTime()).getSeconds()); totalSeconds = totalSeconds.add(seconds); } BigDecimal totalHours = totalSeconds.divide( BigDecimal.valueOf(3600), 2, RoundingMode.HALF_UP); return totalHours.multiply(unitPrice).setScale(2, RoundingMode.HALF_UP); }

这段代码避免了一个很隐蔽的坑：Duration.between().toHours()只保留整数小时，学生干了两小时四十分钟，会被算成两小时。正确做法是先转成秒或分钟，再乘以时薪。getSeconds()拿到的差值精确到秒，除以 3600 保留两位小数，四舍五入用的是RoundingMode.HALF_UP，也就是传统的“四舍五入”。

金额计算必须用 BigDecimal。double 在二进制里本身就不精确，0.1 加 0.2 的结果是 0.30000000000000004，工资表里出现这种数字，答辩时很难解释。数据库里金额字段一律用DECIMAL(10,2)，Java 实体里用 BigDecimal，不能图省事用 double。如果要把计算后的金额写回数据库，可以调用BigDecimal.setScale(2, RoundingMode.HALF_UP)保证精度一致。

工时记录的展示按时间排序，可以直接在 SQL 里ORDER BY work_date DESC，比在 Java 里用 Comparator 排序更省事，也减少一次内存排序的开销。数据量小不影响性能，但写成 SQL 更清晰，面试官也更容易看懂。

4. 数据库设计：三张主表、唯一约束与 MyBatis 映射的配合

业务代码写完了，数据库设计跟不上，照样跑不通。很多课设的失败不是败在 Java 代码上，而是表结构设计得乱七八糟，岗位表没有发布时间字段、申请表没有状态字段、工资表直接用 double，最后联表查询怎么写都不对。这一章按“主表→约束→映射”来讲。

4.1 学生、岗位、申请三张表：字段、类型与关联关系的取舍

用户表先单独建，存放登录账号和角色，角色用 TINYINT 区分：0 学生、1 辅导员、2 管理员。学生表存学号、姓名、班级、电话等基本信息，学号加唯一索引，防止同一个人注册两个账号。

CREATE TABLE `job` ( `id` BIGINT PRIMARY KEY AUTO_INCREMENT, `title` VARCHAR(100) NOT NULL COMMENT '岗位名称', `unit_price` DECIMAL(10,2) NOT NULL COMMENT '时薪（元）', `total_hours` INT NOT NULL DEFAULT 0 COMMENT '总工时预算', `remain_hours` INT NOT NULL DEFAULT 0 COMMENT '剩余工时', `status` TINYINT NOT NULL DEFAULT 1 COMMENT '1-招聘中 0-已关闭', `description` VARCHAR(500) COMMENT '岗位描述', `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

岗位表注意三个地方：unit_price用 DECIMAL，不用 FLOAT；remain_hours每次申请成功后要减少，所以不能设置为和 total_hours 一样但完全依靠应用层计算，而是在一次 UPDATE 里同时判断“大于 0 才能减”，保证准确。create_time用 DATETIME 而不是 TIMESTAMP，避免 2038 年问题和时区转换麻烦。

CREATE TABLE `apply` ( `id` BIGINT PRIMARY KEY AUTO_INCREMENT, `student_id` BIGINT NOT NULL, `job_id` BIGINT NOT NULL, `status` TINYINT NOT NULL DEFAULT 0 COMMENT '0-待审核 1-通过 2-驳回 3-已撤销', `apply_time` DATETIME DEFAULT CURRENT_TIMESTAMP, `review_time` DATETIME NULL, UNIQUE KEY `uk_student_job` (`student_id`, `job_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

申请表是业务核心，status默认 0，表示提交后进入待审核状态，不需要应用层显式赋值。review_time允许为空，审核通过或驳回时再写入。唯一索引uk_student_job就是 3.2 节说的数据库防线，它保证同一个学生不可能对同一个岗位产生两条申请记录。

表之间的关联用逻辑外键，也就是只在 Java 代码里维护关联关系，不建物理外键。物理外键在删除数据时会受约束限制，比如想删掉一个岗位，如果申请记录还引用着它，Delete 会被数据库拒绝，课设调试时非常麻烦。逻辑外键没有这个限制，只要保证插入的数据是正确的，关联关系靠 SQL 联表查出来即可。

4.2 默认值、唯一索引与条件更新：挡住重复申请和重复审核

表结构设计决定了业务规则能不能守住。三个细节一定要在建表时就做对：能设默认值的字段不要依赖应用层赋值，能加唯一索引的业务组合一定要加，UPDATE 语句要带状态条件。

apply_time的默认值CURRENT_TIMESTAMP让数据库替我们记录提交时间；status默认 0 让新插入的申请自动进入待审核状态。这些默认值保证即使某个接口漏写了赋值代码，数据也不会变成 NULL，脏数据的可能性就小很多。

条件更新的 SQL 是防重复审核的关键：

UPDATE apply SET status = 1, review_time = NOW() WHERE id = #{id} AND status = 0;

这条 SQL 只更新“当前仍然处于待审核状态”的记录。如果辅导员在页面上重复点击通过按钮，第二次执行时条件status = 0已经不成立，影响行数是 0，Service 层拿到 0 就可以抛出“该申请已处理”的异常。这个思路和防止超卖是同一个套路：把业务条件写进 UPDATE 的 WHERE 里，而不是先 SELECT 再 UPDATE。

4.3 MyBatis 映射与联表查询：驼峰、ResultMap 和时间字段的配合

实体类字段用驼峰命名，数据库列用下划线命名，这是 Java 项目的惯例。MyBatis 默认不会自动把real_name映射到realName属性，需要在 application.properties 里打开开关：

mybatis.configuration.map-underscore-to-camel-case=true

打开后，普通的单表查询不需要写 resultMap，MyBatis 自动完成下划线到驼峰的转换。但联表查询想带出关联字段时，还是要用 resultMap 或别名。

<select id="selectApplyDetail" resultType="com.example.ework.entity.ApplyVO"> SELECT a.id, a.job_id, a.status, a.apply_time, s.name AS studentName, s.student_no AS studentNo, j.title AS jobTitle, j.unit_price AS unitPrice FROM apply a LEFT JOIN student s ON a.student_id = s.id LEFT JOIN job j ON a.job_id = j.id WHERE a.student_id = #{studentId} ORDER BY a.apply_time DESC </select>

这里的studentName、jobTitle是实体里并不存在的字段，所以要建一个 ApplyVO 类来承接查询结果。VO 类里的属性名和 SQL 别名完全一致，MyBatis 会按属性名映射，不需要额外配置。注意apply_time是 DATETIME 类型，Java 属性用LocalDateTime接收，MyBatis 对 JSR-310 时间类型有原生支持，不用加特殊处理器。

联表查询的 LEFT JOIN 顺序也有讲究。这里必须以 apply 为驱动表，学生和岗位都是补全信息，即使用 INNER JOIN 结果也一样，但 LEFT JOIN 能保证即使岗位被删除，申请记录仍然能查出来，只是 jobTitle 为 null，前端显示“岗位已撤销”而不是整条记录消失。

调试 MyBatis 的 SQL 时，在 application.properties 里打开 Mapper 日志：

logging.level.com.example.ework.mapper=debug

这样控制台会打印实际执行的 SQL 和参数值。很多“查不到数据”的玄学问题，打开日志看到参数才意识到是传了 null 进去，根本不是 SQL 写错。

5. 避坑排查：从启动失败到工资算错的五条实战记录

这一章写的都是课设里反复出现的真实事故。每条按“现象→原因→解决”来说，都是我实际带项目时踩过或见人踩过的坑。

5.1 启动失败：八成是版本、端口和环境变量的问题

现象：mvn spring-boot:run后控制台报Application run failed，或提示端口被占用，或者干脆提示找不到主类。

原因分三类。第一类是 JAVA_HOME 环境变量没有配置或配错，Maven 用的是配置的 JDK 路径，命令行里java -version正常不代表 Maven 能正常工作。第二类是 Spring Boot 项目配置的端口被占用，常见的是之前残留的进程还占着 8080。第三类是版本不匹配，Spring Boot 3.x 项目用 JDK 8 编译，直接报UnsupportedClassVersionError。

解决：先确认环境变量，echo $JAVA_HOME（Windows 用echo %JAVA_HOME%）看路径指向是不是 JDK 而不是 JRE。再用netstat -ano | findstr :8080找出占用端口的 PID，把残留 java 进程结束掉，或者直接在 application.properties 里改server.port=8081。版本问题最省事的办法是把 Spring Boot 降到 2.7.x，配合 JDK 1.8，不要一上来就追新版本。

5.2 MyBatis 返回结果与预期不符：是 SQL 错还是映射错

现象：接口返回的列表里某些字段是 null，明明数据库里有值；或者多表联查时只查出了主表字段，关联字段全是空。

原因：最常见的是实体类属性和数据库列名对不上，又没开map-underscore-to-camel-case；其次是 SQL 里没有写别名，数据库返回的是student_name，实体类属性叫studentName，映射失败。第三种是 Mapper 接口的方法名和 XML 里的 id 不一致，MyBatis 运行时报Invalid bound statement，这种报错其实更好定位。

解决：第一步打开驼峰映射开关，绝大多数单表字段都能自动对上。第二步对多表联查的字段用别名显式指定，让返回列名和实体属性名完全一致。第三步看日志里打印的 SQL，把 SQL 复制到 Navicat 里直接跑一遍，能立刻判断是数据问题还是映射问题。SQL 日志是排查 MyBatis 问题的第一工具，比反复看代码高效得多。

5.3 时间和字符串格式不对，导致查询结果为空

现象：前端传一个日期字符串2025-06-01到后端，后端用LocalDateTime接收，请求直接 400；或者按日期范围查申请记录，查出来永远是空。

原因：Spring Boot 默认对LocalDateTime的 JSON 反序列化格式是yyyy-MM-ddTHH:mm:ss，前端传的是yyyy-MM-dd，格式不匹配，解析失败。查询为空是因为数据库里apply_time是2025-06-01 14:23:00，代码里却用LIKE '2025-06-01'去匹配 DATETIME 字段，注意事项是 LIKE 匹配只能查到部分 MySQL 版本下格式恰好一致的记录。

解决：在接收参数的实体字段上加@JsonFormat注解统一格式。查询日期范围时，把传入的日期结束值补上时间部分，endDate + " 23:59:59"，或者干脆用DATE_FORMAT(apply_time, '%Y-%m-%d')和前端传的字符串比较，但这样会导致索引失效，数据量大时不建议。课设里最稳妥的做法是前端传完整范围时间，后端用BETWEEN #{startTime} AND #{endTime}。

5.4 double 算钱算出 199.999999：金额计算必须用 BigDecimal

现象：工资计算结果显示 199.999999，或者 1.0E2 这样的科学计数法数字。

原因：用 double 做乘法再输出，二进制浮点数的精度误差被放大。数据库字段若设计成 DOUBLE，MySQL 本身也会出现精度问题，回传 Java 后误差继续累积。很多新手同学习惯把所有数字都用 double，工时、单价、工资一路 double 算下来，最后在页面上就出现了“199.999999”。

解决：金额相关的实体字段用 BigDecimal，数据库列用 DECIMAL(10,2)。计算时不要用new BigDecimal(double)，这个构造方法会把二进制误差带进来，正确姿势是BigDecimal.valueOf(0.1)或从字符串构造。加法和乘法之后用setScale(2, RoundingMode.HALF_UP)收尾。习惯养成后，这类问题基本可以绝迹。

5.5 导出文件中文名乱码：响应头编码设置

现象：导出 Excel 或 CSV 功能，文件内容正常，但下载的文件名是一串乱码，比如“岗位工资表.xls”变成“????.xls”。

原因：HTTP 响应头Content-Disposition里的文件名默认按 Latin-1 编码，中文直接写进去会被浏览器按错误的方式解码。这是老问题，主流浏览器对响应头里的 UTF-8 支持各有差异，不能只靠一个filename参数。

解决：对文件名做 URL 编码，并且同时提供filename和filename*两个参数。

String fileName = "岗位工资表.xls"; String encodedName = URLEncoder.encode(fileName, StandardCharsets.UTF_8.toString()).replaceAll("\\+", "%20"); response.setHeader("Content-Disposition", "attachment; filename=\"" + encodedName + "\"; filename*=UTF-8''" + encodedName);

filename*是 RFC 5987 标准定义的写法，UTF-8''后面跟 URL 编码后的文件名，绝大多数现代浏览器都会优先识别这个参数。URLEncoder 会把空格编码成加号，所以要 replace 成%20，否则文件名里的空格会显示成加号。

6. 部署验证与加分项：让系统从“能跑”到“能演示”

代码写完了，课设答辩前一天要做三件事：本地打包、数据库初始化、走一遍完整业务流程。很多人死在最后一步，代码在 IDEA 里点运行没问题，打包后部署却起不来。

6.1 打包、部署与自测路径

用 Maven 打可执行 jar 包：

mvn clean package -DskipTests java -jar target/ework-0.0.1-SNAPSHOT.jar

-DskipTests跳过测试，避免测试类报错阻断打包。启动时如果连的不是本地数据库，用启动参数覆盖配置：

java -jar target/ework-0.0.1-SNAPSHOT.jar --spring.datasource.url=jdbc:mysql://192.168.1.100:3306/ework?serverTimezone=Asia/Shanghai --spring.datasource.username=root --spring.datasource.password=123456

部署完自测路径按业务顺序走：管理员登录→创建岗位→学生注册登录→申请岗位→管理员审核通过→学生上报工时→管理员查看工资结算单→导出 Excel 文件。每个环节刷新页面确认状态变化正确，特别是申请后立刻再次申请，必须被唯一索引拦下来。

6.2 用 Spring 定时任务做月度工时汇总

如果想让项目在答辩时有点亮点，用一个月度工资汇总的定时任务很不错。Spring 自带的@Scheduled就能实现，不需要额外引入 Quartz 框架，代码轻量且容易讲清楚。

@Component public class MonthlySalaryTask { @Scheduled(cron = "0 0 1 1 * ?") public void generateMonthlyReport() { LocalDate now = LocalDate.now(); LocalDate lastMonthStart = now.minusMonths(1).withDayOfMonth(1); LocalDate lastMonthEnd = now.withDayOfMonth(1).minusDays(1); List<WorkRecord> records = workRecordMapper.findByTimeRange( lastMonthStart.atStartOfDay(), lastMonthEnd.atTime(LocalTime.MAX)); for (WorkRecord record : records) { // 按岗位汇总工时，计算应发工资，写入月度统计表 } } }

cron 表达式0 0 1 1 * ?表示每月 1 日凌晨 1 点执行。秒、分、时分别是 0、0、1，日期是 1，月份和星期用通配符。定时任务代码要写在 Service 层或独立的 Component 里，不要在 Controller 里搞定时任务。主启动类上加@EnableScheduling开启定时能力。为了演示效果，可以临时改成每分钟执行一次，看汇总表数据变化后再改回正式周期。

答辩时被问到定时任务，如果能说出“用 Spring 的 @Scheduled 而不是 Quartz，因为单机任务用轻量方案足够，Quartz 的调度器、持久化在课设场景是过度设计”，这段回答比功能本身更加分。

我带这个方向的项目带了好几轮，最深的体会是：这类系统真正的难点从来不是框架怎么配，而是状态流转和数据精度有没有从数据库层面守住。如果让我从零再做一次，我会先在纸上把“待审核→通过→驳回”的状态图画出来，再建表写代码。状态图画清楚了，代码只是把它翻译出来而已。希望这个方向的经验能帮到你少走一段夜路。

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