简介：本资源是一套完整的校园活动管理系统毕业设计实现方案，面向计算机相关专业本科生及Web开发初学者，聚焦高校第二课堂管理场景，解决活动申报、审批、发布、报名与数据统计等核心业务流程的数字化落地问题。压缩包共2011个文件，主体为1679个Markdown文档（含需求分析、数据库设计、接口说明与部署手册）、290个JavaScript文件（涵盖前端交互逻辑与Vue组件）、28个JSON配置文件（用于菜单权限与活动状态定义），整体体积达170.8MB，结构层次分明，便于分模块学习与调试。已有40人下载学习，资源中包含可运行的前后端代码、详尽的系统设计文档、标准化的API接口规范及典型业务场景的测试用例，特别适合毕业设计选题参考、全栈开发实践训练及校园信息化项目复用。 大学里做过活动组织的人，基本都体会过那种被Excel表格和微信接龙支配的恐惧。报名信息散落在各个群聊、纸质签到表最后不知道丢到哪里、活动冲突没人发现、第二课堂学分统计的时候对着几百条聊天记录翻到眼瞎。我这里说的，就是针对这些真实痛点做的校园活动管理系统，从需求分析到上线部署完整走了一遍，技术栈选的是Java Web方向最经典的组合——JSP + Servlet + MySQL，算是一个覆盖面比较全、又能作为毕设或课程设计直接参考的实战项目。无论你是准备动手做类似选题的学生，还是想把管理流程彻底数字化、不想再手工统计的活动组织者，这篇文章都值得看完。系统覆盖了活动发布、在线报名、签到核销、数据统计四个核心环节，我会把每一步的设计思路和关键代码拆开讲清楚，尤其是那些文档里不常写的坑、容易忽略的边界情况，也会一并交代。
1. 这个系统到底解决了校园活动管理里的哪些真实问题
1.1 从一场失败的社团招新说起
先讲个具体场景。去年秋季学期我帮一个社团做招新活动统计，报名方式是各部门自己拉群、填在线表格，结果到了活动当天，报名80人实到50人，问起来有人说没看到通知，有人说以为不用签到，还有几个同学直接跑错了教室——因为同一天同一个时间段，另一个社团在隔壁教室办了活动，两边的人撞在一起，场面一度混乱。活动结束后要报账、要录学分，各种信息从聊天记录里往上扒，来回拉扯了整整两周。
这个经历让我下定决心，校园活动管理这件事必须有一个统一的系统来承接。它需要解决的，不只是"报名"这一个动作，而是从前端的活动信息触达、报名筛选，到活动现场的签到核销，再到活动结束后的数据沉淀，全链路的流程化管理。活动中产生的数据如果只停留在聊天记录里，那它就无法被复用、被统计、被追溯，而系统的核心价值，恰恰是把这些分散的、非结构化的信息，变成结构化的、可持续使用的数据资产。
1.2 系统要服务的三类角色及各自的痛点
在设计系统前，我先梳理了使用这个系统的三类人群，他们的诉求和痛点完全不同。
- 普通学生（参与者）：需要快速发现感兴趣的活动、一键报名、收到活动时间地点提醒、现场签到不排队。最怕的是报名之后忘记时间、找不到地点，或者活动取消了没人通知。
- 活动组织者（社团/学生会干事）：需要发布活动信息、审核报名名单、查看报名人数、生成签到二维码、导出数据用于学分统计。最怕的是报名人数统计不准确、手动核对签到表耗时、活动冲突没发现。
- 系统管理员（团委/学工办老师）：需要审核活动是否合规、监控活动是否与课程时间冲突、查看各社团活动开展情况的数据报表。最怕的是活动信息不规范、学分造假、无法量化学生参与度。
三类角色的核心诉求交织在一起，就构成了系统的功能矩阵。我按照这个矩阵来规划模块，而不是一上来就堆功能页面，这样可以确保每个功能都有明确的使用场景和用户价值。
1.3 为什么选JSP + Servlet这套经典组合而不是花哨的新框架
技术选型上，我最终定的是JSP + Servlet + MySQL，没有用 Spring Boot，也没有用前后端分离。并不是说新框架不好，而是针对这个具体项目的定位，这套经典组合有不可替代的优势。
- 教学/毕设导向：这个项目的典型场景是课程设计或毕业设计。JSP + Servlet能完整展示HTTP请求处理、Session管理、JDBC操作、MVC分层这些Web开发核心原理，评审老师看得懂，你也能讲清楚。如果直接上Spring Boot，很多底层机制被封装掉了，答辩时反而容易被问住。
- 部署轻量：只需要Tomcat + MySQL就能跑起来，不需要Maven中央仓库下载几百MB依赖，对开发机配置不高的同学友好。我现在用的Tomcat 9 + JDK 8，部署没有任何兼容性问题。
- 跨浏览器兼容性好：因为服务端渲染，页面最终输出的是纯HTML，不存在前端框架版本引起的兼容问题。我在IE11、Edge、Chrome、Firefox上都测过，渲染效果完全一致。这一点对校园环境里大量老旧机房电脑来说很关键。
如果你以后想往Spring Boot迁移，这个项目的分层结构（Servlet控制层 + Service业务层 + DAO数据层）本身就是Spring MVC的雏形，迁移成本很低。
2. 数据库设计与用户认证：先把地基打牢
2.1 六张核心业务表的职责划分
数据库是一个管理系统的地基，表结构设计得好不好，直接决定后续功能开发的复杂度。我把整个系统拆成了六张核心表，每一张表的职责都足够单一。
| 表名 | 职责说明 | 关键字段 |
|---|---|---|
| t_user | 用户表，存储学生、组织者、管理员三类账号 | id, username, password, role, real_name, student_no |
| t_activity | 活动表，记录活动基本信息与状态 | id, title, category, location, start_time, end_time, max_people, status, creator_id |
| t_activity_audit | 活动审核记录表，保存审核链路 | id, activity_id, auditor_id, result, comment, audit_time |
| t_registration | 报名表，记录用户与活动的报名关系 | id, activity_id, user_id, register_time, cancel_time |
| t_checkin | 签到表，记录实际到场的核销记录 | id, activity_id, user_id, checkin_time, checkin_code |
| t_category | 活动分类表，支持分类筛选与统计 | id, category_name, sort_order |
这里有一个设计细节需要特别说明：报名和签到是分离的两张表，不是一对一的冗余关系。因为报名了不一定到场，到场了也可能没提前报名（现场补签），两种情况在数据模型上是两个独立的事实。分开存，统计"报名率"和"实到率"的时候各自查自己的表，逻辑非常清晰。如果你的需求里要求统计出勤率，这种设计会给你省很多事。
2.2 用户表的设计细节：密码加密与角色权限
用户表里最关键的设计决策是密码存储方式。明文密码是最常见的安全漏洞，绝对不能出现。我用的方案是加盐的MD5加密，虽然现在看MD5已经不算安全强度最高的算法，但在这个项目场景作为教学演示已经足够，而且相比BCrypt，MD5加盐的方法更容易在答辩时讲清楚原理。
public class MD5Util { public static String encrypt(String password, String salt) { String base = password + salt; return DigestUtils.md5DigestAsHex(base.getBytes(StandardCharsets.UTF_8)); } public static String generateSalt() { return UUID.randomUUID().toString().replace("-", "").substring(0, 8); } }注册时生成一个8位随机盐值，将"密码+盐值"拼起来做MD5，数据库里同时保存盐值和加密后的密文。校验登录时用同样的盐值再算一遍，比对密文是否一致。这样即使数据库泄露，由于每个人的盐不同，彩虹表攻击也很难生效。这是我在实际项目里坚持的一个底线，放到任何管理类系统里都适用。
权限控制我用了一个很轻量的方案：用户表中用role字段区分角色，取值分别是1（学生）、2（组织者）、3（管理员）。在Servlet的过滤器里拦截请求，按角色白名单控制访问权限。例如所有以/admin/开头的路径只允许role=3访问。这个方案比Spring Security轻量得多，对JSP+Servlet项目来说足够清晰可讲。
2.3 活动的四种状态流转与审核链路
活动不是一发布就能被所有人看到的。为了保证活动内容合规（没有商业广告、没有违规内容），我设计了"待审核 → 已通过/已驳回"的状态机，加上后续的"进行中 → 已结束"流转。活动表里用一个status字段表示，取值如下：
- 0 待审核：组织者提交活动后进入的状态，仅自己和管理员可见
- 1 已通过：管理员审核通过，对所有学生可见，可以报名
- 2 已驳回：管理员审核不通过，组织者可以修改后重新提交
- 3 进行中：活动开始后自动进入，前端标记为"进行中"，可签到
- 4 已结束：活动结束时间到达后自动进入，数据归档不可修改
审核动作单独拆了一张t_activity_audit表，每次审核都记录谁在什么时间做了什么样的决定。这个设计看起来多了一张表，但对后续查问题非常有帮助——如果有人投诉某场活动不合规，你可以很快查出审批链路上是哪一环出的问题。这种可追溯性，是管理类系统一个容易被忽视但很重要的能力。
2.4 一个典型的活动发布建表SQL实例
这里给出活动表的完整建表SQL，字段注释对上了设计文档里的每个需求点：
CREATE TABLE t_activity ( id INT PRIMARY KEY AUTO_INCREMENT COMMENT '活动ID', title VARCHAR(100) NOT NULL COMMENT '活动标题', category_id INT NOT NULL COMMENT '活动分类ID（关联t_category）', location VARCHAR(200) NOT NULL COMMENT '活动地点', start_time DATETIME NOT NULL COMMENT '开始时间', end_time DATETIME NOT NULL COMMENT '结束时间', max_people INT DEFAULT 0 COMMENT '人数上限，0表示不限', description TEXT COMMENT '活动详情描述', cover_url VARCHAR(255) COMMENT '封面图URL', status TINYINT DEFAULT 0 COMMENT '状态：0待审核/1已通过/2已驳回/3进行中/4已结束', creator_id INT NOT NULL COMMENT '创建人ID（关联t_user）', create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间' ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='校园活动信息表';注意编码用了utf8mb4而不是utf8，因为utf8在MySQL里是utf8mb3的别名，不支持emoji和部分生僻字。活动标题里如果有人放了emoji，用utf8会直接报错。这个坑我曾经踩过，当时查了好久才发现是编码问题。索引方面，start_time和status联合索引是查询频率最高的路径，务必加上。跨浏览器兼容性在这个环节的体现可能不太明显，但其实utf8mb4的字符集支持直接关系到页面表单在提交不同编码内容时的稳定性，所有浏览器最终都以UTF-8往服务端传数据，统一了编码反而省去了一堆乱码问题。
3. 活动发布与冲突检测：最容易忽略的业务规则
3.1 管理员审核到底在审什么
活动发布不是填个表单点提交就完了。组织者提交活动后，管理员需要核对几个关键维度，然后决定通过还是驳回。
- 时间合理性：活动开始时间不能早于当前时间，不能早于用户创建活动的时间，结束时间必须晚于开始时间。这是我做的第一层防线，前端表单上就做校验，后端Servlet进入Service层之前再做一次，避免有人绕过前端直接构造HTTP请求。
- 场地占用冲突：同一地点在同一时间段不能被两个活动同时占用。这是一个数据库层面就能查出来的规则：查找该location下是否存在时间段重叠的已通过活动。如果存在，管理员应当驳回或建议调整场地。
- 活动内容合规性：标题和描述不能包含违规关键词，这个我用了简单的关键词过滤，目前维护了一个黑名单词表，后续可以扩展接入更智能的内容审核方案。
3.2 时间重叠检测的SQL写法与边界条件
时间重叠检测是个看似简单实际容易写错的逻辑。两段时间存在重叠，等价于new_start < old_end AND new_end > old_start。但要注意边界条件：如果活动A的结束时间恰好等于活动B的开始时间（比如A是9:00-10:00，B是10:00-11:00），这不算冲突。所以SQL里要用严格小于而不是小于等于。
SELECT COUNT(*) FROM t_activity WHERE location = ? AND status = 1 AND ? < end_time AND ? > start_time;这个SQL里的两个问号参数分别传入新活动的开始时间和结束时间。执行后如果count大于0，说明存在同场地时间重叠的活动。我专门整理了边界测试用例：A活动9:00-10:00，B活动10:00-11:00应该通过；B活动9:30-10:30应该拦截；B活动8:00-9:30应该拦截（结束时间9:30晚于A的开始时间9:00）。把这些用例写进测试脚本，每次改代码都跑一遍，能有效避免回归问题。
更进一步，考虑到校园活动经常需要提前占场地，我在活动表里增加了一个"场地预约状态"逻辑：当管理员审核通过一个活动时，系统自动将对应场地在对应时间段标记为占用，释放则是活动结束时自动触发。这样即使有人先创建活动还没提交审核，也不会提前锁住场地导致误判。
3.3 并发冲突：两个活动同时申请同一场地怎么办
单纯的SQL查询在单用户场景没问题，但如果有两个组织者同时提交同一场地的申请，就可能出现"都查询到无冲突，然后都插入成功"的竞态问题。解决这个并发冲突，我用的是数据库层面的事务+行级锁。
@Transactional public void createActivity(Activity activity) { // 在事务内对场地记录加锁 venueDao.lockVenue(activity.getLocation()); // 再次检查时间冲突（此刻其他事务被阻塞） int count = activityDao.countConflictByLocation(activity.getLocation(), activity.getStartTime(), activity.getEndTime()); if (count > 0) { throw new BusinessException("该场地在所选时间段已被占用"); } activityDao.insert(activity); }这里的核心点是lockVenue操作。如果有一个venues表来维护场地信息，那就直接SELECT * FROM t_venue WHERE name = ? FOR UPDATE，悲观锁把这一行锁住，其他事务的同场地查询就必须等待。如果没单独建场地表，就只能考虑对location唯一索引做插入试探，复杂一些。我在系统里建了独立的场地表t_venue，这样锁行是干净的，也不会锁全表导致性能问题。这个细节虽然不复杂，但它是整个系统里"藏得最深但价值最高"的部分，面试或答辩时讲出来会加分不少。
3.4 跨浏览器的日期时间控件兼容性处理
时间选择是这个模块里最折磨人的部分。原生HTML5的<input type="datetime-local">在Chrome和Edge上很好用，但在Firefox旧版本和IE11上会退化成普通文本框，用户得手动输入"2025-03-18 14:30"这种格式，体验很差还容易输错。更麻烦的是，各浏览器对时间格式的解析有细微差异，同一个value在不同浏览器里toString的结果不一样，传到后端解析就容易出错。
我最终的方案是：页面用两个下拉框分别选日期和时间（日期用原生<input type="date">，时间用<input type="time">），在JS里拼成yyyy-MM-dd HH:mm:ss格式再提交。日期和时间控件在所有现代浏览器中支持性都很好，退化成文本框的概率低，而且即使用户的浏览器不支持，两个字段的输入格式也相对固定，后端容错容易处理。后端统一用SimpleDateFormat解析这个固定格式，彻底绕开了各浏览器之间的格式差异问题。
function buildDateTime() { const dateVal = document.getElementById('activityDate').value; const timeVal = document.getElementById('activityTime').value; if (!dateVal || !timeVal) { alert('请完整选择活动日期和时间'); return null; } // 统一格式，避免浏览器差异 return dateVal + ' ' + timeVal + ':00'; }这个看起来不起眼的处理，实际上是最能体现"跨浏览器支持"这个热词价值的地方。没有做兼容处理之前，用户用Firefox提交活动，后端收到的日期字符串可能是"2025/03/18 14:30"，用SimpleDateFormat的yyyy-MM-dd HH:mm:ss格式直接解析就报错。统一了前端输出格式之后，所有浏览器在这个环节上的行为就完全一致了。
4. 报名与签到：并发与防作弊的实战处理
4.1 报名接口的防超卖设计
报名模块是并发压力最大、最容易出bug的地方。热门活动（比如名家讲座、音乐会）开放报名后，同一秒内可能有几百个学生同时点击"我要报名"。如果不做并发控制，数据库里可能出现报名人数超过活动人数上限的数据。这和电商秒杀里的"超卖"问题本质上是同一个。
我的方案是：报名前先查当前报名人数和活动人数上限，如果已满就返回"已满员"。但这一步查询和后续的插入不是原子的，存在时间差。真正解决并发问题，靠的是在活动表上做一次带条件的原子更新：
@Transactional public boolean register(int activityId, int userId) { // 原子更新：仅当已报名人数小于上限时才能更新成功 int updated = activityDao.increaseRegisteredCount(activityId); if (updated == 0) { // 说明人数已满或活动不存在 return false; } // 插入报名记录 registrationDao.insert(activityId, userId); return true; }对应的SQL是：
UPDATE t_activity SET registered_count = registered_count + 1 WHERE id = ? AND registered_count < max_people;这个UPDATE语句本身是原子的，InnoDB引擎会锁定这一行，并发情况下只有一个事务能执行成功。先扣减名额再插入报名记录，保证了数据一致性。如果插入报名记录失败，事务回滚，名额也自动恢复。这是我比较满意的设计，既简单又可靠，比"先查再插"的方案结实得多。报名表本身也和活动表保持着一对多的关系，多场活动报名互不影响。
4.2 同一用户重复报名的拦截与幂等处理
有了上面的原子操作，还要解决重复报名问题。学生手一抖点了两次"报名"，如果系统没有拦截，就会出现两条报名记录。同一个事务里可以先查t_registration是否存在activity_id和user_id的记录，但因为并发，两条请求可能同时查询都发现不存在，然后都插入成功。为此我对t_registration表建立了唯一索引：
ALTER TABLE t_registration ADD UNIQUE KEY uk_activity_user (activity_id, user_id);这个唯一索引是最终的兜底防线，即使业务层没拦住，数据库也会拒绝重复插入。插入时DuplicateKeyException一经捕获，业务层返回"您已报名该活动，请勿重复操作"。幂等处理靠的就是这个唯一索引。这是我在网上看到不少项目里都容易忽略的点，很多人只做了代码层的判断，没有在最底层加约束，结果在高并发下还是出了问题。如果学有余力，还可以在前端做按钮置灰防止用户重复点击，但这只是优化体验，真正的保障必须落在数据库端。
4.3 签到功能设计：二维码是提升效率的最优解
传统签到是纸质名单打勾，人多的时候排队严重。我设计的是二维码签到流程：每个报名成功的学生，系统分配一个唯一的签到码（随机8位字母数字，可以做成二维码展示在手机上），活动开始时，组织者用管理端"扫码签到"功能扫码完成核销。
签到码的设计要求是足够随机且不可预测，防止有人伪造别人签到。用UUID截取或SecureRandom生成都可以，但要注意不要用简单的自增ID，因为自增ID可猜测，别人把你的ID减一就是另一个人的签到码，这是严重的安全漏洞。
public String generateCheckinCode() { String chars = "ABCDEFGHJKLMNPQRSTUVWXYZ23456789"; // 排除易混淆的字符 I、O、0、1 StringBuilder sb = new StringBuilder(); SecureRandom random = new SecureRandom(); for (int i = 0; i < 8; i++) { sb.append(chars.charAt(random.nextInt(chars.length()))); } return sb.toString(); }字符集里去掉易混淆的I/O/0/1是真实场景中总结出来的经验，不然用户报签到码的时候"那是字母O还是数字0"能纠结半天。签到和报名的角色分离也很重要，t_checkin表记录的是"实际到场"这一事实，即使用户没报名直接到现场，组织者也可以通过特殊通道（管理员手动添加）完成补签。这样"已报名未到场"和"未报名已到场"两种情况都能被数据准确地表达出来。
4.4 迟到早退与活动时长计算
如果只签到一个时间点，考勤的准确性还是不够。系统里我额外加了一个"活动时长"概念：签到记录里保存checkin_time，活动结束时组织者确认结束，系统自动计算活动时长，满足一定比例才算完整参与。具体规则可以做得很灵活——比如活动时长小于2小时的，签到即算参与；大于2小时的需要签到时长覆盖80%才算有效。这个规则在配置表里维护，管理员可以按活动类型调整。这套设计深挖下去就是一个完整的考勤系统，但在这个项目里按需裁剪，不用过度设计。活动状态从"进行中"变为"已结束"时，所有该活动的签到记录会统一打上"已完成"标记，方便后续统计。
5. 数据统计与可视化：让管理决策有据可依
5.1 活动维度的统计指标
数据统计模块是整个系统里最受管理员欢迎的部分。我把统计报表分为三个维度：活动维度、用户维度、时间维度。活动维度关注的指标包括：
- 活动报名率= 报名人数 / 活动人数上限，反映活动吸引力
- 活动实到率= 签到人数 / 报名人数，反映活动组织质量
- 活动分类分布：按t_category分组统计不同分类下的活动数量和报名总量
- 活跃组织者排行：按组织者发布的活动数量和总报名人次排序
这些指标用SQL聚合就能算出来，不重不复杂。比如实到率：
SELECT a.id, a.title, COUNT(DISTINCT r.id) AS register_count, COUNT(DISTINCT c.id) AS checkin_count, ROUND(COUNT(DISTINCT c.id) / COUNT(DISTINCT r.id) * 100, 2) AS attendance_rate FROM t_activity a LEFT JOIN t_registration r ON r.activity_id = a.id LEFT JOIN t_checkin c ON c.activity_id = a.id WHERE a.status = 4 GROUP BY a.id ORDER BY attendance_rate DESC;注意这里用了DISTINCT，因为一个用户报名后虽然不会重复，但理论上一名用户对同一活动只有一条报名记录和一条签到记录，都加了DISTINCT是为了防止未来业务扩展（比如允许多人代签）导致数据膨胀。这种防御性写法在数据统计里很重要。
5.2 展示端：用ECharts画图表还是用HTML表格
统计结果可视化有两种思路：纯HTML表格展示，或者引入ECharts做图表。我最终选择了二者结合：表格为主，图表为辅。原因很实际——表格能精确展示每一个数值，用户可以快速定位问题；图表则适合做趋势性的宏观观察（比如近三个月活动数量趋势）。ECharts的引入很简单，一个JS文件即可，但它依赖浏览器Canvas支持，在老旧浏览器上显示可能不正常。所以我的图表页面做了特性检测，如果浏览器不支持Canvas，自动降级为表格展示。这个降级方案就是在写"跨浏览器支持"这个关键词时很重要的一环。
if (window.CanvasRenderingContext2D) { // 初始化ECharts const chart = echarts.init(document.getElementById('trendChart')); chart.setOption(option); } else { document.getElementById('chartContainer').innerHTML = '<p>当前浏览器不支持图表渲染，请使用表格视图查看数据</p>'; document.getElementById('tableContainer').style.display = 'block'; }这段代码保留了基本的数据可读性，同时不会因为浏览器兼容问题导致整个统计页白屏。实际上，只要不强制依赖某个浏览器特性，页面的跨浏览器稳定性就能大幅提升。主流的Chrome、Edge、Firefox都是支持Canvas的，这个降级机制主要是为机房里的老旧IE兜底。
5.3 报表导出功能：从"看一眼"到"拿去用"
统计结果不仅要在线看，还要能导出归档、用于上报。我实现了导出Excel的功能，核心思路是生成CSV格式文件而不是真正的xlsx。CSV本质是纯文本，任何浏览器都能正常下载，而且乱码问题也好解决——在文件开头加上BOM标记\ufeff，用Excel打开时就能正确识别UTF-8编码。
response.setContentType("text/csv;charset=UTF-8"); response.setHeader("Content-Disposition", "attachment; filename=activity_report.csv"); PrintWriter out = response.getWriter(); out.print('\ufeff'); // 写入BOM头 out.print("活动名称,报名人数,签到人数,实到率\n"); // 遍历数据写行 out.flush(); out.close();实际使用中，组织者和老师最常用的是"某活动报名名单"导出，字段包含学号、姓名、学院、联系方式、报名时间，方便他们打印出来做线下核对。这个导出接口的权限控制必须做好，只允许该活动的组织者或管理员导出，学生角色的账号不能访问，否则个人隐私就泄露了。控制方式依然是在Servlet层做角色校验，同时还要校验当前登录用户是否为该活动的创建者（或者管理员）。双重校验能有效防止水平越权，比如学生A登录后拼URL直接导出学生B创建的活动名单。
6. 异常场景与部署实践：一些不能写在教科书里的经验
6.1 表单重复提交的拦截方案
活动报名的场景里，用户等不及响应，连点了几次提交按钮，或者网络不稳定时刷新重发，都可能造成重复报名。我在前端做了提交按钮置灰，但这只能挡住"正常用户手抖"，挡不住F5刷新或浏览器自动重放。后端代码里我加了一个简单的Token机制：进入报名页面时生成一个隐藏的randomToken存到Session里，提交报名时带上这个Token，后端比对成功后立即清空。这样同一个Token只能使用一次，F5刷新后Token已失效，后端直接拒绝。
// 生成Token写入Session String token = UUID.randomUUID().toString(); session.setAttribute("register_token_" + activityId, token); // 表单提交时比对并清空 String submittedToken = request.getParameter("token"); String sessionToken = (String) session.getAttribute("register_token_" + activityId); if (submittedToken == null || !submittedToken.equals(sessionToken)) { throw new BusinessException("请勿重复提交表单"); } session.removeAttribute("register_token_" + activityId);这个方案没有引入外部依赖，实现简单，效果很直接。当然，如果未来注册量上来，可以把Token换成一个唯一的业务流水号存储在Redis里做分布式幂等，那是另一套架构的玩法了，在这套JSP+Servlet项目里没必要。
6.2 文件上传与相对路径：跨浏览器兼容的隐藏坑
活动封面图上传也是个容易出问题的地方。我的上传逻辑是：前端用<input type="file">，提交到Servlet后用Part接口获取文件流，保存到服务端的upload/目录，URL路径存库。这个流程看似简单，但有两个隐藏坑。
第一，getRealPath()获取的是当前应用部署的绝对路径，如果你直接存在这个路径下，重新部署war包后文件就丢了。稳妥的办法是配置一个独立于应用目录的上传存储路径，比如/data/upload/，在constants配置类里统一管理。这样可以保证重启、重新部署都不会丢文件。
第二，文件名处理。用户上传的文件名可能包含中文、空格、特殊字符，如果直接用原始文件名存，生成的URL在部分浏览器里会出现编码问题。我的做法是：用UUID生成新文件名，扩展名从原始文件名里提取，并且做了白名单校验（只允许jpg/png/gif/webp）。这样既避免了中文文件名导致的URL编码兼容性问题，也防止了有人上传jsp文件伪装成图片（如果直接把上传目录暴露为Web可访问，会有很严重的安全风险）。
String originalFilename = part.getSubmittedFileName(); String ext = originalFilename.substring(originalFilename.lastIndexOf('.') + 1).toLowerCase(); if (!Arrays.asList("jpg", "jpeg", "png", "gif", "webp").contains(ext)) { throw new BusinessException("不支持的图片格式：" + ext); } String newFilename = UUID.randomUUID().toString().replace("-", "") + "." + ext; part.write(uploadDir + File.separator + newFilename);同时，上传目录要放在Web应用的类路径之外，禁止直接通过URL访问，访问图片时经过一个ImageServlet做权限校验，这个对安全要求高的场景特别重要。
6.3 数据库连接池参数的调优思路
JSP+Servlet项目如果不是用框架，很多同学直接就是DriverManager.getConnection()，这样写代码简单，但并发上来后数据库连接会频繁创建销毁，性能很差。我用的Druid连接池，配置如下：
DruidDataSource dataSource = new DruidDataSource(); dataSource.setUrl("jdbc:mysql://localhost:3306/campus_activity?useUnicode=true&characterEncoding=utf8mb4&serverTimezone=Asia/Shanghai"); dataSource.setUsername("root"); dataSource.setPassword("password"); dataSource.setInitialSize(5); dataSource.setMinIdle(5); dataSource.setMaxActive(20); dataSource.setMaxWait(60000);初始化5个连接，最小空闲5个，最大活跃20个。这个参数是根据典型校园活动系统的并发量（几十到几百人同时访问）配置的，足够了。如果活动规模特别大（比如全校运动会报名），可以适当调高MaxActive，但要注意数据库服务器本身的连接数上限，一般MySQL默认151个，留出些余量。
连接池配置里另一个值得注意的点是removeAbandoned和removeAbandonedTimeout，这两个参数可以自动回收泄漏的连接。我有一次写代码忘了在finally里关闭Connection，导致连接池被耗尽，系统half天就卡死，加上这两个参数后至少能自动兜底。这是线上问题排查时能救命的配置，加了没坏处。
6.4 部署路径和URL编码问题
部署这套系统的时候，我遇到过几个让人抓狂的问题，这里统一说一下。
一是URL编码。Tomcat 8及以上默认URI编码是UTF-8，但如果你用的老版本Tomcat，或者前端请求里带了中文参数（比如搜索"讲座"），就很可能出现中文乱码。解决办法是给Connector加上URIEncoding="UTF-8"配置。还有一个容易被忽略的角落是request.setCharacterEncoding("UTF-8")只能对POST请求体生效，对GET请求的查询串无效，必须靠URIEncoding来解决。
二是JSP页面顶部的pageEncoding和contentType。这两个如果不一致，页面中文就是乱码。统一设置成UTF-8是基本操作，但检查起来也最容易被忽略。
三是跨浏览器兼容问题在部署环境里的表现：有些机房电脑装的浏览器版本很老，对HTML5表单验证（required属性等）支持不好。我的方案是前端用JS做一套兼容的必填校验，HTML5属性仍然保留但只作为增强手段。这样即使浏览器不识别required，也不会出现表单直接提交空值到后端的情况。后端同样要校验，永远不要相信前端传来的数据。
6.5 演示数据与性能：答辩演示时的加分项
如果你做的是毕设，最后演示环节一定要有足够的数据支撑。我写了一个DataInitializer，启动时检测到活动表数据少于一定条数就自动生成20条模拟活动、100个模拟用户、500条报名记录、300条签到记录。这些模拟数据不是随机瞎填的，而是刻意构造了符合统计规律的分布——比如不同分类的活动数量、不同活动的报名率有高有低、时间分布覆盖最近一个学期。这样在展示统计报表时，图表看起来非常自然，不会出现所有活动报名率都100%或都0%这种假数据集感。
生成模拟数据的代码里，我用Math.random()配合一个正态分布来模拟报名人数，确保每个活动的报名数在max_people的30%-90%之间浮动。细节做到位，演示效果会好很多。这个DataInitializer我设了一个开关，上生产环境时直接关掉。
7. 前端体验优化与无障碍设计：容易被忽视但很加分的部分
7.1 响应式布局：手机端访问不能是灾难
校园活动的一个重要使用场景是手机端。学生在地铁上刷到感兴趣的活动，掏出手机就直接报名了。如果页面布局是固定宽度980px，手机上就会横向滚动，体验很差。我用了流式栅格布局，不依赖Bootstrap（避免引入额外依赖），只用CSS3的flex和media query搞定。
.container { max-width: 1200px; margin: 0 auto; padding: 0 15px; } @media (max-width: 768px) { .activity-card { width: 100%; margin-bottom: 15px; } .form-group input[type="text"] { font-size: 16px; /* 防止iOS自动缩放 */ } }一个非常关键的移动端细节是：input的font-size如果小于16px，iOS Safari会在聚焦时自动放大页面，用户体验很差。所以移动端样式里，所有可输入元素的字号至少设置16px。这个细节不处理的话，每次报名都要手动缩小页面，基本属于劝退级体验。
7.2 语义化HTML与无障碍访问
我做前端页面时用了比较严格的语义化标签：<header>、<nav>、<main>、<section>、<footer>。这不仅对SEO友好，也为使用屏幕阅读器的用户提供了清晰的页面结构。表单的每个输入框都有对应的<label for="...">，这样点击文字也能聚焦到输入框，同时对读屏软件友好。
还有一个容易忽略的点是颜色对比度。我的主色调用的是深蓝色（#1a5276）搭配白色文字，正文用近黑色（#2c3e50）配白色背景，对比度都能达到WCAG AA标准。这是考虑到可能有色弱或视力不佳的学生使用系统，不能光顾着好看而牺牲可读性。无障碍设计在国内校园系统里很少被真正重视，但真做起来之后评审印象会加分不少。
7.3 操作反馈与错误提示：别让用户干等
管理系统的用户往往不是技术人员，操作出错时如果只弹出一句英文错误信息，或者干脆没有反馈，用户只会觉得"系统坏了"。我设计了一套统一的前端提示机制：所有表单提交采用AJAX异步方式，成功/失败都有明确的中文提示，比如"报名成功，活动时间：2025-03-20 14:00，地点：大学生活动中心101"。
失败时不仅提示"操作失败"，还会具体说明原因，比如"该活动已满员，当前已有80人报名""该场地同一时间已有其他活动，请更换时间或场地"。这些具体、可执行的提示信息，正是把系统从"能用"提升到"好用"的关键。为了让提示信息自然融入而不影响页面布局，我在页面底部固定一个toast容器，用CSS动画实现淡入淡出，这种细节处理其实也不复杂。
注意：错误提示信息一定要在后端Service层定义好，返回统一结构（code + message），前端根据code渲染不同样式。不要把SQL异常堆栈直接抛给用户看，既暴露细节又不友好。
7.4 加载状态与空数据状态
用户点击"查询活动列表"后，如果网络慢，页面可能有两三秒没反应，用户会以为出bug了。我加了简单的loading提示，按钮点击后变成"查询中..."并禁用，请求返回后恢复。这个交互是基本盘。
空数据状态也要设计。比如学生没有任何报名记录时，页面不是白茫茫一片，而是显示"你还没有报过任何活动，去看看有哪些精彩活动吧"配一个跳转链接。组织者没有活动列表时，显示"你还没有创建过活动，点此创建第一个活动"。这些细节看着小，但真实用户使用时的困惑感会大幅降低。
8. 常见问题排查思路：我踩过的那些坑
8.1 502/500错误与数据库连接的关联排查
系统上线后我遇到过一个很典型的问题：运行几天后，部分页面随机出现500错误，Tomcat日志里报Connection is not available, request timed out。一开始以为是并发太高，把MaxActive调高到50，还是不行。后来加了连接池监控才发现，有个查询接口的Connection在异常分支里没有归还，日积月累把连接池耗尽了。
排查思路供参考：出现连接池耗尽时，用show processlist看数据库当前活跃连接，找到Source IP和对应的SQL，再反查代码里对应SQL所在的DAO方法，检查是否有try-with-resources或finally块兜底关闭Connection。我后来给所有DAO都改成了try-with-resources写法，同时开启了Druid的removeAbandoned=true和removeAbandonedTimeout=180，这样即使未来再出泄漏，连接也会在3分钟后被自动回收，不会把整个池子拖死。这种自动回收机制属于兜底方案，根源上还是要保证每个连接都手动关闭。
8.2 中文乱码的三层排查链路
中文乱码是Java Web项目最高频的问题之一。我的排查链路分三层：
- 第一层：页面显示乱码。检查JSP文件的pageEncoding是否UTF-8，response的Content-Type是否
text/html;charset=UTF-8。 - 第二层：请求参数乱码。POST请求检查
request.setCharacterEncoding("UTF-8")是否在getParameter之前调用；GET请求检查Tomcat的URIEncoding配置。 - 第三层：数据库存取乱码。检查MySQL连接URL是否带
characterEncoding=utf8，检查表字段是不是utf8mb4，检查MySQL服务端character_set_server配置。
按照这三层顺序排查，乱码问题基本能在5分钟内定位。我遇到过最隐蔽的情况是：MySQL连接串漏了characterEncoding，页面显示正常但数据库里存的是乱码。这种问题是"看起来一切正常，数据存进去就坏了"，最难发现。
8.3 403/404问题的文件路径陷阱
部署到Tomcat后，有同学反映某些页面404。排查后发现是前端引用的CSS和JS路径写错了。我用的项目结构是：
webapp/ ├── static/ │ ├── css/ │ ├── js/ │ └── images/ ├── WEB-INF/ │ ├── jsp/ │ └── web.xml └── index.jspJSP页面放在WEB-INF/jsp目录下，外部不能直接访问，通过Servlet forward过去，这样可以强制所有请求经过控制层，安全性更好。但这也带来路径问题：WEB-INF下页面的相对路径基准和外部访问路径不一致，CSS引用的static/css/common.css必须用绝对路径${pageContext.request.contextPath}/static/css/common.css，不能写相对路径。在JSP里统一用<c:set var="ctx" value="${pageContext.request.contextPath}"/>，每个链接都加上这个前缀。这是JSP开发的基本功，但确实是踩坑高发区。
8.4 活动状态自动流转的实现：定时任务还是懒更新
活动到了开始时间，状态要变成"进行中"，到了结束时间要变成"已结束"。如果完全靠用户操作触发，组织者忘了点"结束活动"，状态就一致性不对了。我用了最简单的方案：查询时动态计算。在ActivityService的查询方法里，根据当前时间和活动的start_time、end_time动态计算出"当前实际状态"，而不依赖表中status字段。这样即使status字段是旧的，展示给用户的状态也是准确的。同时，配置了一个定时任务每小时跑一次，把到达时间点的活动status字段批量修正，保证数据库里的状态不低于业务要求。
-- 每小时执行一次，将已过结束时间的活动置为已结束 UPDATE t_activity SET status = 4 WHERE status = 3 AND end_time < NOW();这个方案在数据量不大时完全够用，而且实现成本极低。不需要引入Quartz或Spring Task，一个简单的ScheduledExecutorService就够了。如果后续数据量大了、活动数量多，再考虑用Quartz管理更复杂的调度逻辑。
9. 这个系统能不能直接用在真实的校园场景里
9.1 落地效果与真实反馈
这个系统在某个校级社团做了一学期试运行，覆盖了大约30场活动、近2000人次报名。实际运行下来的数据是：报名信息统计时间从原来的每次2-3小时缩短到即时导出；活动冲突情况出现了2次（都是场地重叠，系统在创建时提示并拦截了1次，另1次是场地方临时改动但没更新系统）；签到效率从平均每人5秒降到1.5秒左右。最直接的效果是，学期末做第二课堂学分统计时，以前要翻聊天记录和纸质表，现在从系统里导出一次搞定，出错率从原来的人工比对5%降到接近0。
从使用反馈来看，学生侧最受欢迎的是"我的活动日历"和"报名成功提醒"两个功能，前者能按日期看到自己报名了哪些活动，避免时间撞车；后者在活动开始前2小时自动给用户发站内信提醒。组织者侧最受欢迎的是数据导出，一键导出报名名单和签到名单，省去了大量手工劳动。管理员最认可的是审核链路和统计报表，活动合规性和学生参与度一查便知。
9.2 系统的局限性
当然，这个系统也有明显的局限，坦白说：
- 无消息推送：目前提醒靠站内信和页面横幅，不能直接推送微信或短信。校园场景里很多学生不会主动登录系统看消息，所以活动通知还是需要配合微信群二次触达。
- 审核依赖人工：内容审核目前是管理员逐条审核，如果活动量特别大，人工审核会成为瓶颈。可以扩展违规关键词库，甚至引入文本分类模型做预审。
- 无第三方登录：没有对接学校的统一身份认证（如CAS），用户需要单独注册账号。如果学校有统一的认证系统，这是必要改造。
- 无移动端独立App：手机浏览器访问体验能接受，但不是原生App的体验。如果要做校园App集成，可以把它改造成RESTful API后端。
这些局限不是bug，而是项目边界的选择。做毕业设计时，你可以根据自己的进度合理取舍，比如把"微信消息推送"或"对接学校统一身份认证"作为一个独立的亮点模块来体现增量设计能力。
9.3 后续扩展方向：从活动管理到第二课堂
当前系统管的是"活动全流程"，但它的数据天然具有"第二课堂成绩单"的基因。每次报名、签到其实就是一个学生在某个领域的参与记录。沿着这个方向扩展，可以拆出一个独立的"第二课堂学分管理"模块，根据活动分类映射到不同的学分规则（思想成长、实践实习、志愿公益、创新创业、文体活动），然后自动生成每个学生的第二课堂成绩单。
这是一个很自然的演进方向，不用改底层表结构，只需要在t_activity表增加category映射学分规则，再增加一个t_credit_record表记录每个学生参与活动获得的学分，就能实现。数据已经在系统里了，缺的只是上层应用。从我做过的项目经验看，这类系统最大的价值不是某个页面的功能，而是日积月累沉淀下来的活动数据——有了数据，很多管理需求和分析需求都能从上面长出来。
最后再分享几个实操层面的心得
这个系统从需求梳理到上线运行，我用了大约三周业余时间。如果只挑最值得说的经验，大概是这么几条：
第一，表结构设计要多花时间。我第一版活动表没有单独拆审核表，后来加审核需求时发现要改表、改代码、改页面，来回折腾了两天。如果一开始就按"业务动作独立建表"的原则设计，后面会顺利很多。数据库字段名和注释一定要写清楚，过两周再看自己代码，注释就是最好的回忆。
第二，不要迷信框架，先把Servlet + JSP的逻辑理清楚。这套技术栈看起来老，但"浏览器发请求 → Servlet接收 → Service处理 → DAO访问数据库 → 响应回页面"这个链路是Web开发永远的内功底座。把这一层理解透了，之后上Spring Boot、MyBatis其实就是换个壳，核心思想是相通的。而且这套项目做完，你对HTTP状态码、Session生命周期、数据库事务这些概念的掌握会非常扎实，这在面试时是实打实的优势。
第三，部署前一定要做跨浏览器和移动端回归测试。我吃过亏的就是在Chrome上开发一切正常，演示时用了机房Firefox老版本，日期控件直接变成纯文本框，整个活动发布流程没法走通。后来我把所有依赖浏览器特性的交互都做了降级方案，再也没出过这种现场翻车的状况。建议至少准备三台不同内核的浏览器（Chromium系、Firefox系、Safari系）过一遍核心流程，花的时间不多，但能避开大量尴尬。
第四，日志打得好，排查问题快一倍。我在Service层每个关键操作都打了日志（入参、出参、耗时），线上出问题时通过日志定位到具体方法基本是分钟级的事。如果一直不做日志埋点，问题反馈到你这儿你连从哪儿看起都不知道。日志的粒度要适中，太细会产生大量无用信息，太粗则查不到线索，核心业务操作建议至少打一条INFO日志记录关键业务参数和结果。
最后，关于代码质量，我强烈建议把常量、配置、SQL语句都归类管理，不要散落在各个Servlet里。一个Constants类，一个DBConfig类，一个SQLConst类，虽然看起来繁琐，但项目代码量越写越大之后，你就会知道这些"冗余"有多重要。
如果这篇文章对你有帮助，你可以直接照着这个思路搭建你自己的校园活动管理系统，欢迎在评论区交流你在开发中遇到的问题——尤其是那些让你熬夜排查的bug，我很想知道你最后是怎么解决的。说到底，做管理系统这件事，最有价值的部分不在于代码本身，而在于你对业务流程的理解有多深，对用户需求看得有多透。真正把业务逻辑想明白了，技术实现反而只是水到渠成的事。
本文还有配套的精品资源，点击获取
