简介这是一份面向高校师生开发的学科竞赛训练管理系统源码包用于解决比赛报名、成绩录入、自由组队和水平分析等日常训练管理问题。系统基于前端技术栈构建包含用户权限管理、通知推送、数据安全等模块适用于教师管理参赛名单、学生在线组队与查看成绩排名等场景。包内共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 点接受状态变ACCEPTEDC 点了拒绝状态变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) { ListInvitation 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列名 ListScoreImportRow rows EasyExcel.read(file.getInputStream()) .head(ScoreImportRow.class) .sheet() .doReadSync(); // 校验行数限制防止一次性导入过多数据 if (rows.size() 1000) { throw new BizException(单次导入不能超过1000行); } ListScore 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) { ListScore 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分数按竞赛维度计算后取平均 ListDouble 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 请求也读到 0A 更新成 1B 再更新成 1A 插入的报名记录被后续逻辑覆盖或关联字段错乱。解决人数统计改成数据库自增更新。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.2023E10这种科学计数法形式。原因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 分可能只是题目难度浮动。这两个参数在系统里应该做成可配置项不同竞赛不同学期可以调整不要写死在代码里。验证方法也简单抽上一届的数据跑一遍观察被标记的学生里有多少最终在正式竞赛中名次上升。这个方向跑通后系统的价值就从管事情升到了辅助训练决策。以后教练每个学期末打开系统除了看排行榜还有一份潜力名单可以直接纳入集训讨论这才是水平分析这个功能该有的产出。我自己踩过最深的坑就是把系统做成存数据的黑匣子——如果管理者在里面看不到决策依据干得再漂亮也只是个电子档案柜。希望这篇笔记能帮你在落地时避开那些我已经替你们趟过的坑让这套系统真正成为竞赛备赛的抓手而不是又一套应付检查的空壳。本文还有配套的精品资源点击获取