简介：这是一份面向高校师生开发的学科竞赛训练管理系统源码包，用于解决比赛报名、成绩录入、自由组队和水平分析等日常训练管理问题。系统基于前端技术栈构建，包含用户权限管理、通知推送、数据安全等模块，适用于教师管理参赛名单、学生在线组队与查看成绩排名等场景。包内共165个文件，核心为60个JS脚本与57个JSX组件，配合19个LESS样式文件实现界面与交互逻辑，另有16个PNG图片及少量配置、许可文件，整体压缩包仅453KB，结构精简便于二次开发。资源目前已有77人浏览学习，适合具备一定前端基础的开发者参考其功能设计与模块划分。通过阅读源码可了解完整的系统架构与角色权限设计思路，也可直接部署或改造用于本校竞赛训练场景。整体代码组织清晰，文件类型分工明确，是一份实用的教育信息化项目参考资料。
1. 学科竞赛训练管理系统：高校赛事管理为什么需要一个专门系统
每年赛季节奏一起，训练安排、报名名单、成绩记录全挤在聊天记录和Excel里来回传，光是把不同版本的报名表合成一份就够折腾一个下午。学科竞赛训练管理系统，解决的问题不是"能不能报名"，而是把比赛报名、成绩录入、自由组队、水平分析这几个环节串成一条线，让老师和学生在一个系统里完成从备赛到复盘的全过程。系统形态通常是一套Web应用，前端负责操作界面，后端管业务逻辑和数据存储，打包成压缩包交付，部署在校园服务器上。适合正在组织竞赛但还在用表格和接龙管理的高校教师、负责系统维护的信息中心人员，以及想改造赛务流程的学生团队——新手上手门槛不高，熟手可以在数据分析和权限设计上做深。
2. 从需求拆到架构：四个核心模块的数据关系与技术选型
2.1 用户场景梳理：比赛报名、自由组队、成绩录入、水平分析分别解决谁的问题
拿到压缩包之后，第一件事不是急着启动服务，而是把业务场景拆清楚。这套系统里有三类典型用户：学生、指导老师、管理员（通常是学院教务或竞赛负责人）。每类用户关心的功能点完全不同。
学生侧最常用的是比赛报名和自由组队。报名意味着我要在截止日期前把自己或团队的信息提交上去，并能看到是否审核通过；组队意味着我要发出邀请、接受或拒绝邀请，最后确认一支队伍名单。这两个功能使用频率最高，是系统的前台核心。
老师侧高频使用的是成绩录入和水平分析。成绩录入不能只是存一个数，而是要支持按竞赛、按场次、按队伍来记录，后续要能按赛季汇总；水平分析则是从历史成绩里看出学生的稳定性、排名变化和优势项目，帮助指导老师做选拔和训练调整。管理员侧关注的是竞赛配置、报名截止时间、数据导出和权限分配。
这四个模块不是孤立的。报名生成了"参赛资格"，成绩录入在竞赛维度上挂了"结果"，水平分析基于"历史成绩"计算衍生指标，组队则影响了"队伍"这一个实体的成员构成。数据关系理顺了，后续开发才不拧巴。我建议先把业务流程图画一遍，标出每个实体的状态变化，比如报名从"已提交"到"审核通过"，组队从"邀请中"到"确认完成"，再对应到数据库表上——这样不会出现做着做着字段对不上接口的情况。
2.2 技术选型：单体架构的取舍，Spring Boot 为什么够用
高校学科竞赛训练系统的用户量级，峰值并发通常集中在报名开放的前几小时，大约几百人同时在线操作，日常并发不会超过几十。这种规模下，单体架构是最合理的起点——部署简单、排错快、一台普通服务器就能扛住。常见做法是后端用 Spring Boot，前端用 Vue，数据库用 MySQL，三类技术都是高校和外包团队最熟悉的一套组合，遇到问题网上资料也最多。
为什么不上微服务？看着好像有用户、竞赛、消息好几个域，但业务复杂度没有高到需要拆分分布式事务的程度。报名和组队在一个服务里用本地事务就能搞定的场景，拆成两个服务反而要引入消息队列或分布式事务，得不偿失。我一般会跟接手这个系统的人说：先单体跑通，等并发真的上来了，再把消息推送和数据分析单独拆出去，不要提前优化。
前后端分离是值得坚持的。Vue 负责页面交互和图表渲染，Spring Boot 只暴露 REST 接口。这样做的直接好处是，后期如果要把移动端或小程序接进来，接口可以复用；老师端希望单独做一个成绩录入页面，也不需要改后端结构。数据持久层用 MyBatis-Plus 能省掉大量重复的 CRUD 代码，多条件查询、分页都有现成方案，比手写 JDBC 或原生 MyBatis 的 XML 配置效率高很多。
2.3 数据模型：六张核心表如何支撑四个功能模块
数据库表设计直接决定系统能撑到哪一步。按常规交付来看，核心表至少要有用户表、竞赛表、报名表、队伍表、队员表、成绩表这六张。用户表存登录账号和角色，角色做简单 RBAC，用role字段区分学生、老师、管理员三种身份。竞赛表是整个报名流程的主数据，字段包括赛事名称、级别、报名开始和截止时间、最大队伍人数限制。报名表别名注册表，单条记录既支持个人报名也支持团队报名，靠team_id是否为空来区分。
队伍表和队员表的关联关系要设计成主表加从表结构。队伍表存队长用户ID、队伍名称、审核状态；队员表存队伍ID和成员用户ID，一个队员可以同时在多个队里？不行，如果队员表不约束，会出现一个人同时出现在两支队伍里参加同一场竞赛，这是规则错误，要在数据库层面用唯一约束兜底。
成绩表的设计更细节一些。比赛名次、得分、获奖等级这几个字段最好分开存，不要全塞进一个result字符串里。因为水平分析要按具体数值算，获奖等级也要做排名统计。建议成绩表里冗余一个competition_id和team_id外键，查询某场竞赛的成绩排行榜时能少联两张表。索引上，报名表按competition_id和user_id建联合索引，成绩表按competition_id建索引，这是查询最频繁的两个入口。
2.4 项目结构与部署：拿到压缩包后的解读顺序
拿到压缩包解压后，先看目录结构。典型的前后端分离项目，压缩包内会分成三个部分：前端工程（通常叫web或frontend）、后端工程（server或backend）、数据库初始化脚本（sql目录）。先把数据库脚本执行完，再启动后端，最后启动前端，这个顺序不要反。顺序反了的后果是：前端能打开页面，但所有接口请求都报 500，查不到具体错误，因为后端压根没连上库。
后端启动之前要改两个地方。数据库连接信息在application.yml里的datasource配置段，密码要改成自己环境的；文件上传路径、日志输出目录这类绝对路径也得确认存在并有写权限，Windows 和 Linux 的路径写法不一样，部署时最容易在这里翻车。前端启动前要确认接口代理地址配的是不是后端地址，Vue 的 dev 环境通常走vite.config.js里的 proxy，生产环境是 nginx 转发，两处配置要对应上。
这里插一个不太起眼但容易卡住新手的细节：压缩包里自带的 SQL 脚本里如果有外键约束，导入时要注意执行顺序。先建用户表再建队伍表，再建队员表，外键才能关联上。有些人图省事直接拖进可视化工具执行，结果一堆 "Cannot add foreign key constraint" 报错。倒不是 SQL 有问题，是建表依赖顺序错了。
3. 比赛报名与自由组队：两个高频模块的实现细节
3.1 报名接口设计：单人与团队报名共用一套流程的写法
报名是整个系统里调用频次最高的接口，设计得不好会出现两种情况：单人报名和团队报名逻辑分离，代码重复维护两份；或者参数校验不到位，把不完整的报名数据写进库里。常见做法是共用一套报名流程，用参数里的type字段区分报名方式。
@Transactional(rollbackFor = Exception.class) public RegistrationVO submitRegistration(RegistrationRequest request) { // 1. 校验报名时间是否在竞赛开放窗口内 Competition comp = competitionMapper.selectById(request.getCompetitionId()); if (comp == null) { throw new BizException("竞赛不存在"); } if (LocalDateTime.now().isBefore(comp.getRegisterStart()) || LocalDateTime.now().isAfter(comp.getRegisterEnd())) { throw new BizException("不在报名时间范围内"); } // 2. 根据报名类型走不同分支 if (RegistrationType.TEAM.equals(request.getType())) { // 团队报名：校验队员名单是否在5人以内，且无重复 if (request.getMemberIds().size() > comp.getMaxTeamSize()) { throw new BizException("团队人数超出限制"); } // 先创建队伍，再创建报名记录 Team team = new Team(); team.setCaptainId(CurrentUser.get().getUserId()); team.setCompetitionId(comp.getId()); team.setStatus(TeamStatus.PENDING); teamMapper.insert(team); // 队员表批量插入，memberIds去重 batchInsertTeamMembers(team.getId(), request.getMemberIds()); request.setTeamId(team.getId()); } // 3. 创建报名主记录 Registration reg = buildRegistration(request); registrationMapper.insert(reg); // 4. 返回带报名状态的视图对象 return buildRegistrationVO(reg); }这段代码有几个关键点。@Transactional注解保证创建队伍和插入报名记录要么同时成功要么同时回滚，不会出现队伍建了但报名记录没有的情况。时间校验放在事务最前面，目的是让无效请求尽早失败，不占用数据库连接。团队报名里先创建队伍再插入队员，顺序不能换，因为队员表的外键依赖队伍表的主键。
参数说明：maxTeamSize是竞赛表里的配置项，不同竞赛可以设置不同上限；memberIds是前端传过来的队员用户ID列表，后端必须做去重和数量校验，不要信任前端的判断。所有校验失败都用BizException抛出，由全局异常处理器统一返回提示信息，这样前端拿到的是明确的业务提示，而不是晦涩的 SQL 报错。
3.2 自由组队的状态流转：邀请、接受、审批三步怎么设计
自由组队是流程上最容易绕晕的部分。很多人在这一头把邀请、接受、审批拆成三个互不关联的接口，结果数据库里状态字段混乱，一会儿是"待组队"，一会儿是"邀请中"，查数据时要拼好几张表才能还原当下的真实状态。我习惯把组队做成一条带有状态机的记录流。
组队状态设计成六种：INVITING（邀请中）、ACCEPTED（已接受）、REJECTED（已拒绝）、CONFIRMED（教师确认）、EXPIRED（超时失效）、CANCELLED（队长取消）。学生 A 发起组队，系统给 B 和 C 各生成一条邀请记录，状态是INVITING。B 点接受，状态变ACCEPTED；C 点了拒绝，状态变REJECTED。当队伍里所有被邀请的成员都接受了邀请，队伍状态自动变成PENDING（待审批），指导老师确认后变CONFIRMED。
public String handleInvitation(Long invitationId, InviteAction action) { Invitation inv = invitationMapper.selectById(invitationId); // 状态机守卫：只有 INVITING 状态才能被操作 if (!InviteStatus.INVITING.equals(inv.getStatus())) { throw new BizException("该邀请已被处理，不能重复操作"); } if (InviteAction.ACCEPT.equals(action)) { inv.setStatus(InviteStatus.ACCEPTED); invitationMapper.updateById(inv); // 尝试推进队伍状态 advanceTeamStatus(inv.getTeamId()); } else { inv.setStatus(InviteStatus.REJECTED); invitationMapper.updateById(inv); } return "操作成功"; } private void advanceTeamStatus(Long teamId) { List<Invitation> invs = invitationMapper.selectByTeamId(teamId); boolean allAccepted = invs.stream() .allMatch(i -> InviteStatus.ACCEPTED.equals(i.getStatus())); if (allAccepted && !invs.isEmpty()) { Team team = teamMapper.selectById(teamId); team.setStatus(TeamStatus.PENDING); teamMapper.updateById(team); } }这段逻辑里最容易漏掉的是状态机守卫。用户点了两次接受，第二次进来时邀请状态已经不是INVITING，必须直接提示"已被处理"，否则会出现同一条邀请被重复消耗的数据错误。advanceTeamStatus的设计用全量比对判断队伍是否可进入下一状态，比在邀请表上维护一个计数器更不容易出错——计数器一旦和实际记录不同步，队伍状态就卡住了。
默认给邀请加一个 48 小时有效期，超时自动置为EXPIRED。不是所有人都能做到每天看系统，这条兜底可以让队长及时知道"谁还没处理"，该换人换人，不至于卡死整个组队流程。
3.3 并发场景下的数据一致性：报到同一支队伍的兜底策略
报名开放那一刻，可能出现多个学生同时操作，或者在组队截止前最后一刻同时确认名单，这些都是典型的并发场景。不处理好的话，数据库层面会出现同一支队伍被两支不同队伍重复报名，或者队员表里同一用户出现在两支队伍中。
第一种兜底是给报名表加联合唯一索引。(competition_id, team_id)在团队报名中必须是唯一的，这样数据库层面直接拒绝重复插入。第二种兜底是给队员表加(team_id, user_id)唯一索引，限制一个用户在同一支队伍里只能有一条记录。光是代码里判断还不够，并发场景下两条请求同时通过代码校验是可能发生的，唯一索引才是真正的最后防线。
ALTER TABLE team_member ADD UNIQUE KEY uk_team_user (team_id, user_id); ALTER TABLE registration ADD UNIQUE KEY uk_comp_team (competition_id, team_id);这两个唯一索引放在业务代码之外，属于"防守型设计"。可能一个月都触发不到一次，但一旦触发，挽救了可是一条脏数据。需要提醒的是：加唯一索引要在建表 SQL 里就写上，不要等项目上线后数据已经乱了再补。已经存在重复数据的表上加唯一索引会直接失败，到时要先手工清洗数据，麻烦程度翻倍还容易误删。
锁的层面，报名接口的事务里不要用select ... for update锁整张竞赛表，会挡住同一时间所有其他正常用户的报名，等于把并发问题放大成性能问题。唯一索引加事务回滚已经足够解决业务层面的正确性，数据库自己会处理冲突。
4. 成绩录入与水平分析：从原始数据到可视化报告
4.1 成绩录入的两种路子：Excel 批量导入与逐条表单录入
成绩录入是老师每天都可能要用的功能，但也是最容易让老师反感的功能——如果只能一条一条填，一次录入几十个学生的成绩就得花掉一个小时。合理的做法是同时支持两种方式：逐条录入面向单场小规模比赛，Excel 批量导入面向赛季大规模录入。
批量导入的通用思路是前端上传 Excel，后端解析并在内存里做校验，然后分批写库。解析库用 EasyExcel 比原生 Apache POI 省事很多，可以把每行数据直接映射到一个 Java 对象上。
public ImportResult importScores(MultipartFile file, Long competitionId) { // 定义行数据模型，用注解映射Excel列名 List<ScoreImportRow> rows = EasyExcel.read(file.getInputStream()) .head(ScoreImportRow.class) .sheet() .doReadSync(); // 校验行数限制，防止一次性导入过多数据 if (rows.size() > 1000) { throw new BizException("单次导入不能超过1000行"); } List<Score> validList = new ArrayList<>(); int failCount = 0; for (ScoreImportRow row : rows) { // 逐行校验：队员是否存在、成绩是否在合法范围 if (row.getScore() == null || row.getScore() < 0 || row.getScore() > 100) { failCount++; continue; } Score score = buildScore(row, competitionId); validList.add(score); } // 批量插入，每500条提交一次，避免一次插入太多导致事务过大 saveBatch(validList, 500); return new ImportResult(validList.size(), failCount); }EasyExcel的doReadSync()简单直接，适合中小规模的导入场景。但要注意，用同步读取意味着整个文件解析过程会占用一个请求线程，文件过大时页面会转圈很久。限制单次导入行数不是拍脑袋定的，是经验值——1000 行数据解析加校验加批量插入，在普通服务器上大概 2 到 3 秒，用户还能接受；超过这个数建议拆文件或者走异步任务。
逐条录入的表单页其实不需要太多花活。竞赛下拉框、队伍下拉框、分数输入框、备注文本域，提交后走一个普通的 insert 接口。但两个细节不要省：下拉框里的队伍信息要按竞赛过滤，不然老师录 A 竞赛的成绩时选到了 B 竞赛的队伍；分数输入框要做即时校验，输错了当场提示，而不是等到提交后后端拦截。
4.2 水平分析的指标设计：平均分之外的三个关键数字
水平分析是这套系统里最容易被做成"花架子"的功能——画一堆图表，但老师看不出门道。这不是视觉设计问题，是核心指标没选对。一个学生的水平不能只看平均分，平均分掩盖了发挥稳定性、对手强度和进步趋势。我会在系统里加三个关键数字。
第一个是标准差。标准差衡量的是学生历次比赛成绩的波动程度。标准差小说明发挥稳定，标准差的数值大说明成绩忽高忽低，要么是状态不稳，要么是训练强度不规律。第二个是百分位排名。
第三个是 Z 分数，也叫标准化分数。它的价值在于让不同难度竞赛的成绩可比——校级初赛 80 分和省级决赛 75 分谁更接近"正常发挥"？把原始分减去该场比赛的平均分，再除以该场比赛的标准差，两个场景的成绩就放到了同一个坐标系里比较。
public AnalysisResult computeStudentLevel(Long studentId, Long semesterId) { List<Score> scores = scoreMapper.selectByStudentAndSemester(studentId, semesterId); if (scores.isEmpty()) { return AnalysisResult.empty(studentId); } double avg = scores.stream().mapToDouble(Score::getScore).average().orElse(0); // 标准差计算：先求方差再开根号 double variance = scores.stream() .mapToDouble(s -> Math.pow(s.getScore() - avg, 2)) .average().orElse(0); double stddev = Math.sqrt(variance); // 每场比赛的Z分数按竞赛维度计算后取平均 List<Double> zScores = new ArrayList<>(); for (Score s : scores) { Double compAvg = scoreMapper.selectAvgByCompetition(s.getCompetitionId()); Double compStd = scoreMapper.selectStdByCompetition(s.getCompetitionId()); if (compAvg != null && compStd != null && compStd > 0) { zScores.add((s.getScore() - compAvg) / compStd); } } double avgZ = zScores.isEmpty() ? 0 : zScores.stream().mapToDouble(Double::doubleValue).average().orElse(0); return new AnalysisResult(avg, stddev, avgZ); }这段代码的关键点在于 Z 分数是按单场比赛口径计算的，而不是拿所有历史成绩算一个总的标准差。原因是不同场次的难度和对手水平不一样，只有按场次标准化后再平均，才能反映"这个学生相对同场其他选手的稳定水平"。如果直接拿所有原始成绩算标准差，算法上没错，但得出的结论会偏向于"参赛场次越多分数波动越大"的假象。
指标算出来后，系统的呈现方式比数值本身更影响使用率。老师不关心 0.73 这个数字是什么意思，他要的是"这人能不能进省赛集训名单"。所以展示端要配合文字描述：平均分高于 85 且标准差低于 5，标记为"稳定型选手"；标准差高于 10 但 Z 分数为正，标记为"高上限选手"；Z 分数持续为负则提示"建议调整训练方向"。这就把裸数据翻译成了决策信息。
4.3 把分析结果变成图表：前端图表怎么选与数据接口怎么写
图表是水平分析模块的门面，也是前端最容易拖后腿的地方。ECharts 是这类后台管理系统的主流选择，文档全、示例多、对 Vue 的封装成熟，雷达图和折线图开箱即用。我个人推荐用轻量的封装组件，比如vue-echarts，而不是直接操作 ECharts 实例，因为组件的responsive和autoresize特性可以直接使用，省掉一堆 window resize 监听代码。
后端接口输出给图表的数据结构要预先设计好。雷达图接收的是多维能力评分，折线图接收的是按时间排序的成绩序列，接口返回的字段名建议用英文小写加下划线，与数据库字段保持一致，避免前端拿到数据后还要做 map 转换。
{ "student_id": "20230012", "student_name": "张同学", "radar_data": { "理论基础": 82, "代码实现": 74, "调试能力": 69, "临场发挥": 78, "团队协作": 88 }, "trend_data": [ { "match": "第一轮", "score": 72, "rank": 34 }, { "match": "第二轮", "score": 78, "rank": 21 }, { "match": "第三轮", "score": 85, "rank": 9 } ] }图表数据接口的缓存策略值得提一句。水平分析的结果是基于历史成绩计算的，成绩表不更新，分析结果就不变。我一般会在接口层做 5 分钟本地缓存，减少数据库压力。成绩录入后主动删缓存，保证老师录完成绩后刷新页面立刻能看到最新分析。
5. 避坑与排查：学科竞赛训练系统最常见的五个翻车点
5.1 报名数据莫名覆盖：事务里藏了个更新语句
现象：两个学生同时报名同一个竞赛，报名结束后数据库里只有一条记录，且两人显示都是"报名成功"。
原因：报名接口的事务里，写了一个"更新该竞赛的当前报名人数"的语句，用的是先查再更新的方式——SELECT count(*)然后UPDATE competition SET register_count = ?。A 请求先把人数从 0 读到内存，B 请求也读到 0，A 更新成 1，B 再更新成 1，A 插入的报名记录被后续逻辑覆盖或关联字段错乱。
解决：人数统计改成数据库自增更新。UPDATE competition SET register_count = register_count + 1 WHERE id = ?是原子操作，天然规避并发。同时给报名表加(competition_id, user_id)唯一索引，从根本上保证同一用户同一竞赛只能有一条报名记录。不要试图用锁去解决问题，register_count只是一个冗余的统计字段，多一条少一条无关紧要，数据正确性由唯一索引来兜。
5.2 组队邀请异步不同步：轮询的间隔与状态锁冲突
现象：学生 A 接受了队伍邀请，页面显示"队伍已进入待审批"，但队长 B 的页面一直停留在"邀请中"，刷新也没变化。
原因：前端做的是定时轮询，每 30 秒请求一次队伍详情接口。A 操作后，B 本地状态没有立即更新，要等下一轮轮询。如果轮询间隔设置过长，或者页面切到后台后定时器被浏览器节流，就会出现这种"不同步"的观感。更深层的问题是队伍状态的推进逻辑放在了邀请记录更新之后，如果advanceTeamStatus抛了异常，邀请状态已经是"已接受"，但队伍状态没变，数据就永久不一致了。
解决：把接受邀请和推进队伍状态放进同一个事务里，任一步失败整体回滚。前端轮询间隔调整为 10 秒，并在页面visibilitychange事件里重新拉取一次数据，切回页面立刻刷新而不是等定时器。同时在前端把队伍状态做成全局共享，B 的界面收到最新数据前先展示乐观更新，减少"我操作了怎么没反应"的困惑。
5.3 Excel 导入乱码与丢精度：模板兼容没做对
现象：老师下载了官方 Excel 模板，填完导入后被提示"学号格式不正确"，打开数据库看学号变成了1.2023E+10这种科学计数法形式。
原因：Excel 默认把纯数字列当成数字类型处理，超过 12 位的学号自动转成科学计数法。用户在原 Excel 里看到的是一串正常数字，导入成功后程序读到的却是被格式转换后的值。这不是代码 bug，是 Excel 的单元格格式导致的数据丢失。
解决：模板里的学号列预先设置成"文本格式"，这个要在模板文件层面完成。后端解析时再加一道防线：row.get("学号")读到的值统一先转字符串，然后判断是否包含小数点，包含就去掉小数点再补零恢复原始长度。另外在解析逻辑里增加对科学计数法的适配：识别到单元格值是数字类型且包含E时，用BigDecimal.toPlainString()还原完整数字。
5.4 两套代码两种结果：水平分析的口径问题
现象：老师发现系统里的"水平分析"结果和用 Excel 自己算出来对不上。同一个学生，Excel 算的平均分是 82.5，系统显示 83.0。
原因：系统里有两个地方计算了学生平均分，一个是列表页的简要指标，另一个是详情页的完整分析。两处代码写了不同的数据范围——列表页按"本学年所有成绩"算，详情页按"选择学期内已审核成绩"算，一个把未审核成绩算进去了，另一个没算。口径不统一导致同一页面不同位置展示的数字互相矛盾。
解决：把指标计算收敛成一个统一服务方法，所有入口都调用同一个方法。数据范围用参数区分而不是写死在 SQL 里。同时给成绩表加一个status字段，PENDING表示待审核，APPROVED表示有效成绩，所有分析统计默认只纳入APPROVED的数据。规则定死压到代码层面，比靠人记住更加可靠。
5.5 后端不设防：隐藏按钮挡不住越权调用
现象：学生用户通过浏览器的开发者工具直接调用删除竞赛的接口，把一场竞赛删掉了，管理员一脸懵。
原因：前端把"删除"按钮只在管理员登录后才显示，但后端接口没有做权限校验，任何登录用户都能调用DELETE /api/competition/{id}。前端隐藏只是视觉上的防呆，不是安全措施。后端如果偷懒不校验角色，等于把数据库大门钥匙复制给了所有学生。
解决：写一个简单的注解式权限拦截器。在 Controller 方法上加@RequireRole(role = "ADMIN")，拦截器里读当前用户的角色做比对，不满足直接返回 403。所有写操作接口都要加，不只是管理接口。这个属于低成本高收益的防御动作——拦截器代码量不大，但挡住了 90% 以上的越权风险。排查时如果发现已有接口遗漏，先加上再谈其他优化。
6. 往前走一步：用波动系数隐藏在成绩表里的潜力选手
水平分析算出了 Z 分数和标准差，但这份数据对教练的决策帮助还可以更直接。常规做法是列出平均分排行榜，但排行榜只反映"谁现在强"，看不到"谁在变强"。我给这个系统想了一个可以用在期末选拔阶段的技巧：引入"波动系数"，识别成绩持续上行的学生。
波动系数不是一个新的统计量，而是基于标准差和最近三次成绩斜率的组合判断。计算方式分两步：先取学生本学期全部有效成绩拟合一条线性趋势线，斜率大于 0 说明整体向上，斜率绝对值越大进步速度越快；再用"最近三次成绩的方差除以前半程成绩的方差"得到比值，比值小于 1 说明后程比前程稳定。两个条件同时满足，就标记为"潜力型选手"。
# 可作为后端分析模块的独立脚本，或改写成 Java 方法嵌入系统 def calc_potential(scores): # scores: [{round_no, score}, ...]，按轮次升序排列 if len(scores) < 4: return {"potential": False, "reason": "场次不足"} first_half = scores[:len(scores)//2] second_half = scores[len(scores)//2:] var_first = statistics.variance([s["score"] for s in first_half]) var_second = statistics.variance([s["score"] for s in second_half]) # 后半程波动缩小，且成绩相对前半程提升 stable_ratio = var_second / var_first if var_first > 0 else 1 avg_first = sum(s["score"] for s in first_half) / len(first_half) avg_second = sum(s["score"] for s in second_half) / len(second_half) is_potential = stable_ratio < 0.7 and avg_second > avg_first + 3 return {"potential": is_potential, "stable_ratio": stable_ratio, "avg_improve": avg_second - avg_first}两个参数的设定是我实际调过的经验值：稳定比阈值 0.7 太宽松会把发挥一直差的选手也圈进来，太严格 0.5 又会漏掉真正进步的选手；平均分提升 3 分是最低要求，不足 3 分可能只是题目难度浮动。这两个参数在系统里应该做成可配置项，不同竞赛不同学期可以调整，不要写死在代码里。验证方法也简单，抽上一届的数据跑一遍，观察被标记的学生里有多少最终在正式竞赛中名次上升。
这个方向跑通后，系统的价值就从"管事情"升到了"辅助训练决策"。以后教练每个学期末打开系统，除了看排行榜，还有一份潜力名单可以直接纳入集训讨论，这才是水平分析这个功能该有的产出。我自己踩过最深的坑就是把系统做成"存数据的黑匣子"——如果管理者在里面看不到决策依据，干得再漂亮也只是个电子档案柜。希望这篇笔记能帮你在落地时避开那些我已经替你们趟过的坑，让这套系统真正成为竞赛备赛的抓手，而不是又一套应付检查的空壳。
本文还有配套的精品资源，点击获取
