SpringBoot社团活动平台毕设实战：从需求拆解到并发控制

1. 这类系统真正的门槛在需求拆解：先把“角色—社团—活动”的关系理清

很多同学看到“基于SpringBoot的大学生社团活动平台”这个题目，第一反应是：这不就是一套增删改查吗？用户表、社团表、活动表，再来个报名表，页面能点能查，论文能截图能贴代码，任务就完成了。我带过不少做这类题目的毕业生，真实的感受是：抱着这种想法开工的人，往往到中期就会卡住。卡住的原因不是 Spring Boot 学不会，而是最初没把业务需求拆透，代码越写越乱，活动状态、审批关系、角色边界全搅在一起，最后自己都不知道某条数据从哪来、该往哪去。

这个题目其实非常适合作为毕设，因为它不算难，但又有足够的业务深度去体现“设计”两个字。一个高校里的社团活动平台，要处理的不是简单的信息发布，而是“学生申请入社—社长审核—发布活动—成员报名—活动状态流转—数据统计”这样一条完整链路。链条上有普通学生、社团负责人、系统管理员等不同身份，有“待审核、已通过、已拒绝、已结束”等不同状态，还有并发报名、重复提交、权限越界这类真实问题。把这些理顺了，再去看 Spring Boot 里的接口、事务、安全框架，才知道每一处配置都是为了回答什么问题。

1.1 平台要解决的真实问题：大学生组织活动时最痛的点在哪里

要理解这个系统为什么值得做，先看看没有系统的情况下，一个高校社团是怎么运作的。纳新时靠扫楼、发报名表，活动报名靠微信群接龙，天气有变就在群里反复通知，活动结束后想看看这个学期办了几场活动、来了多少人，负责人得翻聊天记录。这种模式对小社团能运转，但学校一旦有几十个社团，团委或社联要统一管理，就完全失控了。

所以，这个平台的核心价值并不是“把线下登记搬到线上”，而是把分散的信息收拢成结构化数据，让每个人在合适的时间看到合适的内容。普通学生能浏览全校社团和活动，在线提交入社申请、报名活动；社团负责人能维护本社团资料、发布活动、审批入社申请；系统管理员能审核社团成立申请、查看活动数据、处理违规内容。一个平台把这三类人的诉求串起来，才叫校园信息化应用。做毕设时，如果把大量精力花在花哨的页面上，却没有把这条主链路走通，答辩时很容易被问住。

另外要记住一点，需求不是模块越多越好。很多同学一上来就想着加二手交易、匿名树洞、失物招领，最后做成了一个大杂烩。一个毕设题目的评分重点，通常在于“核心业务是否闭环、设计是否有依据、技术点是否落地”。把社团和活动这条线做到闭环，比堆十个无关页面更有说服力。

1.2 角色与业务状态是最先要定下来的两张“隐形表”

我建议在打开 IDE 建工程之前，先在一张纸上画出两种关系。第一种是角色关系：用户和社团之间到底是什么关系？一个人可以加入多个社团，一个社团有多名成员，成员在社团内还有不同职务，比如社长、副社长、干事、普通成员。这个关系不是简单的一张 user 表加一个 club_id 就能表达的，因为一个用户可能会属于多个社团，如果硬把社团编号塞进用户表，换社团或者退出社团时历史数据就丢了。

第二种是业务状态关系。一条入社申请，初始是待审核，社长通过后变成已加入，拒绝后变成已拒绝。一条活动记录，从创建到结束，至少要经历草稿、招募中、进行中、已结束、已取消这几个阶段。还有报名记录，报名后可能取消报名，活动结束后还可能签到。如果这些状态不提前定义清楚，等代码写一半再改，需要动的地方就不只是某个字段，而是所有相关查询逻辑。

这一步就是评审老师常说的“需求分析”和“总体设计”。写论文时同样要把这两块放在前面讲，用文字说明清楚角色矩阵、状态流转、模块边界。把状态设计好了，后面建表、写接口、画页面都会顺利很多。

2. 技术选型与工程骨架：版本怎么定、包结构怎么拆

Spring Boot 这个技术栈本身没有太多悬念，但“用哪个版本、搭什么结构”却经常成为毕设翻车的第一站。我见过有同学在官网新建项目时默认选了最新版本，结果拉到本地 JDK 版本不够，又去查各种升级资料，浪费了整整一周。所以这里值得仔细说说。

2.1 Spring Boot 版本不是越新越好：2.7.18 和 3.x 怎么选

如果你是为了稳妥完成毕设，我的建议是优先选择 Spring Boot 2.7.18。原因非常简单：它对应的 Java 版本要求是 8 或 11，兼容性最好，市面上绝大多数教程、博客、毕设源码都基于这个版本线。很多第三方工具和 starter，比如老牌的 Swagger 集成、某些视频教程里的代码，都还停留在 Boot 2.x 时代。你选 2.7.18，遇到问题搜资料时不会一头雾水。

Spring Boot 3.x 本身当然更好，但它强制要求 Java 17，并且部分第三方库还没有跟上。比如 Springfox 的 Swagger 集成，在 Spring Boot 2.6 之后就已经因为路径匹配策略变化出现过兼容问题，到了 Boot 3 上基本不能直接用，得换成 springdoc-openapi。如果你对这套生态差异不熟悉，单单“接口文档出不来”这个问题就能耗掉好几天。翻译成白话就是：毕业设计不是公司生产环境，没有必要追最新版本。把核心业务做扎实、把原理讲清楚，比“我用了最新版”重要得多。

依赖选择上，建议参考这套组合：

这套组合的思路是：持久层用 MyBatis-Plus 而不是 JPA，因为它更容易理解 SQL、分页方便，调试时能直接看到具体执行的语句。安全层用 Spring Security 而不是手写拦截器，虽然配置麻烦一点，但这是企业主流方案，论文里和面试时都有说头。

2.2 单模块 Maven 的分层结构，以及 application.yml 里的几个关键点

工程结构方面，普通毕设项目不需要搞微服务，也不需要强行拆成 Maven 多模块。一个单体 Spring Boot 工程，按功能分层就足够了。我在实际带项目时常用的包结构是：

code复制com.example.club
├── config          // 配置类：Security、MyBatis-Plus、Cors
├── controller      // 对外接口层
├── service         // 业务逻辑层
├── mapper          // 数据访问层
├── entity          // 数据库实体
├── dto             // 接收前端参数的传输对象
├── vo              // 返回给前端的视图对象
├── common          // 统一返回结果、异常、常量
└── utils           // JWT工具、日期工具等

统一返回结果类必须提前写好。我通常定义一个 Result<T>，里面有 code、message、data 三个字段，接口成功失败都用它包一层。这样前端可以通过 code 是否为 0 来判断请求是否成功，后端异常也能通过全局异常处理器统一转换，不会把堆栈信息直接暴露给浏览器。

配置文件这里也提醒一句：不要把所有环境混在一个 application.yml 里。尽量拆成 application.yml、application-dev.yml、application-prod.yml，主配置文件只指定激活哪个 profile。本地开发时用 dev，里面连本地数据库；部署演示时用 prod，里面放服务器上数据库的地址，这样切换环境只改一行配置。很多初学者把所有配置塞一个文件里，数据库密码、文件上传路径一换就到处漏。

下面是我经常用的核心配置模板，可以直接参考：

yaml复制server:
  port: 8080

spring:
  profiles:
    active: dev
  jackson:
    date-format: yyyy-MM-dd HH:mm:ss
    time-zone: GMT+8
  servlet:
    multipart:
      max-file-size: 20MB
      max-request-size: 100MB

mybatis-plus:
  configuration:
    map-underscore-to-camel-case: true
  global-config:
    db-config:
      id-type: auto
      logic-delete-field: deleted
      logic-delete-value: 1
      logic-not-delete-value: 0

这段配置里，jackson 的日期格式很关键。Spring Boot 默认序列化 LocalDateTime 时输出的是 ISO 格式，前端拿到后要额外转换；直接配成 yyyy-MM-dd HH:mm:ss 能省掉很多联调麻烦。logic-delete 是 MyBatis-Plus 的逻辑删除开关，加上之后所有删除操作都变成 update deleted = 1，能保留历史数据。这个小配置对“报名记录不能随便物理删除”这类需求尤其有用。

再说一个轻松的小知识点：Spring Boot 启动时默认显示那个 Spring 图案，如果你想换成自己项目的名字，只要在 resources 目录下放一个 banner.txt，启动时就会自动加载。网上有不少在线生成器可以帮你把字符转成 ASCII Art，或者直接用 IDEA、AI 工具生成一段个性化图案。毕业设计录演示视频时，个性化 banner 能增加一点完成度，但不影响功能性，写到论文里反而多余，自己知道就行。

3. 数据表设计：12 张核心表串起整个平台，字段取舍才是见功底的地方

数据库设计是“大学生社团活动平台”里最容易出彩、也最容易出丑的部分。很多同学为了显得系统复杂，一口气设计二三十张表，结果一半表根本没人用。我见过最夸张的一份毕设代码，登录都要关联六七张表，解释不清为什么，最后答辩时老师问“这张表存在的意义是什么”，直接冷场。所以，表数量控制在必要范围内就够了，核心是把关系设计清楚。

3.1 按“域”来组织表，而不是按页面堆表

我建议把表拆成四个域：用户域、社团域、活动域、辅助域。按照这个思路，12 张表就能覆盖完整业务。

细心的读者会发现，我没有单独建一张角色表，而是在 sys_user 表中加了一个 role 字段，用整数区分普通用户和管理员。为什么不建标准的三张权限表？因为业务场景很简单，用户的全局角色只有两种。如果有人需要在社团内部做细粒度权限，那是另一个问题，应该靠 club_member 里的 club_role 字段去解决，而不是把 RBAC 那套完整搬过来。设计数据库时，最需要警惕的就是“用一把牛刀杀鸡”，复杂性增加不等于设计优秀。

3.2 两张容易设计错的关联表：club_member 和 activity_registration

club_member 是整个社团关系的核心。一个人可以加入多个社团，社团里有多种职务，这些信息不能放在 sys_user 上，而是要单独用关系表保存。典型的建表语句如下：

sql复制CREATE TABLE club_member (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  user_id BIGINT NOT NULL COMMENT '用户ID',
  club_id BIGINT NOT NULL COMMENT '社团ID',
  club_role TINYINT NOT NULL DEFAULT 0 COMMENT '0普通成员 1干事 2社长 3副社长',
  status TINYINT NOT NULL DEFAULT 1 COMMENT '1正常 0已退出',
  join_time DATETIME DEFAULT NULL COMMENT '加入时间',
  deleted TINYINT DEFAULT 0 COMMENT '逻辑删除',
  UNIQUE KEY uk_user_club (user_id, club_id)
) COMMENT '社团成员关系表';

这里的唯一约束 uk_user_club 很重要。如果没有它，程序里再小心，也可能因为并发请求导致同一个人重复加入同一个社团。数据库层面的唯一约束，是防止脏数据的最后一道防线。类似的，活动报名表也要加上 UNIQUE KEY uk_user_activity (user_id, activity_id)，防止同一个人对同一个活动重复报名。

很多同学会忽略一个设计细节：退出社团时应该物理删除行记录，还是把 status 改成退出？我的建议是后者。因为一个用户退出社团后，他曾经在社团期间发布过活动、参与过统计，这些历史数据是有价值的。如果直接删除成员关系，关联查询会断掉，统计数据也会不准。所以状态更新比删除操作更合理。

activity_registration 这张报名表也需要认真考虑。报名不只是 insert 一条记录那么简单，它还牵扯到活动人数上限。关于这个问题，我会在下一章展开说，但表设计阶段就要明确一点：报名表里不但要有 activity_id、user_id、报名时间，还要有 status 字段，因为用户可能取消报名，取消后不能简单删除记录，否则无法追溯“谁曾经报过名、后来取消了”这个信息。如果你的活动还要做签到，那么报名表或者单独的签到表里应保存签到状态，设计时提前留好扩展余地。

4. 关键业务实现：从权限控制到活动报名的并发问题

这个部分是整个项目真正的“实现”核心，也是答辩时最容易拉开差距的地方。CRUD 谁都会写，但权限设计、并发处理、事务边界这些点，才是体现“设计”的关键。

4.1 用户权限设计：全局角色与社团内的职务要分开看待

Spring Boot 项目里做登录认证，最常用的方案是 Spring Security + JWT。JWT 的作用是让服务器不需要保存登录状态。用户登录成功后，后端生成一个带过期时间的令牌返回给前端，前端把它存在本地，每次请求时放到 Authorization 请求头里；后端写一个过滤器，从请求头取出令牌、校验签名、解析出用户信息，再放到 SecurityContext 中，后续接口就能直接获取当前用户。

Spring Security 的过滤链配置里，最让人困惑的是“哪些接口不需要登录”。一般的规则是：登录接口、注册接口、接口文档、静态资源可以放行，其余接口必须经过认证。代码可以这样写：

java复制http.csrf().disable()
    .sessionManagement()
    .sessionCreationPolicy(SessionCreationPolicy.STATELESS)
    .and()
    .authorizeRequests()
    .antMatchers("/api/auth/login", "/api/auth/register").permitAll()
    .antMatchers("/doc.html", "/swagger-ui/**", "/v3/api-docs/**", "/webjars/**", "/favicon.ico").permitAll()
    .anyRequest().authenticated();

这里特别要注意，接口文档地址一定要放行，否则你用 Swagger 在线调试时会发现所有接口都报 401 或者 403，但你又没看到拦截逻辑，非常困惑。很多同学用 Swagger 习惯不好，每个请求都要手动粘贴 token，实际工作中通常会把文档地址加到白名单里，方便前后端联调。“springboot jwt 放开 swagger”这个搜索话题背后的场景，多半就是这里出了问题。

再往深一层说，权限控制不只停留在“是否登录”，还要区分“谁有操作权”。比如社长可以审核入社申请、修改社团资料，普通成员只能查看。全局的 admin 可以查看所有社团数据，但不能随意修改其他人的密码。这些判断逻辑不能全塞到 Controller 里，写多了会非常乱。我的建议是：能用注解控制的用注解，比如管理端接口统一加 @PreAuthorize("hasRole('ADMIN')")，涉及特定资源归属权的，在 Service 层里做校验，比如先查出社团的 ownerId 再看当前登录用户是不是社长。安全框架只解决“你是谁”，业务层还要解决“你是否有权操作这条数据”，两层结合才算完整。

4.2 活动报名的并发问题：先扣减再写流水，而不是查了再写

活动报名是这类系统里最值得拿出来讲的功能。需求听起来很简单：用户点报名，系统判断活动人有没有满，没满就插入一条报名记录。很多人按直觉写出这样的流程：先查 current_count，如果小于 max_count，就 insert，然后把 current_count 加一。功能上没问题，但仔细推敲会发现，这个逻辑在并发情况下是错的。

假设活动限额 10 人，现在已经有 9 人报名。第 10 个和第 11 个用户同时点击报名，两个请求都查到了 current_count = 9，都认为名额还没满，然后都执行了插入和更新。结果就是报名记录插入了两条，活动实际报名人数变成 11，超出了上限。这就是典型的“先查再写”导致的超卖问题。

解决思路也很直接：不要在应用层判断人数，而是让数据库帮忙原子地完成扣减。可以把活动表里的 current_count 当作一个计数器，每次报名都执行下面的更新语句：

sql复制UPDATE activity
SET current_count = current_count + 1
WHERE id = #{activityId}
  AND current_count < max_count

这条 SQL 是原子操作，数据库的行锁会保证同一时刻只有一个事务能更新这行数据。执行后判断受影响行数，如果为 0，说明活动已经满员或者活动不存在，直接抛出“活动已满”异常；如果为 1，再插入报名记录。整个流程加上事务注解，就能保证“扣减名额”和“写入报名流水”要么都成功，要么都失败。

对应的 Service 层代码逻辑大致是：

java复制@Transactional(rollbackFor = Exception.class)
public void signUp(Long activityId, Long userId) {
    int updated = activityMapper.increaseCurrentCount(activityId);
    if (updated == 0) {
        throw new BusinessException("活动已满员或已截止报名");
    }
    ActivityRegistration registration = new ActivityRegistration();
    registration.setActivityId(activityId);
    registration.setUserId(userId);
    registration.setStatus(1);
    registrationMapper.insert(registration);
}

这里有个注意事项：为什么不在插入报名记录之后再去更新活动人数？因为插入时无法判断这个活动是否已经满员，只有先做原子扣减、锁定名额，再写报名流水，语义才正确。代码顺序不能颠倒。这个场景虽然简单，但能把“为什么 SQL 写法有讲究”说得很清楚，我在带学生时经常用它当例子。论文里如果能把这个并发问题单独写成一个小节，展示从“普通写法”到“原子更新”的演进，会让设计思路显得非常扎实。

4.3 审批状态机：不要一上来就引入 flowable 之类的流程引擎

社团成立要审批、入社申请要审批、活动发布可能要审批，这些“审批”需求让不少同学兴奋起来，想着是不是应该引入 flowable、Activiti 这类工作流引擎。我的建议是：毕设场景不要用。大学生社团管理毕竟不是企业级 OA，审批链条短、节点少，用数据库里一个 status 字段配合更新时间就能表达清楚，引入流程引擎反而增加学习成本、部署复杂度和答辩风险。评委追问“为什么不用状态机、为什么活动状态和审批状态要分开存”，你会很难答。

真正值得做的是把状态定义清楚，并用枚举管理。例如活动状态可以设计为：

写代码时不要到处用魔法数字，建议定义一个枚举类，比如 ActivityStatusEnum，把状态码和描述对应起来。尤其是从“报名中”切换到“已截止”这个环节，很多同学都忘了处理：活动人数没满，但报名截止时间已经到了，系统必须提供一个检查机制把状态更新为已截止。实现方式可以是在每次查询活动时动态判断，也可以写一个定时任务每隔几分钟扫描。

我倾向于查询时动态判断：在活动列表 SQL 里，用 CASE WHEN 把 current_count、max_count、报名截止时间和当前时间综合计算成展示状态，或者在后端服务层做状态映射。这样不会出现“活动已经过了报名时间，但前端还能报名”这种低级错误。数据库里状态字段保留原始状态，展示时按实际情况修正，思路更清晰。

5. 前后端联调最容易翻车的几个点：跨域、版本、日期格式

做毕设时很多人习惯先把后端写完，用 Postman 测完接口，再开始写前端页面。单测接口时一切正常，当前后端真正联调时，问题就成串地冒出来。这些坑不是技术难点，但解决起来特别消耗耐心。这一章挑几个最常见的说，希望能帮你提前绕开。

5.1 跨域请求和 401：前后端分离的第一道坎

前端跑在 8081 端口，后端跑在 8080 端口。前端页面发请求访问 http://localhost:8080/api/xxx 时，浏览器会认为这是跨域请求。如果后端没有配置允许跨域，浏览器会直接拦截响应，控制台报 red error，同时网络请求里能看到一个预检请求 OPTIONS。

Spring Boot 里解决跨域通常有两种做法。最简单的是在 Controller 或接口上使用 @CrossOrigin，但接口多了之后每个方法都加注解非常啰嗦。我倾向于写一个全局配置类，统一配置允许的跨域来源、请求头和方法：

java复制@Configuration
public class CorsConfig implements WebMvcConfigurer {
    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/**")
                .allowedOriginPatterns("*")
                .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS")
                .allowedHeaders("*")
                .allowCredentials(true)
                .maxAge(3600);
    }
}

如果你用了 Spring Security，光配这个还不够，因为安全过滤器链是优先于 Spring MVC 的。浏览器发送 OPTIONS 预检请求时通常不会携带 Authorization 头，如果 Security 配置把所有请求都拦截成认证请求，就会导致跨域配置没生效、接口返回 401。处理方法是让 OPTIONS 请求直接放行，或者在 Security 配置里启用 CORS：

java复制http.cors().and().csrf().disable();

这里还要提醒一句：不要把“跨域”和“接口 401”混淆。跨域报错往往是 CORS error，接口返回 401 是你的令牌没通过验证。遇到问题时先把网络请求面板打开，看响应状态码，再判断是浏览器拦截还是服务器拒绝。

5.2 Spring Boot 3 的“版本太高”陷阱与 Swagger 兼容

每年做毕设时都会有人遇到一个奇怪的现象：跟着博客引入 Swagger 依赖后，项目启动失败，控制台报错。原因基本都出在版本匹配上。老牌的 springfox 从 3.0.0 之后就不再积极维护，Spring Boot 2.6 修改了路径匹配策略后，直接使用 springfox 就可能报空指针异常。

如果你选择 Spring Boot 2.7.x，临时解决办法是加一行配置：

yaml复制spring:
  mvc:
    pathmatch:
      matching-strategy: ant_path_matcher

但更推荐的方式是直接换成 springdoc-openapi，它天然兼容 Spring Boot 2.x 和 3.x，并且生成的接口文档比 springfox 更规范。如果你是 Spring Boot 3.x，或者本来就是从官网生成的 3.2 以上版本，不要费劲去解决 springfox 兼容问题，直接选择 springdoc 更省时间。

这个坑给我最大的体会是：引入第三方依赖之前，一定要先确认它和当前 Spring Boot 版本的兼容性，不要只看依赖名字就复制粘贴。大部分“springboot版本太高导致依赖不能用”的问题，成因都在这里。建议在项目一开始就把接口文档工具选定，不要等到代码写差不多了再补，否则排查范围会遍布所有配置。

5.3 时间字段和 JSON 序列化：前端看到 2026-03-01T00:00:00 也算问题

Java 8 之后，时间字段通常用 LocalDate、LocalDateTime。Spring Boot 默认使用 Jackson 序列化这些类型时，可能会输出类似 2026-03-01T10:30:00 的 ISO 字符串，甚至默认配置不当时会输出成一个数组，比如 [2026, 3, 1, 10, 30, 0]。前端拿到这种数据之后，如果直接 new Date(value)，很容易出现解析错误，导致页面上时间显示成 Invalid Date。

解决办法就是在第一节提到的全局配置里设置日期格式：

yaml复制spring:
  jackson:
    date-format: yyyy-MM-dd HH:mm:ss
    time-zone: GMT+8

同时给实体类的时间字段加上注解，双重保险：

java复制@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss", timezone = "GMT+8")
private LocalDateTime createTime;

这里比较隐蔽的点在于时区。如果没有设置 time-zone，服务器时间和数据库时间的时区不一致，可能导致存储和读取相差 8 小时。这个问题在开发时往往发现不了，因为本机时区就是东八区，但部署到云服务器时可能就出问题。配置里把时间统一为 GMT+8，数据库连接串里也顺手加上 serverTimezone=Asia/Shanghai，能省掉后续非常多的排查成本。时间处理是毕设项目里最常见的低级错误，但也是最能显示你是否有工程经验的一个细节。

6. 论文里怎么写才显得“设计过”，以及答辩怎么准备

代码写完、系统能跑，只完成了一半。对毕设来说，论文和答辩同样是评分的重要部分。很多同学代码写得不错，论文却写成“功能说明书”，每章都是“点击这个按钮可以做什么”，读起来没有深度，自然拿不到高分。想写出“设计感”，需要在写作思路上调整。

6.1 “设计”章节怎么谋篇：除了用例图，还要有状态设计和权限矩阵

论文里的总体设计章节，至少要包含三个层面的内容：第一个层面是功能结构。把系统按用户端、社团管理端、系统管理端三个模块去拆分，每个模块下再列子功能，不要只是贴一张大而全的功能树。第二个层面是技术架构。画一张简单的分层图，把 Spring Boot 后端、前端、MySQL 数据库之间的关系画清楚，标明请求是怎么从前端到 Controller、Service、Mapper 再返回的。第三个层面才是数据库设计和接口设计。这里一定要强调你在关键业务上的设计决策。

比如活动报名并发处理，可以先描述常规做法“先查后写”的缺陷，再画一个流程图说明为什么改用“数据库原子更新”。又比如社团成员关系表，为什么不用一个字段直接挂在用户表上，而要设计成独立关联表，这些设计依据写出来，论文的“设计感”就出来了。

很多同学以为论文里的“核心代码”是越详细越好，于是把整段 Service 代码贴进去，一贴好几页。这种写法非常浪费篇幅。正确的做法是截取关键片段，比如原子更新的 SQL、JWT 过滤器的核心逻辑，然后用文字说明这段代码解决了什么问题。评委看重的不是代码量，而是你对自己代码的理解程度。

6.2 答辩高频问题：安全、并发、为什么不用更“高级”的中间件

答辩时老师经常问这几个问题，提前准备会有很大帮助。

第一个高频问题是“为什么用 Spring Security，而不是自己写一个拦截器？”这个问题不能只回答“大家都这么用”，要说出 Spring Security 的不可替代性：它内置了密码加密工具、过滤链机制、会话管理，还提供了方法级权限注解，基于标准的安全模型来做认证与授权，比手写拦截器更规范、安全性更高。但你可以再补一句，如果你对安全框架掌握不深，系统简单时用拦截器也能实现，只是论文里技术含金量会低一截。

第二个高频问题是“你的系统能支撑多大并发？人数上限怎么控制？”这时就可以用上 4.2 节的内容。明确说明：通过数据库行锁或原子更新保证不会超卖，当前架构是单体应用，对于高校单个活动的报名规模是够用的。如果评委继续追问，可以说如果将来超过几百人的瞬时并发，可以再引入 Redis 的 Lua 脚本做库存扣减，用异步消息队列降低数据库压力，但当前阶段没必要。不要为了显得高级而主动说“我项目里用了 Redis 做缓存、用了 RocketMQ 做消息队列”，因为你一旦说了，评委就会追问缓存一致性、消息可靠投递这些细节，答不上来反而减分。

第三个高频问题是“为什么审批功能不用工作流引擎？”我建议回答：这里的审批链很短，只有提交和审核两个环节，用数据库状态字段即可表达，不需要流程引擎的完整能力；如果未来要支持多级审批、撤销、会签等复杂流程，再引入 flowable 才有价值。要把“技术选型要匹配业务复杂度”这个理念讲出来，这比单纯炫技更显成熟。

我自己在做类似系统时的一个体会是：答辩前不要背代码，而是要把“一条数据从页面输入到数据库落盘，中间经历了哪些校验、哪些权限判断、哪些状态变化”完整讲一遍。能把这个链路讲清楚，说明你是真的做过设计，而不只是复制粘贴了别人的工程。很多同学系统里还加了第三方登录、消息推送、数据大屏，但一问到最基础的报名流程反而讲不明白，这才是评分的大坑。