简介基于Spring Boot的高校社团管理系统设计与实现源码包面向毕业设计或课程作业场景适合需要完成社团管理类课题的高校学生及Java开发者。系统内含用户管理、社团创建与审批、活动发布与报名、通知公告、财务收支报表等典型模块并设置管理员、社团负责人、普通成员三级权限可支撑完整业务流程演示与二次开发。压缩包约27.85MB共812个文件核心包括199个Java源码、141个Vue前端组件、63个JavaScript脚本配合Spring Boot与Vue构成完整项目另有120张JPG图片、SQL数据库脚本、工程配置文件及bat启动命令便于理解架构、导入部署。目前已有90人学习下载同时随包提供毕业论文与答辩PPT适合用于课程设计、毕设答辩准备或系统开发练手。1. 高校社团管理系统为什么难点不在增删改查而在角色边界与状态流转一个社团管理系统从页面原型看就是社团表、成员表、活动表、报名表四张 CRUD很多人在开工前也这么想。但真正动手做基于 Spring Boot 的社团管理系统时你会发现被卡住的往往是另外几个地方一个学生同时是多个社团的成员也是某个社团的社长还可能是活动的审批人这套角色边界怎么表达活动报名有人数上限并发抢名额时怎么保证不超卖成员退社、换届、活动取消这些状态怎么流转才不会被答辩老师追问出漏洞。这篇文章从 Spring Boot 项目初始化、数据模型、核心接口、权限与审计一路做到论文配图面向两类读者正在做基于 Spring Boot 的 Java 毕设的学生以及想快速掌握一套可复用管理系统骨架的初级后端工程师。读完你可以拿到一套能跑的代码结构和一套能讲清楚的答辩话术。2. Spring Boot 3.x 项目初始化与分层架构从依赖到分包2.1 版本选型Spring Boot 3.2 与 JDK 17 的组合高校社团管理系统这种以业务建模为主的单体应用最合适的基线是 Spring Boot 3.2.x 配合 JDK 17。Spring Boot 3.0 之后强制要求 JDK 17这已经不是什么新话题但很多做毕设的同学还在 Idea 里装 JDK 8然后发现项目跑不起来。这里明确一下Spring Boot 3.x 技术栈下JDK 17 是基线JDK 21 也可以但没必要因为大多数高校机器和答辩环境跑的是 17。版本不要追最新。很多检索词里能看到springboot版本太高这种反馈指的是 Spring Boot 3.4 / 3.5 刚发布时对应的 spring-boot-starter-parent 和各种第三方 starter 的兼容还没跟上容易在 idea 创建 springboot 项目时出现依赖解析失败。我一般选择 3.2.x 的最后一个 patch 版本比如 3.2.5稳定、文档多、出问题容易搜到答案。如果你所在学校要求必须用 2.7.x这也是可行的只是 javax 包名和 Spring Security 配置方式有差异下面代码按 3.x 写。2.2 start.spring.io 超时时的替代初始化方式IDEA 自带创建 Spring Boot 项目的入口走的是 start.spring.io网络不稳定时经常卡在下载 spring-boot-starter-parent 这一步。出现这个问题不用反复重试直接手动改两个地方先创建一个空的 Maven 项目在 pom.xml 里写入下面的依赖再配置阿里云 Maven 镜像。parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version3.2.5/version relativePath/ /parent properties java.version17/java.version /properties dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-jpa/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-validation/artifactId /dependency dependency groupIdcom.mysql/groupId artifactIdmysql-connector-j/artifactId scoperuntime/scope /dependency dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId optionaltrue/optional /dependency /dependencies这段 pom 的核心逻辑是以 spring-boot-starter-parent 作为统一版本管理入口自己只声明需要的 starter不写具体版本号。starter-web 引入 Spring MVC 和内嵌 Tomcatstarter-data-jpa 引入 Hibernate 作为 ORM 实现validation 用于参数校验。mysql-connector-j 的 scope 是 runtime表示编译期不需要直接引用运行时会自动加载驱动。Lombok 用来消除 getter/setter 样板代码但注意如果你的 JDK 是 21需要确保 Lombok 版本不低于 1.18.30否则编译期会报错。Maven 镜像配置在用户目录的~/.m2/settings.xml中加入阿里云仓库后 idea 创建 springboot 项目超时的问题基本就不再出现了。这一整套下来项目能在一个干净的 Maven 环境里一键构建。2.3 一套适合论文写作的分层包结构包结构决定你后面画架构图、写论文系统设计章节时的表述成本。不建议用那种一个包放所有类的写法虽然项目小也能跑但答辩时讲不清层次关系。我推荐按模块分包而不是按技术层分包理由是业务聚合度更高改一个功能时涉及的文件都在相邻目录里。com.campus.club ├── ClubApplication.java ├── common │ ├── Result.java │ ├── BusinessException.java │ └── GlobalExceptionHandler.java ├── config │ ├── SecurityConfig.java │ └── WebMvcConfig.java ├── controller │ ├── AuthController.java │ ├── ClubController.java │ ├── ActivityController.java │ └── MemberController.java ├── service │ ├── ClubService.java │ ├── ActivityService.java │ └── impl │ ├── ClubServiceImpl.java │ └── ActivityServiceImpl.java ├── repository │ ├── ClubRepository.java │ ├── MemberRepository.java │ └── ActivityRepository.java ├── entity │ ├── Club.java │ ├── Student.java │ ├── Activity.java │ └── ClubMember.java ├── dto │ ├── CreateActivityRequest.java │ └── RegisterRequest.java └── enums ├── MemberRole.java ├── MemberStatus.java └── ActivityStatus.java这个分层的职责边界是controller 只负责参数接收和调用 service不写业务逻辑service 层处理事务、权限判断和状态流转repository 是 Spring Data JPA 的数据访问接口方法名即查询语义entity 是对应数据库表的 ORM 映射实体dto 是接口的入参和出参对象避免把实体直接暴露给前端。common 包放统一返回体和全局异常处理config 包放安全配置。这里有一个常见的坏味道很多人图省事在 controller 里直接操作 repository。这在功能演示时没问题但一旦涉及事务和权限就会出问题。service 层至少要处理两件事事务边界用Transactional标注权限断言写在 service 方法的第一行。后面第 5 章会专门展开权限这部分。3. 核心数据模型ER 设计、状态字段与 JPA/Hibernate 映射3.1 从社团业务推导实体关系高校社团管理系统最核心的业务规则可以归纳成三句话一个学生可以加入多个社团一个社团有多个成员一个社团可以发布多个活动一个活动报名表里有多条报名记录成员在社团里有身份角色包括社长、副社长、普通成员身份可以变更。这三句话直接决定了 ER 图的形状。实体关键字段关联关系studentid, student_no, name, password, email与 club 多对多通过 club_member 中间表clubid, name, category, description, leader_id与 student 多对多activityid, club_id, title, max_people, status与 club 多对一与 student 一对多club_memberid, student_id, club_id, role, status, joined_at关联 student 与 club冗余角色字段activity_registrationid, activity_id, student_id, status, created_at关联 activity 与 student加唯一约束注意 club_member 这个中间表不能省。很多第一次做管理系统的人直接用ManyToMany让 JPA 自动生成关联表表面上省事后面活动报名、社长换届、成员审核这几个功能全部需要中间表上的额外字段比如角色、入社时间、状态等。用ManyToMany表达不了这些字段届时再改表结构会非常痛苦。另外activity_registration 表上要加一个unique(activity_id, student_id)的联合唯一索引这是防重复报名在数据库层面的兜底。后面接口层的并发控制只是第一道防线数据库约束才是最后一道两层都要有。3.2 表结构 DDL 与关键索引设计下面是一份可以直接执行的 MySQL 建表脚本设计上考虑了三个点字符集统一 utf8mb4、时间字段用 datetime 且由应用层写入、冗余字段控制在合理范围内。CREATE TABLE club ( id BIGINT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(64) NOT NULL, category VARCHAR(32) NOT NULL, description VARCHAR(512), leader_id BIGINT, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, KEY idx_category (category) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE club_member ( id BIGINT PRIMARY KEY AUTO_INCREMENT, student_id BIGINT NOT NULL, club_id BIGINT NOT NULL, role TINYINT NOT NULL DEFAULT 3 COMMENT 1:社长 2:副社长 3:成员, status TINYINT NOT NULL DEFAULT 0 COMMENT 0:待审核 1:已通过 2:已退社, joined_at DATETIME, UNIQUE KEY uk_student_club (student_id, club_id), KEY idx_club_status (club_id, status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE activity ( id BIGINT PRIMARY KEY AUTO_INCREMENT, club_id BIGINT NOT NULL, title VARCHAR(128) NOT NULL, location VARCHAR(128), start_time DATETIME NOT NULL, max_people INT NOT NULL DEFAULT 50, status TINYINT NOT NULL DEFAULT 0 COMMENT 0:报名中 1:已截止 2:已结束 3:已取消, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, KEY idx_club_id (club_id), KEY idx_status (status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE activity_registration ( id BIGINT PRIMARY KEY AUTO_INCREMENT, activity_id BIGINT NOT NULL, student_id BIGINT NOT NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT 0:已报名 1:已签到 2:已取消, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_activity_student (activity_id, student_id), KEY idx_student (student_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这份 DDL 里值得注意的设计决策是role 和 status 都用 TINYINT 数字表示而不是字符串。这么做的好处是存储和索引效率更高JPA 里可以用Enumerated(EnumType.ORDINAL)直接映射枚举类型写起来很顺手。坏处是可读性差所以一定要在 COMMENT 里写清楚每个数字的含义后面做 PPT 里的数据字典直接抄这一列。club_member表上的联合唯一索引uk_student_club是关键约束。它保证了同一对 student_id 和 club_id 只能有一条记录那么加入一个社团两次这类问题在数据库层面被直接禁止。activity_registration表的联合唯一索引同理保证一人对同一活动只能有一条报名记录。3.3 用 JPA 映射关联关系时的两个容易踩的坑Spring Boot 集成 JPA 写实体类时最容易出问题的两个地方是懒加载序列化异常和级联操作误删数据。懒加载异常的表现是在 controller 里直接返回一个包含ListActivity的 Club 实体Jackson 序列化时触发对 activities 属性的访问而此时 Session 已经关闭抛出LazyInitializationException。解决的常规办法有两个第一是在 service 层把实体转换为 dto 再返回第二是在实体关联的 getter 上标注JsonIgnore或JsonProperty(access Access.WRITE_ONLY)。我的建议是以 dto 为准因为论文的系统设计章节里你可以写控制层不直接暴露实体而是通过 DTO 层做数据视图隔离这句话在答辩时是加分项。级联操作的问题是在 Club 实体的成员集合上写了cascade CascadeType.REMOVE然后在删除社团时发现报外键约束错误。因为 JPA 会先删子表数据再删主表但如果某条 club_member 记录同时被其他逻辑引用删除顺序就会冲突。我的经验是关联关系一律不加级联删除删除社团前手动检查该社团下是否有未结束的活动和有效成员有就拒绝删除返回业务提示。这比数据库层的 ON DELETE CASCADE 更安全也更符合社团管理的真实业务逻辑。JPA 实体与 MySQL 表字段的命名映射建议显式配置spring.jpa.hibernate.naming.physical-strategyorg.hibernate.boot.model.naming.CamelCaseToUnderscoresNamingStrategy这样 Java 里的 camelCase 属性会自动映射到数据库的 snake_case 列省去大量Column(name ...)注解。如果你在 application.yml 里把ddl-auto设为 updateHibernate 会自动补列但你会发现很多列类型和你预期的不一样比如 TINYINT 可能被映射成 BIT所以生产思路是以 SQL 脚本为准JPA 的 ddl-auto 只用于开发环境。4. 活动报名与成员流转的核心接口实现4.1 活动报名接口的并发控制条件更新与唯一约束兜底活动报名是最典型的写操作接口业务规则是活动状态必须是报名中当前报名人数小于 max_people同一学生不能重复报名。第一个想到的写法是先查再插这在高并发下必然出问题两个请求同时查到人数为 49都判断可以报名然后都执行 insert最终报名人数变成 51。修正的思路是不依赖先查再判而是用数据库条件更新作为原子操作代码如下。Transactional public ResultVoid register(RegisterRequest request) { Activity activity activityRepository.findById(request.getActivityId()) .orElseThrow(() - new BusinessException(活动不存在)); if (activity.getStatus() ! ActivityStatus.OPEN) { throw new BusinessException(活动不在报名时间内); } // 条件更新仅当报名人数小于上限时才更新成功 int updated activityRepository.increaseRegisteredCount( activity.getId(), activity.getMaxPeople()); if (updated 0) { throw new BusinessException(该活动名额已满); } ActivityRegistration registration new ActivityRegistration(); registration.setActivityId(activity.getId()); registration.setStudentId(request.getStudentId()); registration.setStatus(RegistrationStatus.REGISTERED); registrationRepository.save(registration); return Result.success(); }这段代码的关键在increaseRegisteredCount这个自定义 SQL 上对应 repository 的方法如下。public interface ActivityRepository extends JpaRepositoryActivity, Long { Modifying Query(UPDATE Activity a SET a.registeredCount a.registeredCount 1 WHERE a.id :id AND a.registeredCount :maxPeople) int increaseRegisteredCount(Param(id) Long id, Param(maxPeople) Integer maxPeople); }Modifying标注这个查询是更新语句JPA 在执行后会自动清理持久化上下文缓存避免读到旧值。返回值 updated 是受影响的行数如果为 0说明更新条件未满足也就是人数已满。这个方案把检查余额和扣减余额合并成一条原子 SQL不需要分布式锁在对单库单表的毕设场景下是最高效的解法。这里有一个额外的细节需要处理如果registrationRepository.save(registration)这一行抛出了唯一约束冲突异常事务会回滚increaseRegisteredCount的更新也会一并回滚所以不会出现人数加了但报名记录没插入的数据不一致。很多人在这一步担心事务失效JPA 的Transactional对 RuntimeException 默认回滚唯一约束异常属于 DataIntegrityViolationException在回滚范围内所以只要不手写 try/catch 吞掉异常逻辑就是安全的。4.2 成员加入与退社的状态流转设计成员状态比活动报名更容易被忽略因为它是一个跨学期的长期状态。我的设计是 club_member 表中 status 字段用四个值表达完整生命周期0 表示待审核1 表示已通过2 表示已退社3 表示已拒绝。注意我没有设计被移除这个状态因为退社和移除在业务效果上是一样的区分它们没有实际意义反而会让状态机更复杂。public enum MemberStatus { PENDING(0, 待审核), APPROVED(1, 已通过), QUIT(2, 已退社), REJECTED(3, 已拒绝); private final int code; private final String desc; MemberStatus(int code, String desc) { this.code code; this.desc desc; } public int getCode() { return code; } }状态流转的约束规则是PENDING 可以转换为 APPROVED 或 REJECTEDAPPROVED 可以转换为 QUITQUIT 和 REJECTED 是终态不能再转换。规则要写在 service 层而不是前端页面隐藏按钮。原因是前端的按钮可见性只是交互设计后端必须有能力拒绝非法状态变更请求。社长审批入社申请的接口逻辑如下。Transactional public ResultVoid approveJoin(Long memberId, boolean approved) { ClubMember member clubMemberRepository.findById(memberId) .orElseThrow(() - new BusinessException(申请记录不存在)); if (member.getStatus() ! MemberStatus.PENDING) { throw new BusinessException(该申请已处理请勿重复操作); } member.setStatus(approved ? MemberStatus.APPROVED : MemberStatus.REJECTED); if (approved) { member.setJoinedAt(LocalDateTime.now()); } clubMemberRepository.save(member); return Result.success(); }这里的核心是状态判断前置。无论前端页面怎么操作后端在更新前先断言当前状态是 PENDING不是就直接拒绝。这就是状态机的意义让非法路径在代码层面不可达。如果你用的是 MyBatis Plus状态字段的判断逻辑一样只是把 save 换成 updateById。4.3 统一返回体与全局异常处理写接口时如果没有统一返回体每个方法的返回值类型可能都不一样前端对接时每个接口都要单独适配而且全局异常处理器也无法返回一致的错误结构。我习惯在项目第一行代码之前就写好 Result 类。Data public class ResultT { private int code; private String message; private T data; public static T ResultT success(T data) { ResultT result new Result(); result.setCode(200); result.setMessage(success); result.setData(data); return result; } public static T ResultT error(String message) { ResultT result new Result(); result.setCode(500); result.setMessage(message); return result; } }配合RestControllerAdvice捕获 BusinessException 和 MethodArgumentNotValidException可以把业务异常和参数校验异常统一转换成 Result 结构返回。这么做带来的直接好处是controller 层方法体变得非常干净只有参数接收、service 调用、返回 Result 三行代码论文里写系统采用统一响应模型所有接口返回标准格式这句话就有了具体的代码佐证。这里还要提一个容易被问倒的点HTTP 状态码和业务 code 到底该不该一致。我采用的方式是 HTTP 状态码始终返回 200业务状态由 code 字段表达。理由是对于前后端分离的项目前端拦截器只需要判断 code 200 即可统一处理不用每个接口分别处理 400、500、502 等不同异常。这个设计在答辩中被问到的概率很高你要准备好解释为什么不用 HTTP 状态码表达业务错误答案就是降低前端分支处理复杂度。5. 基于角色的权限控制与操作审计从拦截器到注解5.1 为什么先拦截器后 Spring Security基于 Spring Boot 的管理系统权限控制业界有两个路线集成 Spring Security 全家桶或者自己写拦截器加注解。对于高校社团管理系统这个规模我建议先自定义注解加拦截器原因有两点第一Spring Security 的过滤链和认证机制学习成本高你将大量时间花在理解框架源码上而不是业务本身第二毕设答辩时老师追问 Spring Security 的过滤器链顺序、Session 策略、CSRF 保护答不上来反而减分。而自己实现的注解式权限控制讲起来非常直白我是怎么设计注解的、拦截器怎么解析、未授权时返回什么每一步都清晰。5.2 自定义 RequireRole 注解与拦截器实现权限模型使用 RBAC 的简化版本用户属于社团成员在社团中拥有角色角色拥有操作权限。当社长审批入社、发布活动、修改社团信息时接口需要校验操作者在该社团中的角色是否为社长或副社长。实现方式是定义一个注解标注在需要权限校验的 controller 方法上。Target(ElementType.METHOD) Retention(RetentionPolicy.RUNTIME) public interface RequireRole { MemberRole[] value() default {}; // 允许通过的角色 long clubIdParamIndex() default 0; // clubId 在方法参数中的下标 }拦截器的工作流程是从请求头中解析出当前登录学生的 ID通过 club_member 表查出该学生在目标社团中的角色与注解要求的角色集合比对不匹配则抛出权限异常。核心代码如下。Component public class RoleInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { if (!(handler instanceof HandlerMethod handlerMethod)) { return true; } RequireRole requireRole handlerMethod.getMethodAnnotation(RequireRole.class); if (requireRole null) { return true; } Long studentId getCurrentStudentId(request); Long clubId parseClubId(request); MemberRole role clubMemberRepository.findRoleByStudentAndClub(studentId, clubId); if (role null || !Arrays.asList(requireRole.value()).contains(role)) { throw new BusinessException(无权执行该操作); } return true; } }拦截器从 request 中解析 clubId 有两种方式路径变量或请求参数。建议统一放在路径里例如/api/club/{clubId}/member/{memberId}/approve这样拦截器可以直接从 request URI 模板变量中取值不依赖参数顺序。getCurrentStudentId的实现靠登录时把 studentId 写入 ThreadLocal或者直接解析 JWT Token。毕设项目推荐后者因为论文里可以写基于 Token 的无状态认证这是近年面试和答辩的高频词。这个方案相比 Spring Security 的差异在于Spring Security 通过 SecurityContext 保存认证信息用 PreAuthorize 方法级鉴权自定义拦截器则是手动从请求头解析身份再用方法注解声明角色要求。两者的区别也就是你论文里系统安全性设计章节要讲的选型依据。5.3 用 AOP 注解记录操作审计日志权限控制解决的是谁能做的问题审计日志解决的是做了之后可追溯的问题。答辩老师大概率会问社长删除了一个活动你怎么知道是谁删的所以操作审计不可省。实现方式用 Spring AOP 的自定义注解比在每个接口里手写日志代码干净得多。Target(ElementType.METHOD) Retention(RetentionPolicy.RUNTIME) public interface AuditLog { String operation() default ; } Aspect Component public class AuditLogAspect { Around(annotation(auditLog)) public Object record(ProceedingJoinPoint joinPoint, AuditLog auditLog) throws Throwable { long start System.currentTimeMillis(); Object result joinPoint.proceed(); long cost System.currentTimeMillis() - start; String operation auditLog.operation(); String params Arrays.toString(joinPoint.getArgs()); log.info(operation{}, cost{}ms, params{}, operation, cost, params); return result; } }实际项目中审计日志应该落库而不是只打到控制台。建议建一张 operation_log 表字段包括 id、student_id、operation、params、created_at。写入时机上要注意一个细节Around中 joinPoint.proceed() 返回后系统时间取的是业务执行耗时如果要记录真实的数据库变更结果可以在返回后再次查询但对毕设项目来说记录到操作名称和参数这层已经足够。5.4 配置文件中的敏感信息处理Spring Boot 项目的 application.yml 里有数据库密码如果你的代码要上传到 GitHub 或交给导师留存不能明文裸奔。最简处理是使用环境变量占位符让敏感值从运行环境注入。spring: datasource: url: jdbc:mysql://${DB_HOST}:${DB_PORT}/${DB_NAME}?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: ${DB_USERNAME} password: ${DB_PASSWORD}如果觉得环境变量还不够可以使用 Jasypt 对密码加密配置jasypt.encryptor.password环境变量作为解密密钥。这一块在springboot yml密文相关的检索中很常见你的论文里可以写系统敏感信息使用环境变量注入避免明文存储在配置文件中属于轻量但能体现安全意识的亮点。6. 从代码到毕业论文与 PPT让架构图、ER 图、接口表始终跟随代码毕业论文和 PPT 不是代码写完后再编的文档它们应该是开发过程中的副产品。这里分享一套我常用的工作流能让图表和代码保持一致避免答辩前突击补图的窘境。画 ER 图时不要用 Visio 手画推荐直接用工具从数据库反向生成。IDEA 的 Persistence 工具窗口自带从数据库生成 JPA 实体和 ER 图的功能DataGrip 和 Navicat 也有类似能力。你只需要保证第 3 章的 DDL 脚本是最新状态ER 图就能一键刷新。论文里的数据字典表也直接来自数据库的 COMMENT 注释这就是为什么之前强调字段注释必须写清楚。画架构图时把包结构映射成层次图这是最省力的方式。你的 Spring Boot 项目分包是 controller / service / repository 三层架构图画成浏览器访问 controllercontroller 调 serviceservice 访问 repositoryrepository 操作 MySQL 即可这个图在 PPT 上占一页讲清楚请求如何贯穿各层。接口表则用 Apifox 或 Knife4j 自动生成每个接口的名称、入参、出参、HTTP 方法都能直接导出成 Markdown 表格贴到论文系统实现章节。答辩前做一轮接口验证用 Apifox 批量跑一遍核心流程学生注册登录、创建社团、提交入社申请、社长审批、发布活动、学生报名、活动名额满员后的拒绝逻辑。这一步既是验证代码也是测试你自己的表达。每一个接口你都要能回答一个问题这个接口如果参数传错会发生什么答案就在统一返回体和全局异常处理里。关于 PPT内容结构建议控制在一个固定套路里选题背景、技术选型对比表、架构图、ER 图、核心流程图活动报名时序、功能截图、测试结果表。选型对比表写三行就够Spring Boot vs SSH、JPA vs MyBatis、JWT vs Session各写两到三条理由。这张表能挡住大部分你为什么选这个的提问。最后提醒一个很容易在答辩现场暴露的问题代码里不能只有 controller 和 repository没有任何 service 层业务逻辑。老师翻你项目源码时如果发现所有业务都是 Repository 直接拼 SQL那论文里所谓系统设计就是空的。确保状态流转、并发控制、权限断言这些逻辑都在 service 层这才是基于 Spring Boot 的社团管理系统设计里真正值分的地方。本文还有配套的精品资源点击获取