SpringBoot+Vue实战：校园活动管理系统从需求梳理到部署上线

每年开学季，社团招新、讲座报名、比赛登记这种事情总会把学生会的同学折腾得够呛。海报贴一墙、Excel传一圈、现场签到全靠纸质名单，最后统计人数还得人工数。做一套基于SpringBoot + Vue的校园活动管理系统，就是把这些琐碎流程线上化：管理员发活动，学生在手机上报，组织者扫个码就能签到，数据自动汇总成表格。这个题目在项目实践中非常常见，也是很多同学第一次真正接触前后端分离项目的起点。

这篇文章我会从需求梳理、技术选型、后端实现、前端联调，一直讲到部署上线的坑。重点放在活动状态流转、并发报名控制和文件上传这几个容易翻车的环节，中间会穿插直接能用的代码片段。内容不追求大而全，而是把“活动发布—学生报名—审核签到—数据统计”这条主线走通，帮你少走几个月的弯路。

1. 需求与业务脉络拆解——活动管理系统到底在管什么

1.1 从三个真实场景看功能边界

先别急着建表写代码，需求理清楚，后面能少改一半。我习惯用场景推功能，校园活动系统最有代表性的三个场景是这样：

第一个，某学院学术部办一场讲座。需要提前发布讲座信息，学生在线报名，到场后扫码签到，结束后统计出勤人数。这个场景的核心是“报名+签到”，对时间窗口有强要求——过了报名截止时间就必须关掉入口。

第二个，某社团开放日。多个社团同时发布体验活动，学生可以一次性浏览所有活动，选择感兴趣的报名，还能看到活动地点、时间、剩余名额。这个场景的核心是“多活动展示+名额控制”，要求列表页响应快，报名状态实时准确。

第三个，比赛类活动。比如新生编程赛，需要学生线上提交作品材料，组织者审核通过后才算报名成功。这个场景的核心是“提交流程+审核环节”，比普通活动多了一层状态转换。

从这三个场景抽象下来，系统的功能模块其实很清楚：

• 用户端：活动大厅（分类浏览、搜索、分页）、活动详情、报名/取消报名、我的报名列表、个人中心、站内通知。
• 组织者端：活动创建与编辑、活动审核申请、报名名单查看与导出、现场签到管理、作品/材料审核。
• 管理端：用户管理（禁用/启用）、活动审核、分类标签维护、全局数据统计、下架违规活动。

不要一上来就做消息推送、积分商城、二手交易这些花活。核心主线就是“发布—报名—审核—签到—统计”，先把这条链路做扎实，其他的都是锦上添花。

1.2 角色权限设计：为什么要拆成三种角色

很多人做系统习惯只分“普通用户”和“管理员”两档，但校园活动系统这么搞会很别扭。举个例子：社团部长确实是个普通学生，但他需要管理自己社团发布的活动，你不能让他跑去找系统管理员帮他改活动时间。所以至少要拆出三种角色：

• 学生（student）：浏览活动、报名、取消、查看通知。
• 组织者（organizer）：拥有学生的全部权限，另外可以创建活动、管理自己创建的活动（改信息、看报名名单、发起签到）。
• 管理员（admin）：最高权限，可以审核活动、下架违规活动、管理所有用户、查看全站统计。

组织者的权限边界一定要用“资源归属”去控制，而不是只靠角色。也就是：组织者可以编辑活动，但只能编辑 creator_id 等于自己ID的活动。如果只判断“你是组织者就能编辑所有活动”，那和裸奔没区别。我当时在这个点上踩过坑，接口写得省事，结果一个组织者能改另一个社团的活动信息，被测试的同学当场抓包。

权限控制的落地可以分两层。第一层是接口级别：用 Spring Security 的 @PreAuthorize 注解判断角色；第二层是数据级别：在 Service 里显式校验资源归属，两种都写了才安全。比如：

@PreAuthorize("hasRole('ORGANIZER')") public void updateActivity(Long activityId, ActivityDTO dto) { Activity activity = activityMapper.selectById(activityId); if (!activity.getCreatorId().equals(currentUserId())) { throw new BusinessException("只能编辑自己创建的活动"); } // 继续更新逻辑 }

1.3 数据模型的核心：活动状态机

活动表不能只有一个 status 字段随便改，一定要设计状态机。我见过很多半成品系统，活动状态全靠前端按钮改，后端不校验，最后出现“活动都结束了还能报名”的怪事。合理的状态至少要有这些：

状态流转要守住两条铁律。第一，只有特定前置状态才能转移到特定结果，比如活动必须经过管理员审核才能发布，草稿直接跳到进行中是违规操作。第二，时间条件是状态流转的天然触发器：报名结束时间过了，状态就必须离开 REGISTERING。

这里分享一个实战经验：列表页展示的状态不要完全依赖定时任务去更新，而是用“状态 + 时间字段”动态计算。比如活动在数据库里的状态是 PUBLISHED，但当前时间已经过了报名截止时间，前端展示时就计算成“已截止”。定时任务只在后台兜底，把长时间没人碰的状态批量更新掉，避免脏数据越积越多。

2. 技术选型：为什么是SpringBoot + Vue

2.1 后端选型逻辑

后端选 SpringBoot，基本没什么悬念，生态成熟、招人容易、出问题能搜到大量解决方案。版本我用的是 SpringBoot 2.7.x + JDK 8，现在也有团队直接上 SpringBoot 3 + JDK 17，但考虑到很多校园项目要部署在老机器上，JDK 8 的兼容性最好，我建议按 2.7.x 来做。

ORM 层推荐 MyBatis-Plus。单表 CRUD 它几乎不用写 SQL，自带分页插件、逻辑删除、自动填充，能省很多重复劳动。尤其活动列表这种分页+条件查询的场景，用 LambdaQueryWrapper 写起来非常舒服：

LambdaQueryWrapper<Activity> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(Activity::getStatus, status) .like(StringUtils.hasText(keyword), Activity::getTitle, keyword) .orderByDesc(Activity::getCreateTime); Page<Activity> page = activityMapper.selectPage(new Page<>(current, size), wrapper);

数据库用 MySQL 8.0，没有特殊理由的话够用了。认证授权这块，老项目很多人用 Shiro，但我更推荐 Spring Security + JWT。虽然 Spring Security 刚接触时配置有点绕，但它是真正的行业标准，你以后做企业项目迟早要面对，不如现在就把它啃下来。后面第三节我会把配置讲透。

为什么不推荐用 Python Flask 或者 Node.js 写这个项目？不是说不行，而是这个题目在毕业设计、课程实训里出现率太高，几乎所有参考案例都是 Java 技术栈。遇到问题你能搜到同款报错，面试官问起来也能顺理成章地解释框架原理，试错成本低很多。

2.2 前端选型逻辑

前端新项目直接 Vue 3 + Vite + Element Plus。Vite 冷启动比 Webpack 快太多，开发体验好了不是一点半点。如果你的团队只熟 Vue 2 + Element UI，也不是不能用，但新项目建议一步到位，别在旧版本上纠结。

状态管理用 Pinia，比 Vuex 写起来简单，Store 里存登录用户信息、token、全局字典就够了。请求库用 Axios，统一封装一个实例，设置 baseURL、超时时间、请求拦截器注入 token、响应拦截器处理业务码和 401 跳转。UI 组件库选 Element Plus，表格、表单、分页、日期选择器都是现成的，后台管理页几乎不用自己造轮子。

移动端的问题必须提前想清楚。这个系统学生肯定会在手机上用，活动列表和报名按钮如果只能在 PC 上玩，实用性大打折扣。我当时的做法是：核心页面（活动大厅、详情、报名、我的）用响应式布局，栅格系统在窄屏下自动单列；后台管理页面默认只在 PC 上操作，不做移动适配。这样省了一半工作量，学生那边体验也不差。

2.3 辅助组件与开发效率工具

开发效率和运行稳定性靠几个辅助组件提上来：

• Redis：缓存登录 token、活动详情、验证码。还有一个妙用：作为并发报名的计数器，后面专门讲。
• Hutool：工具集合包，验证码生成、Excel 导出、随机数、日期处理都能用它，省得自己造轮子。
• Knife4j：接口文档工具，Swagger 的增强版，前后端联调时让前端同学直接看文档调接口，不用追着你问字段。
• Lombok：消除 Getter/Setter/构造器样板代码，实体类干净很多。
• Logback：日志框架，SpringBoot 自带，配置一下日志级别和打印格式就好。

还有一点很容易被忽略：统一返回结构。别让 Controller 直接返回实体类，建议封装一个 Result ，包含 code、message、data 三个字段。这样前端拦截器可以统一处理业务错误，而不是每个接口各写一套错误弹窗。团队协作时这几乎是必须的。

3. 后端核心实现：认证、活动CRUD与状态流转

3.1 JWT + Spring Security 的完整接入

先讲认证流程。用户拿用户名密码调用 /api/auth/login，后端校验通过后生成 JWT 返回给前端。前端每次请求都把 JWT 放到 Authorization 头里，后端通过 Filter 解析 JWT、加载用户信息、塞到 SecurityContext 里。后续接口通过 @PreAuthorize 或直接获取当前用户来完成鉴权。

Spring Security 配置的核心是 SecurityFilterChain。放行登录接口、静态资源、Knife4j 文档，其余接口全部要求认证。配置长这样：

@Bean public SecurityFilterChain filterChain(HttpSecurity http) throws Exception { http.csrf().disable() .sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS) .and() .authorizeHttpRequests() .requestMatchers("/api/auth/login", "/api/captcha", "/doc.html", "/webjars/**", "/v2/api-docs").permitAll() .anyRequest().authenticated() .and() .exceptionHandling().authenticationEntryPoint(restAuthEntryPoint); http.addFilterBefore(jwtAuthenticationFilter, UsernamePasswordAuthenticationFilter.class); return http.build(); }

JWT 解析 Filter 是重点。它的职责只有一个：从请求头里拿 token，解析出用户ID，加载用户信息放到 SecurityContext。如果 token 不存在或解析失败，直接放行，让后面的权限判断去拦截。不要在 Filter 里抛业务异常，否则会把简单问题搞复杂。

还有一个小技巧：用 HandlerMethodArgumentResolver 把当前登录用户注入 Controller 参数。不然每个接口都要从 SecurityContext 里手动取用户，代码会非常啰嗦。写一个 CurrentUser 注解加一个 Resolver，Controller 里直接写：

@GetMapping("/my-list") public Result<List<ActivityVO>> myList(@CurrentUser UserDO user) { return Result.success(activityService.listUserActivities(user.getId())); }

JWT 密钥放到 application.yml 里，不要写死到代码中。过期时间建议 2 小时，不要设 7 天，安全风险太大。想提升体验可以加刷新 token，但校园系统使用频率不高，过期了重新登录完全可以接受。

3.2 活动实体设计与状态流转逻辑

活动表是最核心的表，字段设计直接影响后续开发的效率。我从实际项目里总结了一套够用的字段：

@TableName("activity") public class ActivityDO { @TableId(type = IdType.ASSIGN_ID) private Long id; private String title; // 活动标题 private String description; // 活动详情 private String location; // 活动地点 private LocalDateTime startTime; // 活动开始时间 private LocalDateTime endTime; // 活动结束时间 private LocalDateTime registerStartTime; // 报名开始时间 private LocalDateTime registerEndTime; // 报名截止时间 private Integer capacity; // 人数上限 private Integer currentRegisters; // 当前报名人数 private String coverUrl; // 封面图 private Integer status; // 状态枚举值 private Long creatorId; // 创建者ID private Long categoryId; // 分类ID private LocalDateTime createTime; private LocalDateTime updateTime; }

时间字段建议用 LocalDateTime，不要用 Date，因为 LocalDateTime 更好处理、更不容易出时区问题。LIKE 查询标题、分类筛选、状态筛选都是列表页的刚需，写进 Mapper 的条件构造器里即可。

状态流转逻辑我建议做成两个方法：一个查询，一个变更。查询时动态计算实际状态，变更时严格校验前后状态。伪代码如下：

public Integer getDisplayStatus(ActivityDO act) { LocalDateTime now = LocalDateTime.now(); if (act.getStatus() == StatusEnum.CANCELED.getCode()) return StatusEnum.CANCELED.getCode(); if (act.getStatus() == StatusEnum.PUBLISHED.getCode()) { if (now.isBefore(act.getRegisterStartTime())) return StatusEnum.PUBLISHED.getCode(); if (now.isBefore(act.getRegisterEndTime())) return StatusEnum.REGISTERING.getCode(); if (now.isBefore(act.getStartTime())) return StatusEnum.CLOSED.getCode(); if (now.isBefore(act.getEndTime())) return StatusEnum.ONGOING.getCode(); return StatusEnum.FINISHED.getCode(); } return act.getStatus(); }

注意，这里的 DRAFT、PENDING 状态不受时间影响，只有已发布的活动才按时间窗口动态推进。这套逻辑在详情页和列表页复用，保证用户看到的“可报名”状态和后端校验结果一致。

3.3 报名流程与并发控制

报名接口是整个系统的重中之重。只做功能测试时看着没啥问题，但一旦活动热门、几百人同时报名，很容易出现“名额超卖”。我拆解一下正确流程：

1. 校验活动存在且当前展示状态为 REGISTERING；
2. 校验当前时间在报名时间窗口内；
3. 校验用户没有重复报名；
4. 校验当前报名人数小于人数上限；
5. 扣减活动表名额，插入报名记录。

前四步是业务判断，第五步是数据操作，而且必须保证原子性。如果直接先查 count 再判断再插入，并发下一定会出问题。我推荐用数据库行锁做扣减，这是最简单可靠的方案：

@Transactional(rollbackFor = Exception.class) public void register(Long activityId, Long userId) { ActivityDO act = activityMapper.selectByIdForUpdate(activityId); // 业务校验略 if (act.getCurrentRegisters() >= act.getCapacity()) { throw new BusinessException("活动名额已满"); } activityMapper.incrRegisters(activityId); registerMapper.insert(new RegisterDO(activityId, userId)); }

selectByIdForUpdate 会对活动行加锁，并发请求串行执行，后到的请求就会看到最新的人数。这个方案逻辑简单、不易出错，唯一的代价是同一场活动的大量报名请求会排队。对校园活动系统来说，几百人的并发完全不是问题。

如果要进一步提升并发能力，可以用 Redis 的 DECR 做计数器。报名前对 key 执行 DECR，返回值小于 0 说明满员。但这样要维护缓存和数据库的一致性，复杂度上去了，毕业设计阶段没必要。选价廉物美的方案就好。

另外有两条保险必须加：报名表建立唯一索引 (user_id, activity_id)，数据库层面拒绝重复报名；服务里再用 EXISTS 查询提前拦截，给用户友好的“你已报名”提示。前端再配合按钮置灰，三重保障，基本不可能重复报。

3.4 文件上传与图片压缩

活动要传封面、比赛要交作品材料，文件上传跑不掉。我的做法是：文件存本地磁盘，用 Nginx 做静态映射。文件路径配置成可配置项，部署时改配置就行，不用动代码。

文件上传的坑主要在命名和校验。文件名不要用用户上传的原名，中文会乱码，还会有人传带路径的文件名。统一用 UUID + 原扩展名拼接，扩展名从原始文件名里提取，转成小写。类型校验不能只信前端，后端必须做二次校验，用扩展名 + Content-Type 双重判断，白名单只允许 jpg、png、pdf、zip 这些常见类型。

大小限制也要设。Spring Boot 的配置：

spring: servlet: multipart: max-file-size: 10MB max-request-size: 20MB

图片建议压缩后再存。我用 Thumbnailator 做封面压缩，把上传的原图压缩到宽度不超过 800px、质量 0.8，一张 2MB 的照片能压到 200KB 左右，列表页加载速度明显提升。这个细节很多同学会漏，但实际体验差距很大。

最后说下路径拼接。不要用硬编码的 "D:\xxx" 或 "/data/xxx"，用配置项 + File.separator 拼，否则代码从 Windows 迁到 Linux 全盘报错。上传目录创建前先 mkdirs()，不然第一次上传会直接 FileNotFoundException。

4. 前端实现：Vue3 + Element Plus

4.1 项目骨架与路由权限

前端项目的目录结构我是这样组织的：

src/ api/ # 接口定义，按模块拆分 assets/ # 静态资源 components/ # 公共组件 router/ # 路由配置 stores/ # Pinia views/ admin/ # 管理端页面 user/ # 用户端页面 login.vue home.vue

路由权限用全局前置守卫控制。meta 里写 roles，进入路由前判断当前用户角色是否匹配：

router.beforeEach((to, from, next) => { const userStore = useUserStore() if (to.meta.public) return next() if (!userStore.token) return next('/login') if (to.meta.roles && !to.meta.roles.includes(userStore.role)) { return next('/403') } next() })

这个方案就是静态路由 + 前端判断，简单直接，角色就三种，没必要后端动态生成路由。登录页存 token 和用户信息到 Pinia 和 localStorage，刷新页面后重新拉取一次用户信息就好。

axios 封装一定要做好。请求拦截器统一加 Authorization 头，响应拦截器统一处理 code：业务成功返回 data 直接给页面；401 跳登录；403 跳无权限页。这样业务代码里就不用写一堆错误分支了：

service.interceptors.response.use(res => { const data = res.data if (data.code === 200) return data.data if (data.code === 401) { store.clear(); router.push('/login') } if (data.code === 403) { router.push('/403') } ElMessage.error(data.message) return Promise.reject(data) }, err => { ElMessage.error('网络异常') return Promise.reject(err) })

4.2 活动大厅与报名状态联动

活动大厅是学生用得最多的页面，考验的是“状态展示的准确性”。每个活动卡片要展示标题、时间、地点、分类、剩余名额、状态按钮。状态按钮有几种情况：未到报名时间显示“未开始”，报名中显示“报名”，已截止显示“已截止”，已报名显示“已报名”，名额满了显示“名额已满”。

这里有个细节：剩余名额不要直接展示数据库里的 currentRegisters 和 capacity 相减，因为热门活动报名实时变化，最好通过后端返回的剩余名额字段展示，并发下数据更准确。前端拿到剩余名额后，还要结合报名状态做按钮逻辑：

<el-button v-if="activity.registered" type="info" disabled >已报名</el-button> <el-button v-else-if="activity.displayStatus === 'REGISTERING' && activity.remain > 0" type="primary" @click="handleRegister(activity)" >报名</el-button> <el-button v-else type="info" disabled >{{ statusText(activity) }}</el-button>

活动详情页我喜欢展示一个倒计时。报名截止时间减去当前时间，每秒刷新一次。这个功能很加分，学生能看到“还剩 2 小时 15 分”，紧张感拉满，报名率也会高一些。前端写个简单的 setInterval 就能搞定，记得页面卸载时 clearInterval，防止内存泄漏。

列表页的分页和筛选要注意：按分类筛选、按状态筛选、关键词搜索，全部通过 URL query 参数带到后端。前端不要自己过滤全集数据，数据量一大就卡死。

4.3 后台管理页与签到页

后台管理页面核心是两个：活动表单和报名名单。

活动表单用 Element Plus 的 el-form 加规则校验。时间选择器返回的是数组，提交前要拆成 startTime 和 endTime 两个字段。图片上传用 el-upload，拿到返回的 URL 后塞到 form 里，提交时一起带走。状态是“草稿/待审核”时，表单可以继续编辑；一旦进入审核流程，编辑按钮就要禁用，防止数据改了审核记录对不上。

报名名单页面建议做成“表格 + 搜索 + 批量操作”。表格列出每个报名者的姓名、学号、报名时间、签到状态；搜索框按学号/姓名过滤。导出 Excel 用 Hutool 的 ExcelWriter，一个方法就能生成：

ExcelWriter writer = ExcelUtil.getWriter(true); writer.write(list, true); response.setContentType("application/vnd.openxmlformats-officedocument.spreadsheetml.sheet"); response.setHeader("Content-Disposition", "attachment;filename=signup.xlsx"); ServletOutputStream out = response.getOutputStream(); writer.flush(out, true); writer.close();

签到页是组织者在活动现场用的。三种方式：手动输入学号签到、列表勾选批量签到、扫码签到。扫码需要引入二维码解析依赖，扫码枪一般直接输出键盘事件，前端监听回车就能模拟输入，成本最低。签到状态实时更新到后端，已经签到的学生再次扫码会提示“重复签到”，防止现场混乱。

5. 常见问题与排查技巧实录

5.1 CORS跨域与预检请求

前端和后端端口不同，跨域是刚起步就会遇到的问题。浏览器报 CORS error 或者报错信息里带 Access-Control-Allow-Origin 字样，基本就是跨域没配好。Spring Boot 里写一个 CorsFilter 或者在 Security 配置里加 CorsConfigurationSource 就行。

有个坑特别容易踩：用了 Spring Security 后，预检请求 OPTIONS 会被拦截。要显式放行 options 请求，或者把 CorsFilter 配置到 Security 之前。我建议在 SecurityFilterChain 里直接加上http.cors()，再配一个全局 CorsConfigurationSource，这样最干净。

5.2 JWT拦截与放行路径

登录接口被拦截、登录之后调业务接口 401，十有八九是放行路径配错。注意路径匹配规则是精确的：/api/auth/login配了放行，但/api/auth/**没配，其他用户接口还是会拦。Knife4j 的/doc.html、/webjars/**、/v2/api-docs要全部放行，否则接口文档白屏。

还有一个细节：静态资源“uploads”目录也要在 Security 里放行，否则上传后的图片访问时会被拦截，页面图裂。排查这种问题的方法很简单：打开开发者工具看 Network，401 就看拦截器日志，确认是哪个 Filter 返回的。

5.3 活动人数超卖

如果没用我前面讲的行锁或 Redis 计数，测试阶段偶尔会出现“报名成功但人数超了”的情况。排查时先看日志里是否有两条 update 同时成功，十有八九是没有加锁。修复方法就是把“查人数+扣减”放到同一个事务里，并用行锁保证串行。再加唯一索引防重复。这属于经典并发问题，能讲清楚原理是加分项。

5.4 时间显示差了8小时

前端显示的活动时间比实际少了 8 小时，典型的时区问题。原因一般有两个：MySQL 连接串少了 serverTimezone=Asia/Shanghai；或者后端返回 LocalDateTime 时 Jackson 序列化格式没指定。解决办法是连接串显式指定时区，同时全局配置 Jackson 时间格式：

spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: Asia/Shanghai

前端拿到的时间如果是字符串就格式化展示，如果是时间戳就用 dayjs 转。统一策略：后端全部返回字符串（yyyy-MM-dd HH:mm:ss），前端不做额外转换，问题最少。

5.5 文件上传后访问404

上传成功后文件能存下，但浏览器访问 URL 返回 404，多半是 Nginx 映射没配。Nginx 静态映射要在 server 块加上：

location /uploads/ { alias /data/campus-activity/uploads/; }

还有一个常见错误：数据库里存的 URL 是相对路径 /uploads/xxx.jpg，前端在开发环境访问时自然连到前端端口，404 是必然的。建议后端返回 URL 时拼接完整的后端地址，或者前端请求拦截器里加 baseURL 前缀。我的做法是后端存相对路径，前端在展示时加环境变量前缀。

5.6 部署环节的坑

打包时前端要生成 dist 目录，后端打成 jar 包。前后端分离部署有两种方式：一是 Nginx 托管前端并反向代理后端/api路径；二是直接把 dist 复制到 Spring Boot 的 static 目录当一体包。校园系统部署在实验室一台机器上，我推荐第二种，少一个组件，重启也简单。

一体包只需要把前端 dist 目录里的文件复制到src/main/resources/static/下，重新打包即可。注意前端路由如果用了 history 模式，刷新页面会 404，要改成 hash 模式，或者 Nginx 配 try_files。图省事就直接用 hash 模式，不要有偶像包袱，稳定第一。

最后说点个人感受

这类系统做到后面你会发现，技术本身并不难，真正花时间的全是业务细节：状态什么时候能变、报名到底什么时候截止、签到重复了怎么处理、导出名单字段对不对。把状态机和并发控制想清楚，整个项目就成了一大半。

我在类似项目里带过好几个新人，最容易出的问题不是写不出代码，而是没想清楚就开工，做到一半推翻重来。先画状态流转图、定接口字段、建表，再动手写代码，节奏会顺很多。

如果你正在做类似的校园管理系统，我的建议很直接：先把“活动状态机”和“报名并发控制”这两个点啃下来，其余的 CRUD 只是体力活。把这套逻辑跑通后，再往里面加消息通知、数据大屏、社团管理，都是顺着这份地基往上盖楼的事。