这阵子连续被几个准备课设和毕设的同学问到同一个题目：基于 Spring Boot 的大学生社团活动组织展示举办平台。说实话，这类选题在高校里出现频率确实高，因为它贴合校园实际场景，功能边界清楚，既不像电商系统那样绕，也不像单纯的管理系统那样单薄，用来做课程设计有得讲，用来做毕业设计也能扩展。这个项目通常都带着源码、数据库脚本和万字文档，但很多人拿到手之后并不清楚该怎么把项目跑起来，更不清楚里面的核心逻辑是什么。这篇就把我实际做这个项目时的设计思路、数据库结构、核心接口实现和部署经验完整梳理一遍，给准备复现或者做二次开发的朋友一个能直接抄作业的参照。
这个平台本质上要解决三件事：社团活动怎么展示、学生怎么报名、负责人怎么统计管理。围绕这三件事，拆出用户、社团、活动、报名、签到、公告几个模块，用 Spring Boot 做后端服务，用 MySQL 存数据，用 MyBatis 做数据访问。整个项目跑起来之后，学生能看活动列表、报名活动、扫签到码，社团管理员能发活动、管成员、看报名数据，系统管理员能审核社团和活动、管理用户状态。适合的人群也很清楚：计算机专业做课设/毕设的学生、刚开始学 Spring Boot 想找一个完整项目练手的开发者，以及需要给学生会、团委搭一个简单活动管理后台的同学。
1. 项目定位与整体设计思路
1.1 需求拆解：一个在线场地，解决社团的“三件事”
做系统之前最忌讳一上来就写代码。先想清楚这个平台的使用者是谁、他们要干什么。在这个项目里，使用者可以分成三类：
- 普通学生：浏览活动、查看社团、报名感兴趣的活动、活动当天签到。
- 社团管理员：维护社团信息、发布活动、审核成员申请、查看报名列表。
- 系统管理员：审核社团注册、审核活动发布、管理用户和社团状态、看总体的活动数据。
传统方式里，社团发活动靠贴海报、在群里接龙报名、用 Excel 统计签到，信息分散而且容易漏。后来很多人想做一个集中平台，但容易把功能堆得很杂，社团要审批、活动要审批、评论要审批、积分要累计，结果课设周期根本做不完。这个项目我建议只保留一条主线：发活动 -> 看活动 -> 报名活动 -> 签到 -> 统计。其他功能，比如社团风采展示、公告通知，都属于锦上添花，可作为扩展点写进文档，但不作为核心必须项。
按照这个思路，功能模块可以这样列：
| 模块 | 主要功能 | 使用者 |
|---|---|---|
| 用户模块 | 注册、登录、角色区分、个人信息 | 全部角色 |
| 社团模块 | 创建社团、审核注册、成员管理、社团风采展示 | 学生 / 社团管理员 / 系统管理员 |
| 活动模块 | 发布活动、审核活动、活动列表、活动详情 | 社团管理员 / 系统管理员 / 学生 |
| 报名模块 | 报名活动、取消报名、名额校验、报名列表 | 学生 / 社团管理员 |
| 签到模块 | 活动签到、防止重复签到、签到统计 | 学生 / 社团管理员 |
| 统计模块 | 活动数量、报名人数、签到率按社团/时间统计 | 社团管理员 / 系统管理员 |
1.2 为什么选 Spring Boot 这个技术栈，而不是 SSH 或原生 Servlet
现在再做课设/毕设，Spring Boot 几乎是最省力的选择，没有之一。对比以前的 SSM 手动配置，Spring Boot 把 Tomcat 内嵌到应用里，数据源、事务、日志这些基础配置都交给了自动配置机制，写业务的时候不用再跟一堆 XML 配置文件较劲。原生 Servlet 写接口虽然能让你理解 HTTP 底层，但开发效率太低，课设周期根本耗不起。
数据库访问层我建议用 MyBatis，而不是 Spring Data JPA。理由很简单：这个项目的查询场景比较灵活，比如活动列表要按状态、社团、时间范围做多条件筛选，报名记录要统计数量，MyBatis 的动态 SQL 写起来直白，出了问题也好排查。如果你后面想快速跑起来，MyBatis 的 Mapper 接口加 XML 也方便生成文档。
选版本这里要重点提醒一下：不要一上来就选 Spring Boot 3.x 最新版。3.0 之后的包名从 javax 迁移到了 jakarta，很多老教程、老依赖和代码片段会不兼容，尤其是 MyBatis、PageHelper 这些第三方库，版本对不上就会启动报错。这个项目用 Spring Boot 2.7.x 就好，社区资料多，坑也都被踩平了。
1.3 项目分层与目录结构：三层架构怎么落地
一个适合答辩讲解和二次开发的项目，代码结构一定要清楚。我习惯分成三层：Controller 收请求参数、返回统一结构；Service 写业务规则、事务控制；Mapper 负责数据库读写。实体类用 Entity，给前端用的对象单独放 DTO，避免直接把数据库表字段暴露给前端。
下面是我常用的包结构：
src/main/java/com/example/clubactivity ├── config // 配置类，比如跨域配置、JWT拦截器配置 ├── controller // 接口层，接收HTTP请求 ├── service // 业务层，事务逻辑都在这里 │ └── impl ├── mapper // MyBatis Mapper接口 ├── entity // 数据库实体类 ├── dto // 请求/响应对象 ├── common // 统一返回结构、异常处理、常量 └── utils // JWT工具、日期工具等每个包的职责要单一。Controller 里不要写 SQL，不要写业务判断；Service 里不要出现 HttpServletRequest；Mapper 只做持久化。后面写万字文档的时候，分层是最容易画出架构图的部分，也最容易让答辩老师觉得你有工程化意识。
实际写代码的时候，还有一个细节：统一返回结构一定要先从 common 包开始写。我见过很多同学先写 Controller，返回类型一会儿用 Map，一会儿用 String，最后接口文档没法写。后面我会单独讲统一返回结构怎么写，这里先记住，这是项目能不能顺利联调的关键。
2. 数据库设计与核心数据模型
2.1 六张核心表：字段多不等于设计好
数据库设计是这种课设项目的灵魂。很多同学喜欢把字段铺得很开，什么都想存，结果一张表二十多个字段，自己写代码的时候都记不住。这个项目我建议按业务主链路设计，先保证六张表，其他的看需要再加。
第一张是用户表user，字段包括id、username、password、real_name、student_no、phone、role、status、create_time。角色字段可以用role区分：0 表示普通学生，1 表示社团管理员，2 表示系统管理员。不要再用 1、2、3 之外的魔术数字，写代码的时候用常量定义。
第二张是社团表club，字段包括id、club_name、description、logo、president_id、status、create_time。president_id指向用户表，表示社长。status表示待审核、正常、禁用三种状态。
第三张是活动表activity，字段包括id、club_id、title、content、location、start_time、end_time、total_slots、registered_count、status、create_time。status表示草稿、待审核、进行中、已结束、已取消。registered_count是冗余字段，维护它需要小心，但是能大幅提升列表页的查询速度。
第四张是报名表registration，字段包括id、activity_id、user_id、register_time、status。status表示已报名、已取消。这张表必须加唯一约束，索引活动 ID 和用户 ID，防止同一个人重复报名。
第五张是签到表check_in，字段包括id、activity_id、user_id、check_in_time。这张表同样加唯一约束，防止重复签到。
第六张是公告表announcement，字段包括id、title、content、create_time。公告一般给系统管理员发，社团也可以有自己的公告，但初期可以先共用一张表，加type字段区分。
2.2 表关联关系：外键到底建不建
在 MySQL 里，我建议这些表之间的逻辑关联用字段表达，但不建物理外键约束。什么意思？就是说activity.club_id指向club.id，但不在 MySQL 层面声明FOREIGN KEY。原因有三点：
- 项目数据量不大，物理外键带来的完整性保护意义有限。
- 后期如果要删测试数据，外键会带来一堆级联麻烦。
- 课程设计阶段，代码里的事务控制足够保证数据一致性。
表之间的关系用文字就能说清楚：用户和社团是多对多关系，通过club_member中间表维护，成员表可以只放id、club_id、user_id、join_time四个字段。活动和社团是多对一关系，一个社团可以发布多个活动，一个活动只属于一个社团。活动和用户是多对多关系，通过registration报名表关联，报名表本身还承担了状态流转。
这里特别提醒：活动表里的registered_count和报名表的数据必须保持一致。很多人图省事，列表页的报名人数直接从 count 表里统计，但数据量稍微大一点就会出现性能问题。我的做法是报名成功时把registered_count加一，取消报名时减一，同时在 Service 层用事务保证两步一起成功。
2.3 核心建表 SQL：直接能跑起来的脚本
为了方便你直接复现，我把核心建表 SQL 放在下面。字符集统一用utf8mb4，排序规则用utf8mb4_general_ci，防止中文乱码，也支持表情符号。时间字段用datetime，不要用varchar存时间，否则后面排序和统计都会很难受。
CREATE DATABASE IF NOT EXISTS club_activity_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE club_activity_db; CREATE TABLE `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 '真实姓名', `student_no` VARCHAR(20) DEFAULT NULL COMMENT '学号', `phone` VARCHAR(20) DEFAULT NULL COMMENT '联系电话', `role` TINYINT NOT NULL DEFAULT 0 COMMENT '0学生 1社团管理员 2系统管理员', `status` TINYINT NOT NULL DEFAULT 0 COMMENT '0正常 1禁用', `create_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户表'; CREATE TABLE `club` ( `id` BIGINT NOT NULL AUTO_INCREMENT, `club_name` VARCHAR(100) NOT NULL, `description` VARCHAR(500) DEFAULT NULL, `logo` VARCHAR(255) DEFAULT NULL, `president_id` BIGINT NOT NULL, `status` TINYINT NOT NULL DEFAULT 0 COMMENT '0待审核 1正常 2禁用', `create_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_president_id` (`president_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='社团表'; CREATE TABLE `activity` ( `id` BIGINT NOT NULL AUTO_INCREMENT, `club_id` BIGINT NOT NULL, `title` VARCHAR(100) NOT NULL, `content` TEXT, `location` VARCHAR(100) DEFAULT NULL, `start_time` DATETIME NOT NULL, `end_time` DATETIME NOT NULL, `total_slots` INT NOT NULL DEFAULT 0 COMMENT '总名额', `registered_count` INT NOT NULL DEFAULT 0 COMMENT '已报名人数', `status` TINYINT NOT NULL DEFAULT 0 COMMENT '0草稿 1待审核 2进行中 3已结束 4已取消', `create_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_club_id` (`club_id`), KEY `idx_status` (`status`), KEY `idx_start_time` (`start_time`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='活动表'; CREATE TABLE `registration` ( `id` BIGINT NOT NULL AUTO_INCREMENT, `activity_id` BIGINT NOT NULL, `user_id` BIGINT NOT NULL, `register_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, `status` TINYINT NOT NULL DEFAULT 0 COMMENT '0已报名 1已取消', PRIMARY KEY (`id`), UNIQUE KEY `uk_activity_user` (`activity_id`, `user_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='报名表'; CREATE TABLE `check_in` ( `id` BIGINT NOT NULL AUTO_INCREMENT, `activity_id` BIGINT NOT NULL, `user_id` BIGINT NOT NULL, `check_in_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_activity_user` (`activity_id`, `user_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='签到表';索引设计上，activity表的status和start_time要单独建索引，因为列表页经常按这两列排序筛选。registration表加唯一索引，这是防止重复报名的最后一道数据库防线，代码里判断一千次，也不如这一条唯一约束稳。如果你在后期把活动报名做成并发场景，这条唯一索引能救你一次。
3. 后端核心模块与实现重点
3.1 登录认证与权限控制：JWT 怎么落地
毕设项目里最常见的认证方案是 JWT。相比 Session，JWT 天然适合前后端分离，不用在服务器端存会话状态，接口拿到 token 就能解析出用户信息。但要注意，JWT 只适合做身份认证，不适合存敏感数据，密钥也不要硬编码在代码里。
我把认证逻辑拆成三个部分：登录接口生成 token，拦截器解析 token，注解控制角色权限。工具类里有一个JwtUtil，核心方法大概是这样的逻辑：
public String generateToken(Long userId, String username, Integer role) { Date now = new Date(); Date expiryDate = new Date(now.getTime() + 24 * 60 * 60 * 1000); return Jwts.builder() .setSubject(username) .claim("userId", userId) .claim("role", role) .setIssuedAt(now) .setExpiration(expiryDate) .signWith(SignatureAlgorithm.HS256, secretKey) .compact(); } public Claims parseToken(String token) { return Jwts.parser() .setSigningKey(secretKey) .parseClaimsJws(token) .getBody(); }密码这块，不要再用 MD5 或 SHA 的简单加密，MD5 加盐其实也能用，但 Spring Security 自带的BCryptPasswordEncoder更省心。注册的时候把明文密码 BCrypt 加密再入库，校验的时候用matches方法比较。
权限控制我建议自己写一个轻量拦截器，不要一上来就引入整套 Spring Security 配置。在WebMvcConfigurer里注册拦截器，放行登录、注册和活动列表接口，其他接口都要校验 token。角色区分可以做一个注解@RequireRole(role = 1)，在拦截器里读当前用户的 role，不符合就返回 403。这样后面写文档时，可以单独画一张接口权限表，答辩会非常加分。
3.2 社团管理：从申请加入审核，到成员维护
社团模块的核心不是增删改查，是状态流转。学生可以提交创建社团申请，填入社团名称和简介，系统管理员审核通过后状态变成正常，提交者自动成为社长。社团成员可以邀请加入，也可以申请加入，但加入逻辑要有几个边界条件：
- 用户不能重复加入同一个社团。
- 社团状态必须为正常，禁用或待审核的社团不能加人。
- 社长不能直接退出，需要先转让社长或者解散社团。
实际写 Service 的时候，加入社团的代码大致是这个样子：
public void joinClub(Long clubId, Long userId) { Club club = clubMapper.selectById(clubId); if (club == null || club.getStatus() != 1) { throw new BusinessException("社团不存在或不可加入"); } int count = clubMemberMapper.countByClubIdAndUserId(clubId, userId); if (count > 0) { throw new BusinessException("你已经加入该社团"); } clubMemberMapper.insert(clubId, userId, new Date()); }注意这里要加事务。如果是插入club_member之后还要更新社团人数，必须用@Transactional。很多同学在写了事务注解之后，发现异常不回滚，原因一般是异常被 try-catch 吞掉了，或者方法内自调用导致事务代理失效。记住，事务只对从外部进入 Service 的方法调用生效，同一个类里的this.joinClub()不会触发 AOP。
3.3 活动发布与报名：并发场景怎么做才不出错
活动模块是这个项目的重头戏。一个完整的活动状态流转是：草稿 -> 待审核 -> 进行中 -> 已结束，中途可以被取消。社团管理员发布活动时先存成草稿或是直接提交审核，由系统管理员审核通过后，活动才在学生端可见。这个流程适合演示，也适合写文档。
活动列表接口要注意分页和筛选。一般接收参数有pageNum、pageSize、clubId、status、keyword。用 MyBatis 写动态 SQL 时，条件用<where>标签包起来，避免多余的WHERE and。我习惯用 PageHelper 做分页，用法很简单：
PageHelper.startPage(pageNum, pageSize); List<ActivityVO> list = activityMapper.selectActivityList(query); PageInfo<ActivityVO> pageInfo = new PageInfo<>(list);报名模块是真正考验功底的地方。一个活动有总名额，报名人数不能超过总名额，这看起来简单，但如果没有并发控制，两个人同时报名最后一名额就会超卖。处理方法有三种：
- 给
activity表加行锁，SELECT ... FOR UPDATE，然后判断名额，再插入报名数据。 - 使用乐观锁，在
activity表加version字段，更新报名人数时UPDATE activity SET registered_count = registered_count + 1 WHERE id = ? AND registered_count < total_slots。 - 在 Service 方法上用
synchronized或分布式锁，但单机课设项目里有点重。
最简单可靠的是第二种，SQL 层面直接约束，更新影响行数为 0 就说明名额满了。配合事务，报名接口的核心代码可以写成：
@Transactional public void registerActivity(Long activityId, Long userId) { int updated = activityMapper.increaseRegisteredCount(activityId); if (updated == 0) { throw new BusinessException("名额已满"); } try { registrationMapper.insert(activityId, userId, new Date(), 0); } catch (DuplicateKeyException e) { activityMapper.decreaseRegisteredCount(activityId); throw new BusinessException("不能重复报名"); } }这段代码里，先更新活动表名额，再插入报名记录。如果插入失败，要把名额回补，否则会出现一个人占着名额但报名表没有记录的问题。数据库唯一索引这时候就是兜底方案，哪怕逻辑漏了，重复报名也会在唯一键上炸出来。
3.4 签到与活动统计：一组数据看清活动效果
签到可以做成上课点名那种方式，活动开始时主持人展示一个签到码，学生输入活动码完成签到。这里的签到码可以直接用活动 ID 加固定后缀生成，也可以单独生成一个随机码。判断逻辑就是查check_in表里有没有该用户和活动，没有就插入一条记录。
签到接口要防止两种异常：活动还没开始就可以签到，活动已经结束还能签到。判断时间边界时，统一用后端当前时间，不要相信前端传的时间。签到完成后，可以顺手把活动详情里的签到人数刷出来，但不用每次实时 count，详情页查一次就行。
统计模块是答辩展示的亮点。比如统计每个社团的活动数量和平均报名人数，用一条GROUP BY就能拿到：
SELECT c.club_name, COUNT(a.id) AS activity_count, AVG(a.registered_count) AS avg_registered FROM club c LEFT JOIN activity a ON c.id = a.club_id GROUP BY c.id;签到率的统计稍微绕一点，要拿签到表和报名表关联，用签到人数除以报名人数。如果不想写复杂的 SQL，可以在 Service 里循环查，数据量小也能接受。但要注意，不要在循环里查数据库，先查出活动，再批量查签到数量会快很多。
4. 关键配置与实操经验
4.1 application.yml 配置：一份跑通开发环境的配置
很多项目源码跑不起来，问题都出在配置文件上。Spring Boot 的配置看起来简单，但踩坑点是真多。下面这份配置适合本地开发，MySQL 用 8.0，JDK 用 8 或 11，Spring Boot 用 2.7.x。
server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/club_activity_db?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: Asia/Shanghai mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.clubactivity.entity configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl logging: level: com.example.clubactivity.mapper: debug这里有几个地方要特别说明。第一，serverTimezone=Asia/Shanghai必须加，否则 MySQL 8 的驱动会报时区错误，或者取出来的时间差八个小时。第二，allowPublicKeyRetrieval=true解决 MySQL 8 的一些连接认证问题，不加的话有时候会报 Public Key Retrieval is not allowed。第三，MyBatis 的map-underscore-to-camel-case开启后，数据库的user_id字段就能自动映射成 Java 里的userId，省掉大量手动写resultMap的时间。
日志配置也有讲究。开发阶段把 MyBatis 的 SQL 日志打开，能看到每次请求执行的 SQL。如果接口查询慢，先在控制台看是不是有批量查询被拆成了很多单条 SQL。这里建议开发时用StdOutImpl，部署时改成Slf4jImpl或者直接关闭 SQL 打印。
4.2 统一接口返回结构：前后端联调不扯皮
接口返回格式不统一，是课设项目里最常见的混乱来源。前一个接口返回{code:200, data:...}，后一个接口返回一个裸对象，前端要用就得一直看代码。我建议在一开始就定好统一的Result<T>类。
public class Result<T> { private Integer code; private String message; private T data; public static <T> Result<T> success(T data) { Result<T> result = new Result<>(); result.code = 200; result.message = "success"; result.data = data; return result; } public static <T> Result<T> error(Integer code, String message) { Result<T> result = new Result<>(); result.code = code; result.message = message; return result; } }分页接口再包一层，把列表、总条数、页码都放进去：
public class PageResult<T> { private List<T> list; private long total; private int pageNum; private int pageSize; }Controller 返回时，不要直接返回实体类，尽量返回 VO 或 DTO。比如活动详情里要带社团名称、报名人数、签到人数，这些都是从多张表聚合出来的，定义一个ActivityDetailVO更清晰。写好统一返回结构之后，接口文档可以少写一半废话，前端对接也会非常省心。
4.3 MyBatis 数据访问：动态 SQL 和增删改查重点
这个项目的核心数据操作其实就是增删改查，但 MyBatis 里最容易出问题的不是增删改查，是动态 SQL 和结果映射。活动列表的多条件筛选用<if>判断，每个条件都要注意空值判断。比如：
<select id="selectActivityList" resultType="com.example.clubactivity.entity.Activity"> SELECT * FROM activity <where> <if test="clubId != null"> AND club_id = #{clubId} </if> <if test="status != null"> AND status = #{status} </if> <if test="keyword != null and keyword != ''"> AND title LIKE CONCAT('%', #{keyword}, '%') </if> </where> ORDER BY create_time DESC </select>这里最关键的坑是 LIKE 拼接。不要写成'%${keyword}%'，那样会有 SQL 注入风险，要用CONCAT拼参数。另外，<where>标签会自动去掉第一个多余的AND，比到处写WHERE 1=1要干净得多。
还有一个细节是日期比较。活动列表经常要看当前有哪些活动在进行中，SQL 里直接start_time <= NOW() AND end_time >= NOW()就行，但要注意存到数据库的日期时区必须和服务器一致。之前遇到过一个问题：服务器是 UTC 时区，数据库存的是北京时间，列表里的活动状态总是差几个小时。后来统一了连接参数的时区，问题才彻底解决。
5. 部署上线与踩坑记录
5.1 环境要求与本地启动步骤
要说清楚这个项目能不能跑起来，先看环境对不对。我通常建议用下面的组合：
- JDK 8 或 11
- Maven 3.6 以上
- MySQL 5.7 或 8.0
- Spring Boot 2.7.x
- IDEA 或 Eclipse 都可以，IDEA 更顺手
拿到源码之后，启动步骤其实就几步。第一步，用 IDEA 打开项目，等 Maven 把依赖下载完，这里网络不好会非常慢，可以用阿里云镜像。第二步，新建一个数据库，把源码里提供的club_activity_db.sql导入进去。第三步，修改application.yml里的数据库连接，改成你自己的用户名密码。第四步，直接运行启动类，看到 Spring Boot 启动成功的日志就说明项目起来了。
前端如果有页面，那就看 Vue 或 HTML 的目录，配置接口地址指向http://localhost:8080。如果项目是纯后端接口，可以用 Swagger 或者 Postman 测试。打包用mvn clean package -DskipTests，打出来的 jar 包在target目录下，直接java -jar xxx.jar就能运行。
5.2 服务器部署：尽量走简单可靠的路线
本地跑通之后要部署到服务器，最朴素的方式就是 JDK 加 MySQL 加 jar 包。先把 MySQL 装好，导入数据库，把 application.yml 里的数据库地址改成服务器本机地址，端口不要用公网暴露的 3306，如果有防火墙，就只开放应用端口。打包后上传 jar 包，用nohup java -jar xxx.jar > app.log 2>&1 &启动。
如果想用面板管理，可以装一个宝塔面板，把 JDK 和 MySQL 装好，然后上传 jar 包，用面板自带的进程守护工具保活。也可以写一个 Dockerfile，用 Docker 把 Spring Boot 应用打成一个镜像，但课设项目不追求容器化，Docker 部署反而增加理解成本。服务器部署的重点是日志排查，启动报错一定要看app.log，而不是只盯着终端。
这里补充一点：如果你后面要对接小程序或者手机端，接口跨域问题多半会遇到。Spring Boot 里配置跨域最简单的方法是写一个WebMvcConfigurer，重写addCorsMappings，允许所有来源、所有请求头。但注意，生产环境不要把allowedOriginPatterns设成*，尽量只允许你的前端域名。
5.3 常见问题速查表：照着排查省半天时间
项目跑不起来的原因其实很固定，我整理了一个排查表，都是带课设时反复遇到过的问题。
| 现象 | 常见原因 | 处理思路 |
|---|---|---|
| 启动时报数据库连接失败 | 数据库没启动、密码错误、驱动不对 | 先检查 MySQL 服务，按报错信息核对用户名密码，确认driver-class-name是com.mysql.cj.jdbc.Driver |
| 中文显示乱码 | 数据库字符集不是 utf8mb4 | 建库时指定 utf8mb4，连接参数加characterEncoding=utf8 |
| 时间比实际时间早/晚8小时 | 时区设置不一致 | 连接参数加serverTimezone=Asia/Shanghai，Jackson 也设置time-zone |
| 接口返回的字段名和前端对不上 | MyBatis 下划线转驼峰没开 | 检查配置map-underscore-to-camel-case: true |
| 分页不生效 | PageHelper 版本和 Spring Boot 版本不兼容 | 确认 starter 版本，2.7.x 用 PageHelper 1.4.x 稳妥 |
| 报名接口报重复数据 | 缺少唯一索引，或事务没有正确回滚 | 给registration表加唯一索引，Service 加事务并注意异常抛出 |
| 打包后启动立刻退出 | 端口被占用，或缺少配置项 | 看日志中的Port already in use，换端口或杀掉旧进程 |
| 前端访问接口报跨域 | 没有配置跨域，或配置顺序有问题 | 配置 CorsFilter 或 WebMvcConfigurer，注意拦截器要放行预检请求 |
这些问题的共同特点就是：报错信息里其实都写了原因，但很多人习惯不看完整堆栈。我见过最耽误时间的情况是，同学只盯着第一行报错，结果真正的 Caused by 在最后几行。排查的时候一定要往下翻，找到Caused by，那才是真正的根因。
另外一个很实际的建议是，开发时把日志级别调低一点，不要什么都打。日志太多和日志太少都影响排查效率。建议开发环境只保留 MyBatis 的 SQL 打印和项目自身日志，部署环境把 SQL 打印关掉，只保留 ERROR 级别。这样线上出了问题，看错误日志反而更快。
这个项目后续扩展的方向也很多，比如给活动加图片上传、用 Redis 缓存活动列表、做成小程序端，每一项都可以写进文档作为亮点。但前提是先把主流程跑通，再做扩展。我在实际做这个项目时，感受最深的一点是：与其把十个模块写出简单增删改查，不如把一个核心闭环做得完整闭环。你花两天时间把报名并发控制讲清楚，比花两天时间堆出一个评论模块更有价值。做课程设计也好，毕业设计也好，能不能把逻辑讲通，才是真正拉开差距的地方。
