企业官网建设流程全解析

简介：这是一套面向高校计算机专业毕业设计的JavaWeb体育竞赛管理系统完整项目源码，适合正在准备毕设或需要JavaWeb实战练手的开发者参考。系统基于JDK1.8、JSP与MySQL 5.7开发，采用经典JavaWeb架构，涵盖运动员报名与成绩查询、管理员用户与参赛管理、裁判员成绩录入与公示三大角色模块，可帮助读者理解权限划分、数据流转与前后端协作的完整实现思路。资源包共2662个文件，包含62个jsp页面、60个java源码、134个class编译文件、32个jar依赖，以及大量html、js、css、png等前端静态资源，另附sql建表脚本与说明文档，压缩包约29.37MB，目录结构清晰便于按模块查阅。目前已有903人学习下载，可作为毕设选题参考、课程设计模板或JavaWeb入门到进阶的实践案例，帮助快速搭建竞赛管理类系统的功能框架与数据库设计。

1. 从一份“能跑起来”的体育竞赛管理系统说起

体育竞赛管理系统这个题目，在计算机专业本科毕设里出现的频率高得离谱，但真正能拿得出手的并不多。我见过太多同学把需求书写得天花乱坠，最后交上来的系统连“报名—编排—记分—排名”这条主线都跑不通。问题不在技术难度，而在于大多数人一开始就选错了方向：要么堆砌一堆用不上的模块，要么把精力全耗在前端花哨的动画上，核心业务逻辑反而一塌糊涂。

这篇笔记要讲清楚一件事：用 JavaWeb 技术栈，怎么从零搭出一个结构清晰、业务闭环、答辩时经得起追问的体育竞赛管理系统。适合正在做毕设、需要一套完整案例参考的本科生，也适合想用 SpringBoot 快速落地一个 CRUD 密集型项目的开发者。我不会只给你代码片段，而是把选型理由、数据库设计、关键接口实现、以及那些只有真正跑过项目才会遇到的坑，一条条拆开讲。读完你至少能判断：这个方向值不值得投入，以及怎么投入才不会翻车。

2. 技术选型与数据库设计：为什么这套组合最适合毕设

2.1 JavaWeb 技术栈的取舍逻辑

体育竞赛管理系统的本质是什么？是一套围绕“赛事”这个核心实体的增删改查，加上报名、分组、成绩录入、排名计算这几条业务线。它不需要高并发，不需要分布式，甚至不需要 Redis 缓存。这意味着技术选型的核心原则只有一条：用最少的组件把业务闭环跑通，同时让代码结构经得起答辩老师的审视。

我一般会推荐 SpringBoot + MyBatis-Plus + MySQL + Thymeleaf 这套组合。SpringBoot 负责把 Tomcat、Spring MVC、事务管理全部自动装配好，省掉大量 XML 配置；MyBatis-Plus 在 MyBatis 基础上提供了单表 CRUD 的零 SQL 能力，同时保留了手写复杂查询的灵活性；Thymeleaf 作为服务端模板引擎，天然适合毕设这种“页面不多但需要动态渲染”的场景。前端不需要上 Vue 或 React，用 Bootstrap 加少量 jQuery 就够了——答辩老师看的是业务逻辑，不是你的前端工程化水平。

提示：如果你的学校明确要求“必须用 SSM 框架”，把 SpringBoot 换成 Spring + SpringMVC + MyBatis 即可，业务代码几乎不用改，只是多写几个 XML 配置文件。

数据库选 MySQL 8.0，字符集用 utf8mb4，排序规则用 utf8mb4_general_ci。这个组合在 Windows 和 Linux 上表现一致，不会出现中文乱码的玄学问题。连接池用 HikariCP，SpringBoot 默认自带，不需要额外引入 Druid——除非你的答辩老师特别在意 SQL 监控。

2.2 数据库表结构设计：五张核心表撑起整个系统

很多同学一上来就建十几张表，结果自己都理不清关系。体育竞赛管理系统的核心实体只有五个：用户、赛事、报名记录、比赛分组、成绩记录。下面是我在实际项目中反复验证过的表结构，直接可以抄。

-- 用户表：区分管理员、裁判、运动员三种角色 CREATE TABLE `sys_user` ( `id` BIGINT NOT NULL AUTO_INCREMENT COMMENT '主键', `username` VARCHAR(50) NOT NULL COMMENT '登录名', `password` VARCHAR(100) NOT NULL COMMENT '密码（BCrypt加密）', `real_name` VARCHAR(50) DEFAULT NULL COMMENT '真实姓名', `role` TINYINT NOT NULL DEFAULT 3 COMMENT '角色：1管理员 2裁判 3运动员', `phone` VARCHAR(20) DEFAULT NULL COMMENT '联系电话', `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户表'; -- 赛事表：一场比赛的基本信息 CREATE TABLE `competition` ( `id` BIGINT NOT NULL AUTO_INCREMENT, `name` VARCHAR(100) NOT NULL COMMENT '赛事名称', `sport_type` VARCHAR(50) NOT NULL COMMENT '项目类型：田径/游泳/球类', `start_date` DATE NOT NULL COMMENT '开始日期', `end_date` DATE NOT NULL COMMENT '结束日期', `location` VARCHAR(200) DEFAULT NULL COMMENT '比赛地点', `status` TINYINT DEFAULT 0 COMMENT '状态：0报名中 1进行中 2已结束', `max_participants` INT DEFAULT 0 COMMENT '人数上限，0表示不限', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='赛事表'; -- 报名记录表：运动员与赛事的关联 CREATE TABLE `registration` ( `id` BIGINT NOT NULL AUTO_INCREMENT, `competition_id` BIGINT NOT NULL COMMENT '赛事ID', `user_id` BIGINT NOT NULL COMMENT '运动员ID', `register_time` DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT '报名时间', `status` TINYINT DEFAULT 0 COMMENT '状态：0待审核 1已通过 2已拒绝', PRIMARY KEY (`id`), UNIQUE KEY `uk_comp_user` (`competition_id`, `user_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='报名记录表'; -- 分组表：同一赛事下运动员的分组 CREATE TABLE `group_info` ( `id` BIGINT NOT NULL AUTO_INCREMENT, `competition_id` BIGINT NOT NULL COMMENT '赛事ID', `group_name` VARCHAR(50) NOT NULL COMMENT '组名，如A组/B组', `lane` INT DEFAULT NULL COMMENT '道次/序号', `user_id` BIGINT NOT NULL COMMENT '运动员ID', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='分组表'; -- 成绩表：最终成绩与排名 CREATE TABLE `score` ( `id` BIGINT NOT NULL AUTO_INCREMENT, `competition_id` BIGINT NOT NULL COMMENT '赛事ID', `user_id` BIGINT NOT NULL COMMENT '运动员ID', `result` VARCHAR(50) NOT NULL COMMENT '成绩值，如11.23秒/5.67米', `rank` INT DEFAULT NULL COMMENT '排名', `judge_id` BIGINT DEFAULT NULL COMMENT '录入裁判ID', `record_time` DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT '录入时间', PRIMARY KEY (`id`), UNIQUE KEY `uk_comp_user_score` (`competition_id`, `user_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='成绩表';

这五张表的设计有几个关键决策需要说明。第一，用户表用role字段区分角色而不是拆成三张表，因为三种角色的登录逻辑完全一致，拆表只会增加关联查询的复杂度。第二，报名记录表加了(competition_id, user_id)唯一索引，从数据库层面杜绝重复报名，比在代码里查一遍再插入可靠得多。第三，成绩表的result字段用 VARCHAR 而不是 DECIMAL，因为不同项目的成绩单位不同——跑步是秒，跳远是米，游泳可能是分秒混合，用字符串存储更灵活，排名计算在 Java 层做。

2.3 SpringBoot 项目骨架与依赖配置

创建一个 SpringBoot 项目，用 IDEA 的 Spring Initializr 或者直接去 start.spring.io 生成都行。关键依赖只有四个：Spring Web、MyBatis-Plus、MySQL Driver、Thymeleaf。Lombok 可选，但建议加上，能省掉大量 getter/setter。

<!-- pom.xml 核心依赖 --> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.3.1</version> </dependency> <dependency> <groupId>com.mysql</groupId> <artifactId>mysql-connector-j</artifactId> <scope>runtime</scope> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-thymeleaf</artifactId> </dependency> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency> </dependencies>

application.yml的配置同样简洁，重点是数据库连接和 MyBatis-Plus 的驼峰映射：

server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/sports_meet?useUnicode=true&characterEncoding=utf8mb4&serverTimezone=Asia/Shanghai username: root password: 你的密码 driver-class-name: com.mysql.cj.jdbc.Driver mybatis-plus: configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: id-type: auto

map-underscore-to-camel-case这个配置必须开，否则数据库的real_name字段映射不到 Java 的realName属性，查出来全是 null。log-impl开成 StdOutImpl 是为了在控制台看到实际执行的 SQL，调试阶段非常有用，上线前记得关掉。

3. 核心业务接口实现：从报名到排名的完整链路

3.1 报名接口：并发重复提交的防护

报名是体育竞赛管理系统里第一个容易出问题的环节。用户点两次提交按钮，或者网络延迟导致重复请求，都会产生两条报名记录。虽然数据库唯一索引能兜底，但直接抛异常给用户体验很差。我的做法是在 Service 层用synchronized加本地锁，配合数据库唯一索引做双重防护。

@Service public class RegistrationService { @Autowired private RegistrationMapper registrationMapper; @Autowired private CompetitionMapper competitionMapper; // 对同一赛事+用户的报名操作加锁，防止并发重复插入 public String register(Long competitionId, Long userId) { // 先查赛事状态，只有报名中的赛事才能报名 Competition comp = competitionMapper.selectById(competitionId); if (comp == null || comp.getStatus() != 0) { return "赛事不存在或不在报名阶段"; } // 检查人数上限 if (comp.getMaxParticipants() > 0) { Long count = registrationMapper.selectCount( new LambdaQueryWrapper<Registration>() .eq(Registration::getCompetitionId, competitionId) .eq(Registration::getStatus, 1) ); if (count >= comp.getMaxParticipants()) { return "报名人数已满"; } } // 加锁防止并发重复提交 synchronized (this) { Long exist = registrationMapper.selectCount( new LambdaQueryWrapper<Registration>() .eq(Registration::getCompetitionId, competitionId) .eq(Registration::getUserId, userId) ); if (exist > 0) { return "你已经报名过该赛事"; } Registration reg = new Registration(); reg.setCompetitionId(competitionId); reg.setUserId(userId); reg.setStatus(0); // 待审核 registrationMapper.insert(reg); } return "报名成功，等待审核"; } }

这段代码的逻辑顺序很重要：先校验赛事状态，再校验人数上限，最后才进入加锁区做重复检查。如果把所有校验都塞进synchronized块里，锁的粒度太大，并发性能会急剧下降。synchronized (this)锁的是当前 Service 实例，在单机部署下够用；如果考虑多节点部署，需要换成 Redis 分布式锁，但毕设场景单机完全足够。

注意：selectCount返回的是 Long 类型，和 int 比较时要用count >= comp.getMaxParticipants()，Java 会自动拆箱，但count为 null 时会 NPE。MyBatis-Plus 的selectCount不会返回 null，放心用。

3.2 分组编排：手动分组与自动分组的实现差异

分组编排是体育竞赛管理系统的核心功能之一。常见做法有两种：裁判手动拖拽分组，或者系统按报名顺序自动分组。手动分组灵活但操作繁琐，自动分组高效但缺乏灵活性。我的方案是两者都支持，默认自动分组，裁判可以在自动分组结果上手动调整。

自动分组的逻辑很简单：查出该赛事所有审核通过的报名记录，按报名时间排序，然后按每组人数上限依次分配组名。下面是一个可复用的分组方法：

public void autoGroup(Long competitionId, int groupSize) { // 查询已通过审核的报名记录，按报名时间升序 List<Registration> list = registrationMapper.selectList( new LambdaQueryWrapper<Registration>() .eq(Registration::getCompetitionId, competitionId) .eq(Registration::getStatus, 1) .orderByAsc(Registration::getRegisterTime) ); if (list.isEmpty()) { throw new RuntimeException("没有已通过审核的报名记录"); } // 先清除该赛事已有的分组数据，避免重复分组 groupInfoMapper.delete( new LambdaQueryWrapper<GroupInfo>() .eq(GroupInfo::getCompetitionId, competitionId) ); // 按 groupSize 切分，生成 A组、B组、C组... int groupCount = (int) Math.ceil((double) list.size() / groupSize); for (int i = 0; i < groupCount; i++) { char groupName = (char) ('A' + i); int start = i * groupSize; int end = Math.min(start + groupSize, list.size()); List<Registration> subList = list.subList(start, end); for (int j = 0; j < subList.size(); j++) { GroupInfo gi = new GroupInfo(); gi.setCompetitionId(competitionId); gi.setGroupName(groupName + "组"); gi.setLane(j + 1); // 道次从1开始 gi.setUserId(subList.get(j).getUserId()); groupInfoMapper.insert(gi); } } }

groupSize参数由裁判在页面上输入，常见值是 6 或 8。Math.ceil保证最后一组人数不足时也能正确生成组名。subList返回的是原列表的视图，不是新列表，但这里只用于遍历读取，没有修改操作，所以安全。如果后续要对子列表做写操作，需要new ArrayList<>(subList)包一层。

手动调整分组的接口只需要两个操作：删除某条分组记录，插入一条新的分组记录。前端用拖拽组件把运动员从一组拖到另一组，后端接收userId和新的groupId即可。这里不展开前端代码，核心是保证group_info表的(competition_id, user_id)组合唯一，避免同一个运动员出现在两个组里。

3.3 成绩录入与排名计算：排序稳定性的坑

成绩录入看起来简单，但排名计算有一个容易被忽略的坑：成绩相同时的并列排名处理。比如两名运动员都是 11.23 秒，他们应该并列第一，下一名是第三名，而不是第二名。很多同学直接用Collections.sort然后按索引赋值排名，遇到相同成绩就会出错。

public void calculateRank(Long competitionId) { List<Score> scores = scoreMapper.selectList( new LambdaQueryWrapper<Score>() .eq(Score::getCompetitionId, competitionId) ); // 按成绩值排序，这里假设 result 是纯数字字符串（如"11.23"） // 如果是"1分23秒"这种格式，需要先解析成秒数 scores.sort((a, b) -> { double va = parseResult(a.getResult()); double vb = parseResult(b.getResult()); return Double.compare(va, vb); // 升序，用时少者排名靠前 }); int rank = 1; for (int i = 0; i < scores.size(); i++) { if (i > 0) { double prev = parseResult(scores.get(i - 1).getResult()); double curr = parseResult(scores.get(i).getResult()); if (curr > prev) { rank = i + 1; // 成绩不同，排名跳到当前索引+1 } // 成绩相同，rank 保持不变，实现并列排名 } Score s = scores.get(i); s.setRank(rank); scoreMapper.updateById(s); } } // 将成绩字符串解析为 double，支持"11.23"和"1:23.45"两种格式 private double parseResult(String result) { if (result.contains(":")) { String[] parts = result.split(":"); return Double.parseDouble(parts[0]) * 60 + Double.parseDouble(parts[1]); } return Double.parseDouble(result); }

这段代码的关键在于rank变量的更新时机：只有当当前成绩严格大于前一个成绩时，才把rank更新为i + 1。如果成绩相同，rank不变，自然形成并列。parseResult方法处理了两种常见格式，如果你的系统只支持一种，可以简化。

提示：scores.sort使用的是 TimSort，它是稳定排序。但这里的比较器只比较了成绩值，如果两个成绩完全相同，它们的相对顺序取决于原始列表的顺序。对于排名计算来说，这没有影响，因为并列排名不关心谁在前谁在后。

4. 避坑与排查：那些答辩前夜才会暴露的问题

4.1 中文乱码：从数据库到页面的全链路排查

现象：页面上显示的运动员姓名是“å¼ ä¸‰”这样的乱码，或者数据库里存进去的中文变成了问号。

原因：中文乱码可能出现在三个环节——数据库字符集、JDBC 连接字符集、HTTP 响应字符集。任何一个环节不是 utf8mb4，都会导致乱码。最常见的是建库时用了默认的 latin1，或者 JDBC URL 里没加characterEncoding=utf8mb4。

解决：按顺序检查三处。第一，执行SHOW CREATE DATABASE sports_meet;确认字符集是 utf8mb4。第二，检查application.yml里的 JDBC URL 是否包含useUnicode=true&characterEncoding=utf8mb4。第三，在application.yml里加server.servlet.encoding.charset=utf8mb4和server.servlet.encoding.force=true。三处都改完重启，乱码问题基本消失。

4.2 MyBatis-Plus 字段映射失效：查出来全是 null

现象：数据库里明明有数据，但查出来的实体对象所有字段都是 null，或者只有 id 有值。

原因：MyBatis-Plus 默认开启驼峰映射，但如果你在实体类上用了@TableField注解却写错了列名，或者数据库字段名和 Java 属性名不符合驼峰规则（比如real_name对应realname而不是realName），映射就会失败。

解决：先确认mybatis-plus.configuration.map-underscore-to-camel-case=true已配置。然后检查实体类的属性名是否严格遵循驼峰命名：real_name→realName，create_time→createTime。如果某个字段确实无法对应，用@TableField("real_name")显式指定。最后，打开log-impl看实际执行的 SQL，如果 SQL 查出了数据但对象为 null，一定是映射问题。

4.3 事务不生效：报名成功了但分组没生成

现象：调用一个包含多个数据库操作的方法，前面的操作成功了，后面的操作抛异常回滚了，但前面的数据没有回滚。

原因：Spring 的@Transactional注解默认只对RuntimeException回滚，对CheckedException不回滚。另外，如果方法不是public的，或者同类内部方法直接调用（没有走代理），事务也不会生效。

解决：在@Transactional注解上明确指定rollbackFor = Exception.class。确保加了注解的方法是public的，并且是从其他类调用的。如果确实需要在同类内部调用，用AopContext.currentProxy()获取代理对象再调用，或者把事务方法抽到另一个 Service 里。

4.4 前端日期格式不匹配：提交表单时报 400

现象：新增赛事时，日期选择器选的值提交到后端，报 400 Bad Request，控制台提示Failed to convert value of type 'java.lang.String' to required type 'java.util.Date'。

原因：Spring MVC 默认不支持把yyyy-MM-dd格式的字符串自动转成Date类型，需要加@DateTimeFormat注解或者全局配置日期转换器。

解决：在实体类的日期字段上加@DateTimeFormat(pattern = "yyyy-MM-dd")，或者在 Controller 方法的参数上加@RequestParam @DateTimeFormat(pattern = "yyyy-MM-dd") Date startDate。如果项目里日期字段很多，建议写一个全局的Converter<String, Date>配置类，一次性解决。

4.5 静态资源 404：Thymeleaf 页面样式丢失

现象：Thymeleaf 页面能打开，但 CSS 和 JS 全部 404，页面样式全乱。

原因：SpringBoot 默认把classpath:/static/目录作为静态资源根路径，但 Thymeleaf 页面里引用资源时如果写了/css/style.css，实际会去static/css/style.css找。如果文件放在了templates/目录下，或者路径大小写不一致，就会 404。

解决：确认静态资源放在src/main/resources/static/目录下，引用时用/css/style.css或th:href="@{/css/style.css}"。不要用相对路径../css/style.css，Thymeleaf 解析相对路径时容易出错。如果用了 Spring Security，还需要在配置里放行静态资源路径。

5. 答辩加分项：用 AOP 做操作日志与数据校验

5.1 为什么操作日志是性价比最高的加分项

毕设答辩时，老师最喜欢问的两个问题是：“你这个系统有什么亮点？”和“如果两个人同时操作同一条数据怎么办？”操作日志能同时回答这两个问题。它记录了谁在什么时间做了什么操作，既是审计依据，也是排查问题的黑匣子。用 Spring AOP 实现操作日志，代码量不超过 100 行，但答辩时能讲出“切面、注解、异步记录”这些关键词，印象分直接拉满。

5.2 自定义注解 + AOP 切面的完整实现

先定义一个@OpLog注解，用在需要记录日志的 Controller 方法上：

@Target(ElementType.METHOD) @Retention(RetentionPolicy.RUNTIME) public @interface OpLog { String module() default ""; // 模块名，如"赛事管理" String action() default ""; // 操作类型，如"新增" }

然后写切面类，拦截所有带@OpLog注解的方法：

@Aspect @Component public class OpLogAspect { @Autowired private OpLogMapper opLogMapper; // 环绕通知，在方法执行前后记录日志 @Around("@annotation(opLog)") public Object around(ProceedingJoinPoint joinPoint, OpLog opLog) throws Throwable { long start = System.currentTimeMillis(); Object result = null; try { result = joinPoint.proceed(); // 执行目标方法 return result; } finally { // 无论成功失败都记录日志 OpLogEntity entity = new OpLogEntity(); entity.setModule(opLog.module()); entity.setAction(opLog.action()); entity.setMethod(joinPoint.getSignature().toShortString()); entity.setParams(Arrays.toString(joinPoint.getArgs())); entity.setCostMs(System.currentTimeMillis() - start); entity.setCreateTime(new Date()); // 异步写入，避免影响主流程性能 CompletableFuture.runAsync(() -> opLogMapper.insert(entity)); } } }

在 Controller 方法上加注解即可生效：

@PostMapping("/competition/add") @OpLog(module = "赛事管理", action = "新增赛事") public String addCompetition(Competition competition) { competitionService.save(competition); return "redirect:/competition/list"; }

@Around通知的joinPoint.proceed()会执行目标方法，返回值就是目标方法的返回值。finally块保证无论方法是否抛异常，日志都会记录。CompletableFuture.runAsync把写日志的操作放到异步线程，避免数据库写入拖慢主流程。joinPoint.getArgs()返回的是参数数组，直接Arrays.toString可能包含敏感信息（比如密码），实际项目中需要过滤。

5.3 参数校验：用 Validation 替代手写 if-else

另一个加分项是参数校验。很多同学在 Controller 里写一堆if (name == null || name.isEmpty())，代码又臭又长。用 Spring Validation 可以把校验逻辑抽到实体类的注解上：

public class CompetitionForm { @NotBlank(message = "赛事名称不能为空") @Size(max = 100, message = "赛事名称不能超过100个字符") private String name; @NotNull(message = "开始日期不能为空") @FutureOrPresent(message = "开始日期不能早于今天") @DateTimeFormat(pattern = "yyyy-MM-dd") private Date startDate; @NotNull(message = "结束日期不能为空") @DateTimeFormat(pattern = "yyyy-MM-dd") private Date endDate; @Min(value = 0, message = "人数上限不能为负数") private Integer maxParticipants; }

Controller 方法加上@Valid注解，校验失败会自动返回 400，配合全局异常处理器可以返回友好的错误提示：

@PostMapping("/competition/add") @OpLog(module = "赛事管理", action = "新增赛事") public String addCompetition(@Valid CompetitionForm form, BindingResult bindingResult) { if (bindingResult.hasErrors()) { // 返回第一个校验错误信息 return "redirect:/competition/add?error=" + bindingResult.getAllErrors().get(0).getDefaultMessage(); } competitionService.save(form); return "redirect:/competition/list"; }

@FutureOrPresent确保开始日期不能是过去，@Min(0)确保人数上限非负。这些注解比手写 if-else 更简洁，也更容易在答辩时讲清楚“声明式校验”和“编程式校验”的区别。

5.4 一个我反复踩过的坑：异步日志的事务问题

CompletableFuture.runAsync默认使用 ForkJoinPool 的公共线程池，这个线程池里的线程没有 Spring 事务上下文。如果opLogMapper.insert本身需要事务（比如涉及多表写入），异步执行会失败。我的做法是给日志表设计成单表插入，不需要事务，这样异步写入最安全。如果确实需要事务，把runAsync换成注入一个自定义的ThreadPoolTaskExecutor，并在异步方法上加@Transactional，但这样复杂度会上升，毕设场景不建议。

另外，异步写入意味着日志可能延迟几毫秒才出现在数据库里。答辩演示时如果老师刚操作完就刷新日志页面，可能看不到最新记录。我的习惯是在演示前先手动触发几次操作，让日志数据先积累一些，避免现场尴尬。这个习惯帮我省过好几次后悔药。

希望帮到你。

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