企业官网建设流程全解析

每年毕设季都能在代码论坛里看到大量“学生课外活动管理系统”的 SpringBoot 项目，坦白讲，大部分只是把增删改查套了一层漂亮的外壳，真正拿去给社团联合会用，第一天就会露馅。我这次接手做这套系统，起因是学校社团联合会的老师拿着一张写满社团和活动名字的 Excel 表来找我，说每个活动报名都要手动数人头、手动核对名单，稍不注意就超额，同一个教室还被两个社团同时预订过。这系统要解决的核心根本不是“展示活动”，而是把活动从创建到归档这条链路上的状态、名额、时间冲突管住：什么时候能报名、人数上限怎么卡、状态怎么自动流转、谁有权限操作到哪一步。这篇文章就把我从业务建模、表设计、并发报名、状态机、权限控制到容器化部署的完整过程写一遍，给准备用 SpringBoot 做管理系统的同学一个能直接照着落地的参考。

1. 从CRUD课设到能真正落地的系统：先想清楚业务闭环

1.1 课外活动管理最常见的三个管理盲区

刚开始我也以为这种系统很简单，无非就是活动表、用户表、报名表，三个表一套 CRUD 就齐了。但真正去跟社团和老师聊完业务，才发现三个最容易被忽略的痛点：

• 活动状态靠人工改。活动发出去之后，什么时候从“报名中”变成“进行中”，什么时候从“进行中”变成“已结束”，以前全靠管理员手工在后台改，忘了改就会导致学生在活动已经结束之后还在报名页面提交。
• 报名名单靠 Excel 人工核。一个热门活动报名人数超过上限，就只能在群里说“报满了”，到底谁先谁后，根本没有一个可靠的判断标准；重复报名的情况也只能靠人眼去扫。
• 时间场地冲突靠脑子背。同一个时间段、同一个地点被两个活动同时预订，管理员没记住就会撞车，活动当天才发现教室被人占了。

这三个痛点决定了系统的核心链路绝不是“活动发布 + 报名记录”这么简单，而是需要一条完整的业务闭环：创建活动 → 审核发布 → 开放报名 → 名额控制 → 签到核销 → 归档统计。这条链路里每一步都有状态和时间节点参与，数据库设计、后端接口划分、定时任务配置全部围绕着这条闭环展开，而不是围着页面转。

1.2 角色边界与核心实体梳理

动手写代码之前，我把系统里会用到的人拆成了四个角色，每个角色能干什么必须一开始就定清楚，否则后面接口设计会反复返工：

• 学生：浏览活动、报名、取消报名、查看“我的活动”、活动签到；
• 社团负责人：创建活动、提交审核、查看本社团活动的报名名单、发布活动通知；
• 辅导员/管理员：活动审核、校级公告发布、场地资源维护、报名数据导出；
• 系统超管：角色分配、参数配置、日志查看。

这里有个关键设计：角色决定入口，状态决定按钮。意思是，一个按钮能不能看到，取决于角色；但看到之后能不能点，还取决于活动当前处于什么状态。比如社团负责人创建的“草稿”活动，他自己能编辑；一旦提交审核变成“待审核”，编辑按钮就必须禁用掉；审核通过进入“报名中”，连删除都不能再操作。这些边界在实体建模阶段就要想清楚，落到代码里就是状态枚举和工作流校验，而不是靠前端把按钮藏起来。

1.3 技术选型：SpringBoot为主，Redis按需引入

技术选型上我用的组合是 SpringBoot 2.7 + MyBatis Plus + MySQL 8.0，前端用的 Vue3 + Element Plus。为什么选 SpringBoot，说白了就是三点：约定优于配置，自动装配帮我把大量 Bean 管理的活干了；生态成熟，做管理系统需要的几乎所有组件它都有现成 starter；团队招人容易，这套技术栈会的人最多，后面交接维护成本低。

关于 Redis，我想多说一句。网上很多项目一上来就 Redis 缓存 + 分布式锁，看得人眼花缭乱。但对于一个学生课外活动管理系统，绝大多数实际场景下的并发量，MySQL 加上一条条件更新的 SQL 完全够用，Redis 只有在“上千人同时抢一个热门活动的名额”这种场景才真正发挥价值。我建议判断标准是：日均请求量低于一万，别上 Redis；超过一万并且同时写同一个活动名额的人数超过几百，再考虑。后面第三章我会详细讲报名并发的问题，那里是 Redis 真正可能派上用场的地方。

2. 项目结构与数据库设计：模块划分决定开发效率

2.1 单模块还是多模块：中小型项目别一上来就拆微服务

这里先回答一个很多人纠结的问题：项目结构到底用单模块还是 SpringBoot Modules 多模块。我的建议是，像学生课外活动管理系统这种规模，老老实实单模块、按业务分包就是最优解。多模块（Modules）拆分适合什么情况？适合一个公司里多个产品线共享同一套用户中心、同一套权限中心，需要把这些公共部分独立开来的大项目。对于活动管理这种业务高度内聚的系统，强行拆多模块只会增加构建成本和心智负担。

单模块也要有良好的包结构，我实际用的分包是：

• controller：接口层，只做参数接收和结果返回；
• service：业务逻辑层，承载状态流转、报名校验这些核心逻辑；
• mapper：MyBatis Plus 的 Mapper 接口层；
• entity：数据库实体；
• dto：入参出参对象，避免把实体直接暴露给前端；
• domain：领域对象，像报名结果、状态机枚举、角色枚举这些；
• config：配置类，拦截器、跨域、线程池等；
• common：通用返回体、异常处理、工具类。

这样分包的核心思想是隔离变化：数据库表结构变了只动entity，接口参数变了只动dto，业务逻辑变了只动service。我见过太多项目把业务逻辑全写在 controller 里，一个接口几百行，后面想维护简直是在考古。

2.2 活动表设计：一张表把状态和时间全部管住

活动表是整个系统的核心，字段设计直接影响后续所有业务逻辑的复杂度。我最终的activity表核心字段如下：

CREATE TABLE `activity` ( `id` BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT '主键', `title` VARCHAR(120) NOT NULL COMMENT '活动标题', `type_id` BIGINT NOT NULL COMMENT '活动分类ID', `location` VARCHAR(255) NOT NULL COMMENT '活动地点', `start_time` DATETIME NOT NULL COMMENT '活动开始时间', `end_time` DATETIME NOT NULL COMMENT '活动结束时间', `signup_start_time` DATETIME NOT NULL COMMENT '报名开始时间', `signup_end_time` DATETIME NOT NULL COMMENT '报名截止时间', `max_people` INT NOT NULL DEFAULT 0 COMMENT '报名人数上限', `current_people` INT NOT NULL DEFAULT 0 COMMENT '当前已报名人数', `status` TINYINT NOT NULL DEFAULT 0 COMMENT '状态：0草稿 1报名中 2进行中 3已结束 4已取消', `audit_status` TINYINT NOT NULL DEFAULT 0 COMMENT '审核状态：0未提交 1待审核 2通过 3拒绝', `creator_id` BIGINT NOT NULL COMMENT '创建人ID（社团负责人）', `cover_url` VARCHAR(255) DEFAULT NULL COMMENT '活动封面图', `description` TEXT COMMENT '活动详情', `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP, `update_time` DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='课外活动表';

这里最容易犯的错是只设计了活动本身的时间（start_time/end_time），却没有设计报名窗口时间（signup_start_time/signup_end_time）。这两套时间完全是两回事：活动时间是“活动什么时候开”，报名时间是“学生什么时候能报”。如果只有一个时间，系统就无法表达“活动下周开，但报名只开放三天的”这类真实业务场景。

status和audit_status我刻意分开，是因为活动发布前的审核流程和活动开始后的生命周期是两个维度，合在一起会让状态枚举爆炸。审核状态管的是“能不能出现在报名列表里”，活动状态管的是“当前到哪一步了”，两者解耦后逻辑清晰很多。

2.3 报名表：唯一约束是最后一道防线

报名表设计我同样给出核心 SQL：

CREATE TABLE `signup` ( `id` BIGINT PRIMARY KEY AUTO_INCREMENT, `activity_id` BIGINT NOT NULL, `student_id` BIGINT NOT NULL, `status` TINYINT NOT NULL DEFAULT 1 COMMENT '1正常 2取消 3签到', `signup_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '报名时间', `checkin_time` DATETIME DEFAULT NULL COMMENT '签到时间', UNIQUE KEY `uk_activity_student` (`activity_id`, `student_id`), KEY `idx_student_id` (`student_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='活动报名表';

UNIQUE KEY uk_activity_student (activity_id, student_id)这一行是最后一道防线：哪怕应用层代码因为某个并发 bug 导致同一个学生重复点击了两次报名按钮，数据库层面也会直接拒绝第二条记录，并抛出DuplicateKeyException。很多新手容易忽略这个约束，觉得“应用层已经判断过了，数据库不用再加”，但实际上应用层的判断永远存在时间缝隙，数据库约束是唯一绝对可靠的兜底。

2.4 场地时间冲突检测：SQL 的重叠区间写法

活动创建时最容易被忽略的就是活动场地冲突。两个活动如果用了同一个地点，时间不能重叠，这个校验逻辑用 SQL 判断非常简洁：

SELECT COUNT(*) FROM activity WHERE location = #{location} AND status IN (0, 1, 2) AND end_time > #{startTime} AND start_time < #{endTime}

这个 SQL 背后的数学原理是区间重叠判断。假设已有的活动时间段是[A.start, A.end]，要创建的新活动时间段是[B.start, B.end]，只要A.end > B.start且A.start < B.end，两个区间就存在交集。

这里有个很容易踩的边界坑：有人只判断A.end > B.start，以为结束时间晚于新活动的开始时间就是冲突了，结果漏掉了“已有活动完全包含在新活动时间段内”的情况——比如已有的活动是 10:00-12:00，新活动是 9:00-15:00，此时A.end(12:00) > B.start(9:00)虽然成立，但只判断这一条也能查到，因为确实重叠了。真正容易漏的是反过来：比如你只判断新活动开始时间落在已有活动区间内，当新活动时间段完全覆盖已有活动区间时（B 是 8:00-20:00，A 是 10:00-12:00），B.start 并不在 A 区间内，但冲突是实实在在存在的。所以务必要同时判断两个方向，也就是上面 SQL 里的完整写法。为了这条查询的性能，给location和start_time建一个联合索引，活动表数据量小的话无所谓，到了几万条记录时差距还是很明显的。

3. 报名防超卖与状态机流转：两个最关键的业务点

3.1 报名逻辑的三种方案对比

报名是整个系统并发压力最集中的地方，也是区分“课设代码”和“能上线系统”的分水岭。把一个活动的名额比作商品库存，报名就是一次“先检票再扣库存”的操作。我对比过三种常见方案：

3.2 我的落地实现：数据库层兜底 + 应用层控制

我最终选的是“条件 UPDATE 扣减 + 数据库唯一约束”这套组合。核心就一条 SQL：

int affected = activityMapper.update(null, Wrappers.<Activity>lambdaUpdate() .setSql("current_people = current_people + 1") .eq(Activity::getId, activityId) .eq(Activity::getStatus, 1) // 必须是报名中状态 .apply("current_people < max_people")); // 名额没满 if (affected == 0) { // 返回报名失败：活动已满或活动未开放报名 }

这条 SQL 的巧妙之处在于把两件事合并成了一个原子操作：一是校验活动状态，二是名额扣减。它通过current_people < max_people这个条件保证只有当人数还没满时才执行加一，而数据库的行锁机制保证了同一时间只有一个人能成功执行这条更新，其他人拿到的是affected == 0，由此实现了不超卖。

UPDATE 成功之后再插入报名记录：

try { signupMapper.insert(signup); } catch (DuplicateKeyException e) { // 唯一约束拦截，说明重复报名 }

这里我会额外强调一个顺序问题：先扣名额，再插报名记录。如果反过来先插报名记录再扣名额，极端情况下会出现报名记录插进去了，但名额扣减失败（比如另一个请求刚把名额占满），数据库里留着一条无意义且占着名额的脏数据，还得额外写补偿逻辑。先扣名额后插记录，即使插入时遇到重复报名冲突，名额虽然被多扣了一下，但影响很小——除非后面有更复杂的并发，否则绝大多数情况下这是最稳的顺序。

3.3 定时任务自动流转活动状态

状态流转这块，我的方案是状态值 + 时间维度 + Spring 定时任务。系统里有一个每分钟执行一次的定时任务，扫描活动表里的所有活动，根据当前时间自动推进状态：

@Component public class ActivityStatusScheduler { @Scheduled(cron = "0 * * * * ?") // 每分钟执行一次 public void autoUpdateStatus() { LocalDateTime now = LocalDateTime.now(); // 草稿且审核通过且到达报名开始时间 → 报名中 updateStatusByCondition(0, 2, now, "signup_start_time", 1); // 报名中且到达活动开始时间 → 进行中 updateStatusByCondition(1, now, "start_time", 2); // 进行中且超过活动结束时间 → 已结束 updateStatusByCondition(2, now, "end_time", 3); } }

实际 SQL 里通过<= now之类的条件批量更新，一次定时任务扫描几万条活动数据也是秒级完成的。这里有几个非常实际的注意事项：

• @Scheduled默认是在单线程执行器里跑的，如果你在同一个类里写了多个定时任务，它们默认是串行的。一个任务跑太久，另一个任务就会被阻塞。需要并行的话，在配置类里自定义TaskScheduler线程池。
• 定时任务有“幂等性”要求。生产环境中如果系统部署了多台机器，每台机器都会同时执行这个定时任务，同一批活动会被重复更新。好在这个场景下重复更新不会造成数据错误（因为状态是覆盖式更新），但如果你用定时任务发通知、发短信，就必须考虑重复执行的问题。解决办法是加分布式锁，用 Redis setnx 或者引入 ShedLock 组件。
• 时区问题：如果你部署在 Docker 容器里，默认时区是 UTC，定时任务会比北京时间晚 8 个小时执行。这个坑我后面在部署章节会专门讲怎么处理。

3.4 事务边界：不要在 Service 里盲目加 @Transactional

报名方法是一个典型的“短事务”场景，但我在代码评审时经常看到有人把一连串操作塞进一个@Transactional，包括发站内信、调用别的系统接口、记录日志。这里必须提醒：事务只应该包住真正需要原子性的数据库操作，其他非数据库操作都应该放到事务提交之后。

以报名为例，正确的事务边界只包括两条 SQL：

1. 条件 UPDATE 扣减名额；
2. INSERT 报名记录。

至于报名成功之后要发的通知、要更新的统计缓存，应该在事务提交成功后，在 Service 里通过TransactionSynchronizationManager.registerSynchronization或者直接放到事务方法外面执行。如果把发通知放进事务里，一旦消息队列或者邮件服务临时抖动，整个报名事务就可能回滚，学生明明已经报上了却被提示失败，这种体验很糟糕。

另外，定时任务批量更新活动状态时，如果一次更新几千条记录，也尽量不要包在一个大事务里，不然锁表时间太长，会阻塞正常的报名接口。按照批次每次处理几百条，是比较稳妥的做法。

4. 权限控制与通知触达：不要让每个学生看到所有按钮

4.1 角色鉴权：我不建议一上来就上 Spring Security

学生课外活动管理系统的角色逻辑不算复杂，Spring Security 当然能用，但对于中小型项目，它带来的配置成本和学习成本偏高，而且它默认引入的过滤器链对不熟悉的人就是个黑盒。

我更推荐的做法是HandlerInterceptor + 自定义注解实现 RBAC 权限控制。先定义一个注解：

@Target({ElementType.METHOD, ElementType.TYPE}) @Retention(RetentionPolicy.RUNTIME) public @interface RequireRole { String[] value(); }

然后在拦截器里做校验：

public class RoleInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { if (handler instanceof HandlerMethod) { HandlerMethod method = (HandlerMethod) handler; RequireRole requireRole = method.getMethodAnnotation(RequireRole.class); if (requireRole != null) { // 从当前登录用户上下文（提前放入 ThreadLocal）取出角色 String currentRole = LoginContext.getCurrentUser().getRole(); if (!Arrays.asList(requireRole.value()).contains(currentRole)) { response.setStatus(403); return false; } } } return true; } }

接口上只要加一行@RequireRole({"ADMIN", "TEACHER"})就能控制谁能访问。我实测下来，这种方式在中小项目里维护成本很低，一眼能看到每个接口的权限要求，排查问题非常直观。

那 Spring Security 什么时候该上？我个人的判断标准是：当系统开始需要 OAuth2 第三方登录、单点登录 SSO、复杂的密码策略、或者有多套系统统一权限中心的需求时，Spring Security 这类框架才真正值得引入。在此之前，别为“听起来更安全”买单，权限的安全在于校验逻辑本身不被绕过，而不是依赖某个框架。

4.2 自定义自动配置的进阶玩法

如果你所在的公司或实验室同时维护多个业务系统，每个系统又都在复制粘贴同一套登录拦截器、同一套统一返回体，那就值得考虑把这部分变成 SpringBoot 的自定义自动配置。

做法不复杂：把公共代码抽成一个独立的 Maven 模块，在META-INF/spring.factories（SpringBoot 2.7）或META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports（SpringBoot 3）里注册自动配置类，例如：

@AutoConfiguration public class CommonAutoConfiguration { @Bean public RoleInterceptor roleInterceptor() { return new RoleInterceptor(); } @Bean public WebMvcConfigurer authWebMvcConfigurer(RoleInterceptor interceptor) { return new WebMvcConfigurer() { @Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(interceptor).addPathPatterns("/**"); } }; } }

这样其他项目只要引入这个依赖，登录拦截器和通用返回体就自动生效，不需要在每个项目里都写一遍这几十行配置代码。这也是 SpringBoot 自动装配机制的实际应用，理解了它，你再看手写 xx-starter 的项目源码就能很快看懂了。唯一要提醒的是：不要过度抽象，两三个系统之间的公共代码，复制一份的成本可能比维护一个 starter 更低。我自己的习惯是，当公共逻辑出现第三次复用，才动手抽。

4.3 消息通知的务实选型：ActiveMQ 还是站内信？

活动报名成功、审核结果、活动提醒，这些通知怎么发送，也是一个经常被过度设计的地方。很多教程喜欢一上来就引入消息中间件，热度词里的 ActiveMQ 也时常出现在此类系统里。我的观点很直接：如果通知的量级每天只有几千条，老老实实建一张站内信表 + 定时任务推送，别上消息队列。

站内信表设计非常简单：

CREATE TABLE `message` ( `id` BIGINT PRIMARY KEY AUTO_INCREMENT, `user_id` BIGINT NOT NULL COMMENT '接收人ID', `content` VARCHAR(500) NOT NULL, `is_read` TINYINT DEFAULT 0, `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP, KEY `idx_user_id` (`user_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

业务操作发生时往表里插入数据，学生登录后轮询一次未读数，或者后台定时扫表通过邮件发送。实现简单、可控性高，不会出现消息队列宕机导致通知丢失的问题。

那什么时候才能真正用得上 ActiveMQ 或 Redis Stream？两个条件：一是消息量到了一天内几万条以上，削峰填谷能显著降低对数据库和邮件服务的冲击；二是你有多个系统，需要做异步解耦，比如活动报名成功后，要通知统计系统、档案系统、通知系统等多个下游，这时候消息队列的价值才真正体现。否则你引入的每一个中间件，都给部署和维护多添了一份负担。

5. 版本与依赖踩坑实录：SpringBoot 3.x 不是升了就完事

5.1 版本兼容矩阵

写这篇文章时，网上最热门的一批 SpringBoot 相关搜索里，“springboot 版本太高”是出现频率极高的关键词。版本太高带来的不是新功能，而是生态断裂。我列一下自己实测过的稳定组合，方便你直接在项目里套用：

新手最容易犯的错是：新建一个 SpringBoot 3.3 项目，然后直接复制网上 2.x 版本时代的 MyBatis Plus 依赖，结果项目跑不起来。

5.2 实践中的三个典型坑

第一个坑是javax变jakarta。SpringBoot 3 起，整个 Java EE 命名空间从javax.servlet迁移到了jakarta.servlet。你自己写过的所有 Filter、Servlet、监听器中import javax.servlet.*全部需要改成import jakarta.servlet.*。这个坑不隐蔽，但如果你从老教程直接复制代码，编译时会报一大堆包找不到，排查起来相当费神。

第二个坑是 SpringBoot 2.6 开始默认禁止循环依赖。老项目升级时，Spring 容器启动直接报The dependencies of some of the beans in the application context form a cycle。以前很多项目 AService 依赖 BService，BService 又依赖 AService，虽然不推荐但这种写法偶尔存在，SpringBoot 2.6 之前默认允许，升级之后直接启动失败。解决办法是重构依赖关系，把公共逻辑抽到第三个 Service 里；最差的办法才是设置spring.main.allow-circular-references=true强行打开容错开关，这个开关我不建议在生产环境开。

第三个坑是 Redis 序列化。如果你用 Spring Data Redis，默认的JdkSerializationRedisSerializer存进去的数据，在你用可视化工具查看时是一堆乱码。我一般会显式配置StringRedisSerializer（key）+GenericJackson2JsonRedisSerializer（value）。但这个组合有一个隐蔽问题：LocalDateTime默认反序列化可能会报错，需要在 ObjectMapper 里注册JavaTimeModule。一个小建议：用 Jackson 序列化 Redis 里的实体时，尽量在实体里提前处理日期字段序列化格式，避免踩到 JavaTimeModule 的坑。

5.3 配置外置与多环境隔离

关于 springboot 配置这块，我的铁律是：代码仓库里只提交模板配置文件，真正的账号密码用环境变量传入。结构上拆成三份：

• application.yml：公共配置；
• application-dev.yml：本地开发环境；
• application-prod.yml：生产环境。

生产配置里数据库密码、Redis 密码、短信密钥统统不写死，而是用${DB_PASSWORD}这种占位符，部署时通过环境变量注入。SpringBoot 对SPRING_PROFILES_ACTIVE和SPRING_DATASOURCE_PASSWORD这些环境变量有原生支持，直接用就完了。这样做的直接好处是，切换环境不用改代码重新打包，git 历史里也不会出现明文密码，风险小很多。

6. 宝塔+Docker 部署：把自己写的系统真正跑起来

6.1 多阶段构建的 Dockerfile

项目代码写完，最后一步是部署。我这次用的是宝塔面板的 Docker 管理器，配合 Nginx 反向代理。先给一个可以直接用的多阶段构建 Dockerfile：

FROM maven:3.8-openjdk-17 AS build WORKDIR /app COPY pom.xml . RUN mvn dependency:go-offline -B COPY src ./src RUN mvn package -DskipTests FROM eclipse-temurin:17-jre ENV TZ=Asia/Shanghai RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone WORKDIR /app COPY --from=build /app/target/activity-system.jar app.jar EXPOSE 8080 ENTRYPOINT ["java", "-jar", "app.jar"]

这里有两处细节值得注意：一是先COPY pom.xml再执行dependency:go-offline，利用 Docker 的层缓存机制，只要依赖不变化，后面每次构建都会直接复用这一层，构建速度和开发体验完全不一样；二是创建运行镜像时显式设置时区，SpringBoot 的定时任务、日志时间戳都依赖容器时区，不设置的话后面定时任务差 8 小时，排查好久才意识到是时区问题。

6.2 宝塔面板中的容器编排细节

宝塔里的操作流程大概是：

1. 在软件商店安装 Docker 管理器；
2. 创建 MySQL 容器或者直接用宝塔自带的 MySQL，记得开启 binlog，方便以后数据恢复；
3. 构建后端镜像并创建容器，端口映射为8080:8080，数据卷挂载配置文件目录；
4. 前端打包成静态文件，放到 Nginx 站点目录，反向代理到后端容器。

Nginx 配置里最核心的一段：

location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; }

如果你的前端用了 WebSocket 推送或在线聊天，还要额外加上升级头的配置：

proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade";

有一件事我在这里特别强调：Docker 容器内的 MySQL 数据目录必须挂载到宿主机卷，容器的可写层一旦重建容器就会全部蒸发。宝塔的 docker 管理的图形界面提供了数据卷挂载功能，不要因为嫌麻烦跳过，数据无价。

6.3 容器内定时任务与日志排障

容器部署之后的日常维护，有两件事最容易翻车。第一件是定时任务。如果你用的是 Spring 自带的@Scheduled，任务在应用内部跑，不需要额外在 Linux 里配 cron。但如果你有些清理任务想在宿主机层面定期做（比如清理日志、备份数据库），建议写在宿主机的 crontab 里，通过docker exec mysql mysqldump这种形式执行。不要在容器里再装一个 cron，因为容器重建后配置就丢了。

第二件是日志。运行日志务必挂载到宿主机目录，比如数据卷挂载/logs:/app/logs。这样出问题时可以直接tail -f /logs/app.log，不用先进容器再找日志文件。另外 SpringBoot 默认的日志是打到控制台的，Docker 会通过docker logs收集，但这些日志在容器销毁后就没了。如果项目要长期维护，建议配置 logback 同时输出到文件和控制台，文件路径放在挂载卷里。我吃过一堑：有一次半夜接口报错，因为日志没落盘，想排查根本没有历史记录，只能靠用户截图回忆，那种感觉极其痛苦。

部署完成后，我还会顺手宝塔里建一个每天凌晨的数据库备份任务，备份文件保留最近七天。别嫌多做这一步，哪天有学生问“我上周报名的活动名字叫什么，后台怎么查不到了”，你能从备份里翻出数据时，会感谢当时多花了这十分钟。

最后分享一个实际操作的体会。这套系统从头到尾做下来，我最大的感受是：写管理系统，真正的复杂度从来不在 CRUD，而是在业务边界——哪个状态能操作哪个字段、哪些人有资格看到哪个按钮、什么条件下名额可以扣减。把这些边界用状态枚举和数据库约束固定住，剩下的页面和接口不过是一块一块拼图。如果你们也在做类似的学生课外活动管理系统，建议先把第三章那两条 SQL 和第四章的定时任务跑通，再开始写页面。另外一点小经验：系统上线后，第一时间把“一键备份”配好，半夜被问数据能不能恢复的时候，你会感谢这个习惯。