校园活动管理系统源码与开题：状态机、名额并发与签到核验

1. 校园活动管理系统这个题目，年年有人做，年年有人做崩

每年到了选题季，后台收到最多的私信之一就是“校园活动管理系统怎么做”。这个题目本身没有任何问题，它是最典型的业务管理系统，需求真实、边界清晰、工作量可控，答辩时老师也听得懂。真正让人翻车的地方，往往不在代码，而在于从选题到开题、从建表到答辩这条链路上，有一连串看起来不起眼、实际能拖死人细节。我见过太多同学，开题报告写了十几页，系统跑起来只有增删改查四个页面，老师一句“你这个和网上下的有什么区别”就把人问住了；也见过代码写得不错，结果开题里写的技术栈是SSM，交付时换成了Spring Boot，前后对不上，被追问半天。

所以这篇我想聊的不是“怎么从零写一个系统”这种虚的东西，而是拿“校园活动管理系统（源码+开题）”这个具体题目当样本，把一件事讲透：一个看起来平平无奇的业务系统，怎么在开题阶段就把逻辑立住，在实现阶段把边界守住，最后拿出一个能自圆其说、能当场演示、还能经得起追问的成品。适合正在准备毕业设计的学生，也适合刚接手类似管理类项目、想理清业务链路的开发者。哪怕你不做校园场景，这套拆解思路换到场馆预约、社团管理、志愿时长统计上，基本是通用的。

我先给一个判断标准，后面所有内容都围绕它展开：一个活动管理系统做得好不好，看的不是页面多漂亮，而是“活动从生到死”这条状态链有没有闭环，以及“人”和“名额”这两个资源有没有被正确地约束住。把这两件事想明白，开题报告的思路自然就出来了，代码也不会写成一堆孤立的表。

1.1 先搞清楚市面上三类成品各自的问题在哪

动手之前，得知道自己要做的这个东西，市面上大概有几种形态。我大致归成三类，每一类的坑都不一样。

第一类是纯CRUD教学模板。特点是一张活动表、一张用户表、一张报名表，页面上活动列表、活动详情、报名按钮、我的报名，加起来七八个接口。这类东西最大的问题不是功能少，而是没有“状态”。活动一旦创建就永远是可报名状态，过期了不会自动关闭，名额满了靠前端隐藏按钮，后端根本不管。老师稍微认真一点，随便造两条数据并发提交一下，就露馅了。

第二类是校园App里的活动模块。这类产品形态相对成熟，报名、签到、核销、评价都有，但它是嵌在超级App里的，你没法单独抽出业务逻辑来答辩。很多同学拿这类产品截图当“参考”，结果开题报告里的功能列表写得像产品需求文档，实现的时候一个都落不了地。

第三类是往届学长的半成品源码。这类东西最危险。表面上看功能齐全，代码一打开，Mapper里全是select *，Service层一个方法两百行，注释只有一句“查询活动列表”。你改一个字段，能顺着牵出五处报错。更麻烦的是答辩时你自己都讲不清这段逻辑为什么这么写。

我个人的建议是：把这三种当成“功能清单的参考”，而不是“代码的参考”。功能上你确实需要覆盖活动发布、审核、报名、签到、统计这几块，这是业务闭环的最低要求；但代码结构必须自己搭，哪怕只有十几个接口，也要分层清楚、命名统一，因为老师最常问的那句“这部分是你自己写的吗”，答案不在嘴上，在你打开IDE的那三十秒里。

1.2 开题阶段最容易埋的三个雷，后面全是债

很多同学觉得开题就是填个表、走个流程，随便写写等答辩再补。我经手的案例里，开题埋雷导致后期返工的比例高得离谱，主要集中在三个地方。

第一个雷是技术栈写得太花。开题报告里写着“采用微服务架构、Redis集群缓存、消息队列削峰”，实际交付是一个单体应用加MySQL。评审老师不一定懂技术细节，但他会记住你写过什么，答辩时对照着问一句“你的消息队列用在哪了”，你就得现编。技术栈的唯一原则是：写进去的每一项，你都能指出对应的代码位置。用不到Redis就别写，用不到分布式就别提，老老实实写Spring Boot + MyBatis-Plus + MySQL + Vue，没人会因为这个扣分。

第二个雷是功能列表写成许愿池。动不动列二十几项功能，人脸识别签到、智能推荐活动、AI审核内容全写上。结果是工作量爆炸，最后大部分功能只做了个入口。更尴尬的是，功能列表和数据库表对不上——你写了“活动评价体系”，结果库里只有一张评论表，连评分字段都没有。

第三个雷是研究意义写成套话。整段都是“提高了效率”“促进了信息化建设”这类谁都能套的话。真正有意义的部分是：你解决了现有做法中的哪个具体不便。比如线下报名靠班群接龙，人数统计靠人肉数，名额超额了还要一个个私聊劝退——这才是你系统存在的理由，写得越具体越可信。

提醒一句：开题报告里的每一句话，都要预设“老师会拿它对照你的系统”。写之前先问问自己，这句话对应的页面或接口在哪。

2. 开题报告不是走流程，六个问题写透了评审自然过

我在帮人看开题的时候，习惯用六个问题去套：为什么做、别人做到什么程度、你要做哪些事、用什么做、凭什么做得完、做完长什么样。这六个问题分别对应选题背景、国内外研究现状、研究内容、技术路线、可行性分析、进度安排与预期成果。听起来像八股，但确实好用，因为这正是评审老师的思维路径。下面挑三个最容易写砸的说。

2.1 选题背景：把“痛点”落到具体场景，别停在宏观描述

大部分开题报告的背景段落是这么写的：随着高校信息化建设的不断推进，校园活动管理的信息化水平有待提高……这种句子放在任何题目里都成立，也正因为如此，它等于什么都没说。

有效的写法是从一个具体场景切进去。比如：某高校某学院每学期要组织十几场讲座、比赛、志愿服务活动，组织流程长期依赖班级群通知加在线表格收集。组织者面临三个实际问题：一是报名信息分散在多张表格里，重复报名、临时退出无法及时同步；二是活动名额靠人工把关，热门活动经常超额，冷门活动报名不足也无从调剂；三是活动结束后，参与记录散落在各处，综合素质测评需要参与证明时只能靠人工翻记录。

你看，同样是讲背景，后者的每一句都能对应到你系统里的一个模块：报名去重对应唯一约束，名额控制对应库存扣减，参与记录对应签到与归档。背景写得越具体，后面的功能设计就越像是“被需求推出来的”，而不是“为了凑功能硬加的”。这是开题报告里性价比最高的一段。

顺便说一个小技巧：背景里可以适度提一下“现有做法”的成本，比如“一场两百人的活动，人工核对报名与签到平均需要两小时”，这种量化的描述不需要特别精确，但能让老师立刻感知到问题的分量。当然别编得太夸张，说自己学院一年办三千场活动，那反而显得不真实。

2.2 研究现状：不是罗列产品，而是找出“我补的那块空白”

国内外研究现状这一段，很多人的处理方式是打开应用商店，把几个校园类App的名字和功能列一遍，再加一句“功能较为完善，但针对性不强”。这种写法的问题在于，它没有推出你的位置。

比较稳的思路是分两层。第一层讲通用平台，它们的优势是功能全面、用户基数大，劣势是针对单个学校的组织流程适配不足，比如学院级的活动审核链路、特定类型的志愿时长认定，很难在通用产品里配出来。第二层讲同类毕设作品，普遍存在的问题是重展示轻业务，页面做得花哨，但状态流转不完整，名额并发、签到核验这类真正需要设计的地方被绕过去了。

然后你的落脚点就出来了：不做大而全的平台，聚焦“院系级活动的全流程闭环”，把状态机、名额约束、签到核验这三件事做扎实。这个定位听起来朴素，但它诚实、可交付、有明确边界。答辩时老师问“你的创新点在哪”，你答“我把报名名额的并发问题用数据库条件更新解决了，并且活动状态是自动流转而不是手动改的”，比答“我加了智能推荐算法”要可信得多。

2.3 研究内容与进度安排：功能清单必须能反推出数据表

研究内容这一段最忌讳写成产品宣传语。我建议直接用“模块 + 动作 + 约束”的句式来写，写完自己检查一遍，每个模块能不能对应到至少一张表。

比如这么写：

• 活动管理模块：支持活动的新建、编辑、提交审核、上下架与归档，活动状态由时间与审核结果共同驱动，不允许跨状态跳转。
• 报名管理模块：支持学生报名、取消报名、管理员代报名，同一用户对同一活动仅允许一条有效报名记录，名额扣减在数据库层做条件更新。
• 签到核验模块：支持动态签到码生成与核销，签到码携带时效签名，过期或重复使用均校验失败。
• 统计报表模块：按活动、按院系、按时间段统计报名人数、实际签到人数与到场率，支持导出。

这样写的好处是，你后面建表的时候几乎是照抄：活动表、报名表、签到记录表，字段和约束都是现成的，不会出现“功能写了但没地方落”的情况。进度安排同理，别写“第1-2周完成需求分析”这种放到任何项目都成立的排期，要写成“第3周完成活动状态机与报名唯一约束的设计并在库表落地”，这样才看得出你真的推进了。

3. 把活动当成一个有生命周期的对象，模块划分自然就清楚了

很多人做这个系统，是先把页面画出来，再倒推接口和表。这个顺序反了，做出来的东西一定是散的。我的做法是先画出活动的状态流转，再围绕状态去切模块。

3.1 角色与权限：三种人，三套动作集合

校园活动这个场景，角色其实很清晰，不需要设计得多复杂。学生：浏览、报名、取消、签到、查看自己的参与记录。活动组织者（可以是学生干部，也可以是老师）：创建活动、提交审核、查看本活动的报名名单、发起签到、导出参与名单。系统管理员：审核活动、管理分类与场地、处理违规报名、查看全局统计。

真正的难点不在角色多少，而在于权限的粒度。比如“活动组织者”这个角色，他只能编辑自己创建的活动，不能编辑别人的；活动一旦进入“进行中”，就不允许再修改时间地点；管理员审核通过之后，组织者再改核心字段就需要重新走审核。这些规则如果不在设计阶段想清楚，后面只能靠前端藏按钮，后端裸奔，一测就穿。

我用一张权限矩阵表来说明会更清楚，这张表可以直接放进开题报告，也可以在答辩时作为讲解材料：

这张表的价值在于，它把“权限”从一句抽象的话变成了可验证的规则。写代码的时候，每个接口进来先对照这张表判一次，就不会出现学生调管理员的接口还能成功的情况——这种漏洞在被老师随手一试的时候特别显眼。

3.2 核心表结构与状态机：这是整个系统的地基

表设计这块，我给一个可以直接用的最小集合。需要说明的是，这是我根据常见实践整理的一版，具体字段可以按学校情况增减，但骨架基本就是这样。

• 用户表：主键、账号、密码（存哈希）、姓名、学号/工号、所属院系、角色标识、状态。
• 活动表：主键、标题、封面、简介、分类、主办方、场地、开始时间、结束时间、报名截止时间、名额上限、已报名人数、状态、创建人、审核人、审核意见。
• 报名表：主键、活动ID、用户ID、报名时间、报名状态（有效/已取消/已签到）、取消时间。这里必须加**(活动ID, 用户ID)的唯一约束**，只允许一条有效记录，取消后再报名就把状态改回来，不要新增行。
• 签到记录表：主键、活动ID、用户ID、签到时间、签到方式、核验人。
• 审核记录表：主键、活动ID、审核人、审核结果、意见、时间。这张表很多人会省掉，但它在你被问“审核流程怎么留痕”的时候非常有用。
• 分类表、场地表：作为基础字典，避免分类写成自由文本导致统计口径混乱。

状态机是这块的重点。我给一条经过实践检验的链路：

草稿 → 待审核 → 已通过（待开始）→ 报名中 → 进行中 → 已结束 → 已归档，另外从待审核可分叉出“已驳回”，驳回后可回到草稿修改再提交。

这里面有两个细节必须做进去，否则系统就是假的。第一，状态不能全靠人工点。“报名中”和“进行中”的切换应该由当前时间和报名截止时间计算得出，而不是让管理员手动去改。第二，状态只进不退。已结束的活动不能被改回报名中，这需要在更新语句里带上原状态作为条件，而不是先查再改——先查再改在并发下会出现状态被覆盖的情况。

已报名人数这个字段要不要冗余存？我建议存，但必须配合条件更新使用，不能靠count(*)现算。原因很简单，列表页要显示剩余名额，每个活动都去count一次，几十条数据就是几十次聚合查询，页面会明显变慢。冗余字段加条件更新，是这类场景里最省事也最稳的做法。

3.3 名额并发：看起来是个小问题，其实是唯一的“技术含金量”

如果要在这个项目里找一个真正能体现设计能力、又能在答辩时讲出东西的点，那就是名额并发。这也是绝大多数同类模板直接绕过去的地方。

问题场景很具体：一个活动限额50人，报名截止前最后几分钟，几十个人同时点报名。如果代码是“先查已报名人数，判断小于50，再插入报名记录并更新人数”，那么在并发下必然超卖——两个请求同时查到49，都判断通过，最后变成51人。

解决办法不复杂，核心思路是把判断和扣减合并成一条原子操作，交给数据库去保证。具体做法是在更新语句里带上条件：

UPDATE activity SET enrolled_count = enrolled_count + 1 WHERE id = #{activityId} AND status = 'SIGNUP' AND enrolled_count < capacity;

这条语句执行后返回受影响行数，如果返回0，说明名额已满或活动已不在报名状态，直接抛出业务异常即可。整个过程没有先查后改，天然避免了竞态。取消报名则是反向操作，enrolled_count - 1，并加上enrolled_count > 0的保护条件。

这里有个容易忽略的点：报名表插入和人数更新必须在同一个事务里，否则会出现人数加了但报名记录没进去、或者反过来。另外，唯一约束冲突要单独捕获，转换成“你已经报过名了”这类友好提示，而不是把数据库异常直接甩到前端。

如果你的场景并发量真的很小，比如就是学院内部几十个人用，那也可以退一步用乐观锁版本号，逻辑更好理解。但我不建议用synchronized或者应用层锁，因为一旦部署多实例就失效，而且老师问一句“你这个锁在多台服务器上还有效吗”，很难圆回来。

4. 技术选型与源码落点：每一行代码都要能说清为什么

4.1 后端分层：把“能跑”和“能讲”区分开

技术栈我建议就用最主流的组合：Spring Boot + MyBatis-Plus + MySQL，前端 Vue 3 + Element Plus。理由不是它先进，而是资料密度最高、出问题最容易搜到答案、答辩老师最熟悉。毕业设计阶段，选一个你三天能跑通的技术栈，比选一个听起来高级但要折腾两周的栈划算得多。

分层上，Controller 只做参数校验和权限判断，Service 承载业务规则（状态流转、名额扣减、唯一性校验），Mapper 只做数据访问。这个划分不是形式主义，它的实际好处是：当老师问“活动状态是怎么控制的”，你可以直接打开 Service 层指给他看，而不是在一个八百行的 Controller 里翻。

参数校验用@Valid加注解就够了，别在 Controller 里写一堆 if。权限判断我倾向于用拦截器加自定义注解的方式，简单直接：

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

拦截器里解析当前登录用户，比对注解声明的角色，不匹配直接返回 403。这套东西几十行代码就能写完，比引入完整的权限框架轻得多，讲解的时候也讲得清楚。

4.2 三段可以直接抄的源码，重点是理解它在防什么

第一段：报名核心逻辑。这段的关键在于顺序——先做条件更新抢名额，成功后再插报名记录，任何一步失败整体回滚。

@Transactional(rollbackFor = Exception.class) public void signUp(Long activityId, Long userId) { Activity act = activityMapper.selectById(activityId); if (act == null) throw new BizException("活动不存在"); if (act.getSignupDeadline().isBefore(LocalDateTime.now())) throw new BizException("报名已截止"); int affected = activityMapper.occupySeat(activityId); if (affected == 0) throw new BizException("名额已满或活动不可报名"); try { signupMapper.insert(Signup.builder() .activityId(activityId).userId(userId) .status(SignupStatus.VALID) .createTime(LocalDateTime.now()).build()); } catch (DuplicateKeyException e) { throw new BizException("你已报名该活动"); } }

注意这里有个坑：唯一约束冲突是在插入时才抛出的，而名额已经在上一步扣掉了。事务回滚会把它恢复，但如果你的异常被捕获后没有继续向外抛，事务就不会回滚，人数就永久多扣了一个。所以捕获DuplicateKeyException之后要么重新抛出业务异常，要么手动标记回滚，这一点我在早期项目里栽过，排查了半天才发现是人数对不上。

第二段：动态签到码。静态二维码截图转发是签到环节最常见的作弊方式，处理办法是让码带时效。生成时把活动ID、时间片（比如当前分钟数）、密钥拼起来做哈希，取前若干位作为token，页面定时刷新。核验时用同样的方式算一遍，比对是否一致，并容许前后各一个时间片的误差。

public String genToken(Long activityId, long slot) { String raw = activityId + ":" + slot + ":" + SECRET; return DigestUtils.md5DigestAsHex(raw.getBytes()).substring(0, 8); }

这个方案谈不上多安全，但对校园场景完全够用，而且实现成本极低，答辩时讲出来也算是一个“有思考的设计”。如果有精力，再给每个用户加一条签到记录的唯一约束，防止同一场活动被重复签到。

第三段：报表导出。用 EasyExcel 注解式导出，几十行搞定，注意两点：一是导出数据量大时用分页查询，别一次性全查出来；二是时间字段格式化好，中文表头直接写在注解里，省得前端再处理。

@ExcelProperty("活动名称") private String title; @ExcelProperty("报名人数") private Integer enrolledCount; @ExcelProperty("实际签到人数") private Integer signedCount;

导出功能看起来不起眼，但它是答辩演示时的加分项。老师看多了只能增删改查的系统，一个能点导出、能生成到场率统计的系统，印象分会明显不同。

4.3 前端不用做得漂亮，但流程必须走得通

前端我不建议花太多时间在视觉上，Element Plus 默认样式足够用了。真正要花功夫的是流程的完整性：学生从活动列表点进详情，报名按钮的状态要根据是否已报名、是否已满、是否截止动态变化；组织者从活动管理进入报名名单，能看到实时的报名人数；管理员审核页面要有通过和驳回两个动作，驳回必须填意见。

一个具体的注意点：按钮状态不要只靠前端判断，但前端判断必须做，因为它决定了体验。后端的条件更新是底线，前端的置灰是礼貌，两者缺一不可。很多同学只做了一边，要么点了没反应，要么点了报错。

5. 从本机跑通到上台演示，中间还差着三道坎

5.1 数据库脚本和初始化数据，比你想的重要

交付源码的时候，sql文件是必带的，但很多人给的脚本只有建表语句，跑起来一个数据都没有，老师想点一下报名都无从下手。我的做法是准备两份脚本：schema.sql只放建表和索引，data.sql放初始化数据——至少三个角色各一个账号、五到八个覆盖不同状态的活动（草稿、待审核、报名中、已结束各来一个）、几十条报名记录。

这样做的实际收益是，你部署到任何一台机器上，两条命令就能看到一个“像真的”的系统。演示的时候不需要现场造数据，减少翻车概率。活动数据尽量造得真实一些，别用“测试1”“测试2”这种，换成“春季校园读书分享会”“院系篮球联赛”之类，观感差别很大。

索引这块顺带提一句，报名表和活动表上按活动ID、用户ID、状态这些高频查询字段建索引就够，别建一堆用不上的。老师如果问起优化，你能说清“这个索引是为了支撑按状态筛选活动列表”就足够了。

5.2 演示前必须走一遍的三件事

第一件，清空并重新导入数据。你自己调试时留下的脏数据，很可能导致演示时列表里冒出乱七八糟的记录。演示前用干净的脚本重跑一次。

第二件，把关键流程完整走一遍，包括失败路径。比如故意报一个已满的活动，看提示是不是友好；故意用学生账号调管理员的接口，看是不是被拦住。失败路径的演示往往比成功路径更能说明你考虑过边界。

第三件，准备一段三分钟的口头讲解。不是念PPT，而是讲清楚“这个活动从创建到归档经历了哪些状态、每个状态谁能操作、名额是怎么保证不超卖的”。这三分钟讲顺了，后面的提问基本都在你的节奏里。

5.3 老师最可能追问的几个问题，提前想好答案

我把高频问题整理成了一个对照表，建议答辩前逐条过一遍，能答上来心里就有底了。

这些问题没有标准答案，但有一个共同点：答案必须指向具体代码或具体表字段。凡是只能用概念回答的，说明那块你其实没真正做进去。

最后分享一个我自己的体会。这类管理系统的价值，从来不在功能数量，而在“每个功能都站得住”。我见过功能列表写了三十项、结果一半是空壳的系统，也见过只有十几个接口、但每个状态流转都严丝合缝的系统，后者的评价永远更高。所以别贪多，把活动状态、名额约束、签到核验这三根柱子立稳，剩下的统计和导出都是锦上添花。真要说还有什么可以继续往下做的，我一般会建议加一个“活动归档后的参与记录导出”，因为这东西直接对接综合素质测评的实际需求，用得上，也讲得出理由。