简介：这是一份面向高校师生的学科竞赛训练管理系统前端源码，覆盖比赛报名、成绩录入、自由组队、水平分析等核心模块，可帮助教师高效管理赛事、学生便捷参与组队与训练。包内共一百六十五个文件，以六十个JavaScript脚本、五十七个jsx组件、十九个less样式表为主，另有页面图标、项目配置与说明文档，整体约四百五十三KB，目录结构清晰，方便直接运行调试或二次开发。系统还包含用户权限管理、通知推送、移动端适配、数据安全等设计，并配有eslint、editorconfig等工程化配置，可作为Web前端实战案例学习。目前已有七十七人浏览学习，通过源码可掌握列表筛选、表单校验、图表展示等常见业务实现，适合需要快速搭建竞赛管理平台或学习React项目架构的高校师生、前端开发者，也可作为课程设计或毕业设计的参考项目。
1. 学科竞赛训练管理系统：为什么高校都在补这块拼图
学科竞赛训练管理系统，说到底就是把比赛报名、成绩录入、自由组队、水平分析这几条散线收拢成一个闭环。高校里带竞赛的老师和负责赛事的学生干部，最头疼的不是训练本身，而是报名表在微信群里传来传去、成绩录完没法对比、组队全靠缘分。一个能跑起来的系统，核心就三件事：让报名有状态、让成绩可比较、让组队有依据。这个方向值不值得投入？我的判断是值得，但前提是别把它做成又一个 CRUD 后台。下面我会从数据模型、报名状态机、组队算法、水平分析模型到落地后的排障，完整过一遍实操路径，代码都是可以直接抄走的量级。
2. 先把地基打对：系统架构选型和核心表结构设计
2.1 选型逻辑：为什么用 Django + PostgreSQL 而不是前后端分离全家桶
我做过几个类似的管理系统，最常见的翻车原因不是功能不够，而是起步太重。学科竞赛训练管理系统的使用场景非常明确：校内几百个学生、几十位指导老师、一学期几十场比赛，并发峰值也就是报名截止前半小时。这个量级用 Django + PostgreSQL 是性价比最高的组合——Django 自带的 admin 可以快速给老师做成绩录入界面，ORM 迁移工具能随时调整表结构，PostgreSQL 的 JSONField 可以存灵活的竞赛配置。
框架选型优先级：Django + DRF 提供 API，Vue 做前端；如果你团队只有两三个人，直接用 Django 模板渲染也能跑。数据库选 PostgreSQL 是因为水平分析那一章需要算百分位排名和统计指标，PG 的窗口函数比 MySQL 顺手得多。ORM 的好处是改表结构不用写一堆 ALTER 语句，用python manage.py makemigrations就能同步。当然，如果学校已经有统一认证体系（常见的是 OAuth2 或 CAS），那认证这层可以接到外部，系统只专心做业务。
2.2 六张核心表：从学生到成绩的完整链路
设计表结构前先画清楚业务流程。用户角色有三类：学生、指导老师、系统管理员。学生报名比赛、发起组队；老师审批报名、录入成绩、查看水平分析；管理员管理比赛、配置赛季。围绕这个流程，我最终收敛成六张表：User（用户基表）、StudentProfile（学生档案）、TeacherProfile（教师档案）、Competition（比赛）、Team（队伍）、Enrollment（报名记录）、Score（成绩）。这里把用户和角色档案分开，是为了以后接学校的统一身份认证时可以只映射 User，不动业务表。
from django.db import models from django.contrib.auth.models import AbstractUser class User(AbstractUser): ROLE_CHOICES = [ ("student", "学生"), ("teacher", "指导老师"), ("admin", "系统管理员"), ] role = models.CharField("角色", max_length=16, choices=ROLE_CHOICES) class StudentProfile(models.Model): user = models.OneToOneField(User, on_delete=models.CASCADE, related_name="student_profile") student_no = models.CharField("学号", max_length=20, unique=True) major = models.CharField("专业", max_length=64, db_index=True) grade = models.IntegerField("年级", db_index=True) levels = models.JSONField("历史参与记录", default=dict, blank=True) class Competition(models.Model): STATUS_CHOICES = [ ("registration", "报名中"), ("in_progress", "进行中"), ("finished", "已结束"), ] name = models.CharField("竞赛名称", max_length=128) category = models.CharField("竞赛类别", max_length=32, db_index=True) # 数学/编程/电子设计... season = models.CharField("赛季", max_length=32, db_index=True) # 如 2025-春季 status = models.CharField("状态", max_length=16, choices=STATUS_CHOICES, default="registration") max_team_size = models.IntegerField("队伍人数上限", default=3) config = models.JSONField("扩展配置", default=dict, blank=True) register_start = models.DateTimeField("报名开始时间") register_end = models.DateTimeField("报名截止时间") class Team(models.Model): competition = models.ForeignKey(Competition, on_delete=models.CASCADE, related_name="teams") name = models.CharField("队名", max_length=64) leader = models.ForeignKey(User, on_delete=models.PROTECT, related_name="led_teams") members = models.ManyToManyField(User, related_name="joined_teams", blank=True) status = models.CharField( "组队状态", max_length=16, choices=[("forming", "组建中"), ("locked", "已锁定"), ("disbanded", "已解散")], default="forming", ) class Enrollment(models.Model): STATUS_CHOICES = [ ("pending", "待审核"), ("approved", "已通过"), ("rejected", "已驳回"), ] student = models.ForeignKey(User, on_delete=models.CASCADE, related_name="enrollments") competition = models.ForeignKey(Competition, on_delete=models.CASCADE, related_name="enrollments") team = models.ForeignKey(Team, on_delete=models.SET_NULL, null=True, blank=True) status = models.CharField("报名状态", max_length=16, choices=STATUS_CHOICES, default="pending") created_at = models.DateTimeField("创建时间", auto_now_add=True) updated_at = models.DateTimeField("更新时间", auto_now=True) class Meta: constraints = [ models.UniqueConstraint(fields=["student", "competition"], name="uniq_student_competition") ] class Score(models.Model): enrollment = models.ForeignKey(Enrollment, on_delete=models.CASCADE, related_name="scores") judge_level = models.CharField("获奖等第", max_length=32) # 如"国一"、"省二"、"参与奖" raw_score = models.FloatField("原始分数", null=True, blank=True) # 百分制时使用 rank = models.IntegerField("校内名次", null=True, blank=True) recorded_by = models.ForeignKey(User, on_delete=models.PROTECT, related_name="recorded_scores") created_at = models.DateTimeField(auto_now_add=True)逻辑说明：levels字段设计成 JSONField 而不是单独建表，是因为历史参与记录的结构各赛季不稳定——有的要存获奖级别，有的要存参赛项目，强结构反而增加维护成本。Enrollment表加唯一约束保证同一学生不能对同一比赛重复报名，这是报名模块最底层的防线。Score表同时保留 raw_score 和 judge_level，是因为不同比赛计分方式完全不同，编程赛有分数，论文赛可能只有名次，两套字段互相弥补。
关键参数说明：max_team_size是组队上限，但要注意它存在 Competition 表而非 Team 表，这是因为不同比赛组队人数规则不同——数学建模通常三人，电子设计可能两人，放在比赛配置上才能灵活调整。Team.status里的 locked 状态很关键，锁定后成员不能再变更，防止比赛开始前队员临时换人导致数据混乱。on_delete=PROTECT用在 leader 和 recorded_by 上，意思是指导老师账号即使要删除，也必须先处理其名下的队伍和成绩记录，避免历史数据悬空。
3. 比赛报名与自由组队：状态机设计和并发控制
3.1 报名状态机：从提交到审核的完整流转
学科竞赛训练管理系统里最容易出问题的不是写代码，而是定义「状态」。我见过一个版本把所有状态塞进一个字段 header 里，最后状态变成一锅粥。报名流程看起来简单，但每个节点都有真实发生的操作：学生提交报名、系统校验队伍人数、指导老师审核、驳回后重新提交、报名截止后整体锁定。这些不能靠 if/else 散写在视图函数里，要收敛成状态机。
# services/enrollment_service.py from enum import Enum from django.db import transaction from django.core.exceptions import ValidationError class EnrollmentState(str, Enum): PENDING = "pending" APPROVED = "approved" REJECTED = "rejected" class EnrollmentMachine: """报名的状态机：禁止非法状态迁移""" ALLOWED_TRANSITIONS = { EnrollmentState.PENDING: {EnrollmentState.APPROVED, EnrollmentState.REJECTED}, EnrollmentState.REJECTED: {EnrollmentState.PENDING, EnrollmentState.APPROVED}, EnrollmentState.APPROVED: {}, } def __init__(self, enrollment): self.enrollment = enrollment def can_transition(self, target_state): current = EnrollmentState(self.enrollment.status) return target_state in self.ALLOWED_TRANSITIONS[current] def approve(self): if not self.can_transition(EnrollmentState.APPROVED): raise ValidationError("当前状态不能通过审核") self.enrollment.status = EnrollmentState.APPROVED self.enrollment.save(update_fields=["status", "updated_at"]) def reject(self): if not self.can_transition(EnrollmentState.REJECTED): raise ValidationError("当前状态不能驳回") self.enrollment.status = EnrollmentState.REJECTED self.enrollment.save(update_fields=["status", "updated_at"]) def create_enrollment(student, competition, team): """创建报名记录，同时校验比赛状态和队伍归属""" with transaction.atomic(): if competition.status != "registration": raise ValidationError("该比赛不在报名期内") if team.competition_id != competition.id: raise ValidationError("队伍不属于该比赛") enrollment = Enrollment(student=student, competition=competition, team=team) enrollment.full_clean() enrollment.save() return enrollment逻辑说明：EnrollmentMachine把状态迁移规则集中管理，后续加状态（比如「已参赛」「已完赛」）只需要在这个类里加枚举值和迁移表。transaction.atomic()保证报名记录创建和队伍状态的一致性，如果后续还要扣减队伍名额，这个事务块里应该一起操作。full_clean()会触发模型层的字段校验和唯一约束检查，确保同一学生不会重复报名。
参数说明：update_fields列表里指定只更新 status 和 updated_at，避免 save() 时把所有字段重写一遍，减少并发场景下的冲突面。状态机里 REJECTED 可以回到 PENDING，这是因为驳回后学生修改信息重新提交是真实需求，不设这条迁移后面就会有人绕过代码直接改数据库。
3.2 自由组队：邀请制 + 队长的线程模型
自由组队的核心矛盾是「谁都想做队长」和「队长必须唯一」。我最终采用的方案是：队长创建队伍，成员通过邀请链接或搜索队名申请加入，队长审批。所有组队操作都只允许队长执行，队员只能退出。这跟 QQ 群的管理模型一致，学习成本最低。
# views/team_views.py from django.db import transaction from django.shortcuts import get_object_or_404 from django.contrib.auth.decorators import login_required from django.http import JsonResponse from django.core.exceptions import ValidationError @login_required def lock_team(request, team_id): """队长锁定队伍：锁定的同时创建所有成员的报名记录""" team = get_object_or_404(Team, id=team_id, leader=request.user) if team.status == "locked": return JsonResponse({"error": "队伍已锁定，不能再操作"}, status=400) with transaction.atomic(): # 先更新队伍状态，再创建报名记录，防止并发下重复报名 locked = Team.objects.select_for_update().get(id=team.id) member_ids = list(locked.members.values_list("id", flat=True)) if len(member_ids) + 1 < 2: # 队长算一个 raise ValidationError("至少需要2人才能锁定队伍") if len(member_ids) + 1 > locked.competition.max_team_size: raise ValidationError("队伍人数超过比赛上限") locked.status = "locked" locked.save(update_fields=["status"]) for uid in member_ids: Enrollment.objects.get_or_create( student_id=uid, competition_id=locked.competition_id, defaults={"team": locked, "status": "pending"}, ) return JsonResponse({"message": "队伍已锁定并提交审核", "team_id": team.id})逻辑说明：select_for_update()是并发控制的关键——两个学生同时提交锁定请求时，数据库行锁保证只有一个事务能读到当前队伍状态，另一个会阻塞到第一个事务提交后再执行。get_or_create处理边界情况：队伍可能处于 forming 状态时已有部分成员单独提交过报名（比如先报名后组队的流程），此时不会重复插入。锁定动作和报名记录创建放在一个事务里，避免出现「队伍锁了但报名没提交」的中间态。
参数说明：member_ids + 1里那个 1 是队长本人，很多系统在这里忘掉队长也在队伍里。人数校验必须读competition.max_team_size而不是硬编码 3，因为不同比赛组队上限不同。锁定后成员列表不可变，后续成绩录入按锁定时的成员名单为准，这能避免比赛中途有人换队导致成绩算错。
3.3 报名截止的自动化处理
报名截止不是简单把按钮置灰，要做的是自动把截止前已锁定但未审核的队伍批量置为「待审核」，给指导老师生成待办提醒。我一般用 Django 的manage.py命令加 crontab 跑批量任务，不用 Celery——这个项目级别用消息队列是杀鸡用牛刀。
# management/commands/close_registration.py from django.core.management.base import BaseCommand from django.utils import timezone from django.db import transaction from competitions.models import Competition from teams.models import Team class Command(BaseCommand): help = "关闭截止的报名窗口" def handle(self, *args, **options): now = timezone.now() expired = Competition.objects.filter( status="registration", register_end__lte=now, ) for comp in expired.iterator(): with transaction.atomic(): comp.status = "in_progress" comp.save(update_fields=["status"]) # 所有未锁定队伍自动解散，锁定队伍流转到待审核 Team.objects.filter(competition=comp, status="forming").update(status="disbanded") Team.objects.filter(competition=comp, status="locked").update(status="submitted") self.stdout.write(f"已关闭报名: {comp.name}")逻辑说明：iterator()在比赛数量多时不把所有对象一次性加载进内存。未锁定队伍直接解散，因为报名截止时还没定员的队伍本质上就是没组起来，留着会在后续成绩录入阶段产生大量空队伍。锁定队伍置为 submitted，进入老师审核队列，这是一个中间态，区别于学生刚提交的 pending。
4. 水平分析：让数据说话的两个核心算法
4.1 等第归一化：把「国一、省二、参与奖」变成可计算的数
水平分析的第一个难题是成绩没有可比性。学校内部赛是百分制，省赛是等第制，国赛可能只有名次。老师最关心的是「这个学生本赛季进步了没有」——但不同赛事对进步的定义完全不同。我的做法是给每个等第打上归一化的标准分，用映射表而不是数据库字段。
# services/scoring_service.py AWARD_LEVEL_MAP = { ("国一", "国际级"): 100.0, ("国一", "国家级"): 95.0, ("国二", "国家级"): 85.0, ("国三", "国家级"): 75.0, ("省一", "省级"): 65.0, ("省二", "省级"): 55.0, ("省三", "省级"): 45.0, ("校一", "校级"): 35.0, ("校二", "校级"): 25.0, ("校三", "校级"): 15.0, ("参与奖", "校级"): 5.0, } def normalize_score(judge_level, competition_category): """把等第+赛事级别转成百分制标准分，用于跨赛事对比""" res = AWARD_LEVEL_MAP.get((judge_level, competition_category)) if res is None: raise ValueError(f"未找到等第映射: {judge_level} / {competition_category}") return res逻辑说明：AWARD_LEVEL_MAP是纯字典映射，放代码里而不是数据库表，原因是这类映射一年可能只调整一次（比如学校突然规定省二从 55 调成 60），代码里改完走 git 记录比数据库里改来改去更容易回滚。等第相同但赛事级别不同，分数必须不同——「省一」在省级赛和国家级赛里的含金量差别很大。
参数说明：标准分的绝对数值没有意义，有意义的是相对关系。国一 100 和参与奖 5 之间拉开 20 倍差距，是为了让获奖学生的水平曲线在雷达图上显著高于未获奖学生。如果学校生源整体水平接近，可以把区间压缩成 40~100 分，但跨度太小会导致水平分析看不出区分度。
4.2 趋势分析：学期内的进步曲线和赛季间的能力迁移
水平分析不能只给一个静态分数。老师真正想看的是：这个学生上学期末还在省三徘徊，这学期国二了，说明训练有效。两个学期不同比赛的分数用归一化后已经可以在同一坐标系里画曲线。
# services/analysis_service.py from django.db.models import Avg, F, Count from competitions.models import Competition from scores.models import Score def get_student_progress(student_id, season="2025-春季"): """计算学生在某个赛季内的参赛次数、平均标准和最高名次""" enrollments = Enrollment.objects.filter( student_id=student_id, status="approved", competition__season=season, competition__status="finished", ).select_related("competition") score_rows = [] for enr in enrollments: latest_score = enr.scores.order_by("-created_at").first() if latest_score: normalized = normalize_score( latest_score.judge_level, enr.competition.category, ) score_rows.append({ "competition": enr.competition.name, "normalized_score": normalized, "award_level": latest_score.judge_level, "category": enr.competition.category, }) if not score_rows: return {"message": "本赛季暂无成绩"} total = len(score_rows) scores = [row["normalized_score"] for row in score_rows] result = { "season": season, "competition_count": total, "avg_score": round(sum(scores) / total, 2), "best_score": max(scores), "best_competition": max(score_rows, key=lambda x: x["normalized_score"]), "trend": _compute_trend(scores), } return result def _compute_trend(scores): if len(scores) < 3: return "样本不足，无法评估趋势" first_half = sum(scores[: len(scores) // 2]) / (len(scores) // 2) second_half = sum(scores[len(scores) // 2:]) / (len(scores) - len(scores) // 2) diff = round(second_half - first_half, 2) return "上升" if diff >= 5 else "下降" if diff <= -5 else "平稳"逻辑说明：分析接口的核心是归一化后的分数序列。first_half/second_half是简化版趋势判断，在参赛次数少的时候比线性回归更稳——一个只打了三场比赛的学生，线性回归会因为第二场爆冷全崩掉。赛季参数要不用字符串而用枚举约束，防止「2025春季」和「2025-春季」两种写法并存。select_related 的懒加载策略是这里性能的关键：不预取所有成绩，只在循环里取各自最新一条，避免多场比赛的场景一次性加载海量数据把内存打爆。
4.3 ELO 评分在竞赛训练场景的变体使用
水平分析的进阶玩法是给每个学生算一个动态 ELO 分。经典 ELO 是给棋手对战用的，竞赛训练场景变一下：把「同一场比赛」视作「所有参赛者与同一对手比赛」，赛后的 ELO 调整按名次梯度分发。这样既能反映长期实力，又不依赖具体的比赛等第映射。
def update_elo_after_competition(enrollment_score_pairs, k_factor=32): """ enrollment_score_pairs: [(enrollment_id, rank), ...]，按名次升序排列 """ n = len(enrollment_score_pairs) if n == 0: return # 获取当前 ELO student_ids = [p[0].student_id for p in enrollment_score_pairs] profiles = StudentProfile.objects.in_bulk(student_ids) elo_values = {sid: profiles[sid].levels.get("elo", 1500) for sid in student_ids} # 两两计算期望胜率，聚合每人的期望得分和实际得分 expected_scores = {sid: 0.0 for sid in student_ids} actual_scores = {sid: 0.0 for sid in student_ids} for i in range(n): for j in range(n): if i == j: continue ea = 1 / (1 + 10 ** ((elo_values[student_ids[j]] - elo_values[student_ids[i]]) / 400)) expected_scores[student_ids[i]] += ea actual_scores[student_ids[i]] += 1 if i < j else 0 # 更新 ELO updates = {} for sid in student_ids: new_elo = elo_values[sid] + k_factor * (actual_scores[sid] - expected_scores[sid]) updates[sid] = round(new_elo, 1) # 批量写回 for enr, _ in enrollment_score_pairs: profile = profiles[enr.student_id] current_levels = profile.levels or {} current_levels["elo"] = updates[enr.student_id] profile.levels = current_levels profile.save(update_fields=["levels"]) return updates逻辑说明：这里的思路是把同一场比赛的 n 名学生视作一个全连接的对战图，排名靠前的人视作战胜了排名靠后的人——这天然符合「比赛名次决定实力关系」的直觉。期望胜率使用标准 ELO 公式，分母 400 是经典参数，惩罚系数取 32 是 ELO 体系里比较稳的默认值。与联赛积分不同，ELO 会自然衰减掉早期运气带来的虚高分，因为每参加一场比赛，你的分值都在向真实实力收敛。
参数说明：k_factor=32在对抗赛中属于中等灵敏度：太低（8~16）则学生打了五六场还看不出水平差异，太高（64+）则单场比赛的偶然性会被过度放大。初值 1500 是 ELO 体系惯例，理论上全校学生的平均分恒定在 1500 附近，不会因为参赛人数逐年增加而整体膨胀。
5. 避坑指南：从权限失控到成绩口径混乱的 5 个典型问题
5.1 指导老师误录成绩覆盖他人记录
现象：两个老师同时录入同一个学生的比赛成绩，后录的那个人直接覆盖了先前老师录的分数，且没有任何提示。原因：Score 表没有唯一的归属标记。解决：给 Score 加recorder字段并做可追溯的变更记录，成绩一旦录入后不直接 UPDATE，而是插入新版本并保留旧记录。
class ScoreVersion(models.Model): """成绩版本表，保留每次编辑的历史痕迹""" score = models.ForeignKey(Score, on_delete=models.CASCADE, related_name="versions") raw_score = models.FloatField("分数") judge_level = models.CharField("等第", max_length=32) recorded_by = models.ForeignKey(User, on_delete=models.PROTECT) updated_at = models.DateTimeField(auto_now_add=True)5.2 并发报名导致同一学生重复出现在两个队伍
现象：学生同时在两个浏览器标签页操作，一个页面创建了 A 队，另一个页面加入了 B 队，两边都显示成功。原因：报名创建逻辑只检查了队伍维度，没在Enrollment模型层加唯一约束。解决：给Enrollment建 UniqueConstraint，并在事务内用数据库约束兜底，应用层检查永远会有竞态窗口。如果你的 Django 迁移已经跑到生产环境，用AddConstraint加这一步要提前评估大表加唯一索引的耗时——数据量几万行以下是安全的。
5.3 成绩口径不统一导致水平分析失真
现象：同一场比赛，数学建模赛按百分比打分（92 分），电子设计赛按等第打分（「省二」），水平分析把两者直接做了算术平均，结果出图表时发现有的学生被算成 200 分。原因：Score 表把原始分和等第并存，没有统一换算层。解决：任何分析接口都先走normalize_score()归一化，不在 SQL 层面对 raw_score 和 judge_level 做混合聚合。这是一个架构决定：原始分数永远保留在库里，展示和分析时再换算，绝不把换算结果写回主表。
5.4 队伍解散后报名记录没清理
现象：学生 A 和 B 组了队，报名已审核通过，后来 B 因个人原因退赛，老师手动把 B 移出队伍，但 B 的报名记录还是「已通过」状态，导致比赛确认名单里出现了 B。原因：从队伍成员表删除成员的操作没有联动更新 Enrollment 表。解决：在队长操作移出成员的 service 方法里，同步把 Enrollment 置为「已驳回」，并让历史版本可见。这个操作必须和成员删除放同一个事务里，否则出现中间态时会更难排查。
5.5 比赛被删除时外键级联引发的历史数据淹没
现象：管理员删掉一个已经结束的比赛，结果所有关联的成绩、证书记录全部被级联删除，学生水平分析里的历史曲线立刻变空。原因：Competition 的外键用了 CASCADE，而实际业务里「删除比赛」应该只是「归档」。解决：把 Competition 的状态改成「已删除」而非物理删除，或者在 on_delete 用 SET_NULL 并让分析接口跳过 status=deleted 的比赛。
6. 让系统真正可用的三个验证手段和两个进阶技巧
先说自己每次交付前必跑三件事：第一，Python 端的单元测试覆盖状态机和归一化映射，因为这两块是业务的核心逻辑，任何改动都可能让曲线分析结果整体偏移；第二，并发报名场景的压测脚本，模拟 100 个学生同一秒提交报名，确认不会出现重复记录；第三，权限回归测试，检查学生不能调 DELETE 接口删队伍——这是 Django 权限系统最常见的漏洞，视图层忘了加装饰器就裸奔。
# 并发报名压测脚本（locust.conf） # 模拟报名截止前的高并发场景 locust --headless -u 100 -r 10 \ --spawn-rate 10 -t 120s \ --host http://127.0.0.1:8000这个脚本跑起来后重点看两个指标：一是数据库的锁等待时间，二是get_or_create的冲突次数。如果并发超过 50 后发现大量锁超时，先检查是不是所有报名接口都加了transaction.atomic()——加和不加在高并发下性能差异是数量级的。
再说两个进阶技巧。第一是给水平分析画「选手画像」，把每个学生的优势赛事类别、参与频率、得分趋势、ELO 波动四个维度聚合成一张缩放图，指导老师可以一秒找出「偏科苗子」——这个功能不需要额外算法，把上面几个服务的结果拼在一张卡片上即可。第二是给报名流程加「候补池」，报名截止后如果有队伍因为资格问题被驳回，候补池里的学生自动顶替——这是我接手过的系统里老师反馈最刚需的功能，因为实际报名中总有人填错信息被驳回，而看到消息时已经错过了重新报名的时间。
我自己的习惯是每学期开学第一天跑一次python manage.py close_registration --dry-run，把所有截止时间快到了的比赛列出来确认一遍，再跑一次水平分析的预热——把上一学期的历史数据先算好缓存，避免开学后老师同时访问时把数据库打死。这个系统的核心价值不在代码量，而在状态机设计和数据口径的统一上。数据库永远存原始数据，换算层只做计算不改写；状态迁移永远走服务层，不留手工改库的后门。这三个月里因为这两条纪律少加了无数个夜班。希望帮到你。
本文还有配套的精品资源，点击获取
