每年9月到次年6月，研招办都是学校里最忙的部门之一。为了把校园研究生招生研招网平台做好，我从Python技术栈入手，先后对比了Django和Flask两套框架，最终用Django完成了一套可稳定运行的招生管理平台。这篇文章就是对这个项目完整过程的复盘。报名信息散落在Excel表格和PDF扫描件里，院系秘书挨个核对身份和学历信息，复试通知靠邮件加电话，拟录取名单反复对了好几遍还有出入——这些场景相信做过同类系统的人都不陌生。文章会从需求拆解、技术选型、数据模型、核心功能实现讲到部署和排坑，希望能给正在做研招平台或同类管理系统的你一些参考。
1. 先把流程理顺，再谈写代码
1.1 研招平台涉及的五个角色和真实痛点
研招平台不是简单的“报名系统”。我实际做下来发现，它至少连接了五类人，每一类人对系统的期待都不一样。
考生是系统的直接使用者，他们要注册账号、维护基本信息、选择专业方向、上传报名材料、接收审核反馈、查询初试成绩、确认复试安排、查看拟录取结果。他们最在意三件事：信息能不能及时看到、材料上传后有没有明确回执、出现问题时能不能找到人工咨询入口。院系秘书是日常使用最频繁的角色，他们要维护本院系专业目录和招生计划、审核报名资格、组织复试时间安排、录入复试成绩。他们最烦的是反复向考生要材料，以及手工对比不同渠道提交的信息是否一致。研招办工作人员关注全局，他们要发布招生简章、设定分数线、审定拟录取名单、生成上报数据，最怕的是统计口径不统一，每年填报各种报表时从不同Excel里挖数据。导师和评委相对轻量，主要查看报考本方向的考生材料、参与复试评分，部分学校要求匿名评审，这就需要在系统里做姓名和材料的脱敏处理。最后是系统管理员，负责账号权限、异常数据修复和高峰期的稳定性保障。
这些角色凑在一起，产生了几个绕不开的痛点。第一个是“信息孤岛”，同一个考生的材料可能在不同邮件里传来传去，秘书手上一个版本、研招办手里一个版本，最后对不上。第二个是“流程黑箱”，考生不知道自己的材料审核到哪一步、成绩出没出、复试安排是什么，只能打电话问，而电话里常常得不到准确答复。第三个是“统计灾难”，报名统计表、录取统计表字段极多，靠人工从Excel里筛出来既慢又容易错。第四个是“权限模糊”，谁能看到身份证号、谁有资格修改复试分数，纸质办公时代说不清楚，系统里如果不定死，后面一定会出事。
1.2 功能边界怎么划，才不会越做越臃肿
明确需求之后，我第一个动作不是建表，而是画功能清单，并且按优先级砍掉了一大批“看起来很美”的需求。第一版如果上来就做导师匿名评分、考生与导师双向互选、调剂系统、在线笔试，很可能三个月都交不了差。合理的做法是把整个平台分成三期。第一期做考生报名和资格审核，先把“材料收集”这件事线上化，这是整个系统能跑起来的地基。第二期做初试成绩管理和复试安排，核心是成绩发布和通知触达。第三期做拟录取、名单公示和各类统计导出。
这样划分之后，系统的功能边界非常清楚：考生前台负责注册、报名、上传材料、查状态、收通知；管理后台负责招生计划维护、报名审核、成绩管理、复试批次、录取管理、数据导出；导师工作台负责查看考生材料、复试评分入口。至于调剂系统、在线笔试、学费缴纳这些，要么留给后续迭代，要么干脆不做。核心原则是先把数据流打通，让考生信息能够从报名一路流到拟录取，每一步的状态都留痕。
做这类系统，最怕的不是功能少，而是流程没想清楚就堆功能。每加一个模块，状态流转和权限边界都跟着复杂一分。我强烈建议先拿出完整流程图，确认每个节点谁操作、谁审核、数据流向哪里，再开始写代码。
2. 技术选型：Django和Flask，不能靠感觉拍板
2.1 先分清两套框架的定位差异
在决定用Django还是Flask之前，先明确一点：这两个框架解决问题的层次完全不同。Django是“全家桶”风格的框架，自带ORM、Admin后台、用户认证、表单处理、数据库迁移、中间件等一整套基础设施，它的设计目标就是让开发者在默认约定下快速完成一个完整可用的Web应用。Flask是“微框架”，核心只帮你做路由分发、请求和响应封装、模板渲染，数据库要用SQLAlchemy自己接，登录要装Flask-Login，后台管理还得另找Flask-Admin之类的第三方库，所有东西都需要自行拼装。
| 对比维度 | Django | Flask |
|---|---|---|
| 核心定位 | 全功能Web框架 | 轻量微框架 |
| 内置ORM | 有，且迁移机制成熟 | 无，需集成SQLAlchemy |
| Admin后台 | 自带，可快速自定义 | 需Flask-Admin扩展 |
| 用户认证与权限 | django.contrib.auth开箱即用 | 需自行集成第三方库 |
| 适用项目 | 中大型业务系统、管理后台 | 小型API服务、原型、微服务 |
| 学习成本 | 概念多但有完整体系 | 上手快但全貌需自己拼 |
2.2 这个项目我选Django的四个具体理由
研招网平台本质上是一个“多角色、有复杂状态流、需要后台管理”的业务系统，这类项目恰好是Django的主场。第一个理由是自带Admin后台，这一点在研招项目里特别值钱。报名高峰期，研招办的老师需要随时手工查一条记录、改一个状态、导出某个院系的报名名单。Django Admin可以快速定制成可用的运营后台，早期开发阶段甚至能让老师直接在Admin里完成大部分管理工作，开发工作量骤减。换成Flask，这些功能全部要从零开发。第二个理由是用户和权限体系完整。Django的auth系统直接提供了User、Group、Permission三种概念，可以自然地把考生组、院系秘书组、研招办管理员组映射进去，后续做数据权限过滤时也能基于这些模型平滑扩展。第三个理由是ORM和迁移机制完善。研招平台涉及十几张关联紧密的表，Django ORM的select_related、prefetch_related让复杂查询写起来很舒服，makemigrations和migrate让字段变更是件轻松事，这在需求还会不断微调的项目阶段非常重要。第四个理由是生态稳定。Django有大量面向内容管理、后台任务、接口文档的第三方组件，长期维护的案例和文档非常多，即使团队换了人，接手成本也远低于一堆自定义拼装的Flask代码。
那什么情况下我会反过来选Flask？如果团队已经有了一套独立的前端框架，后端只需要提供纯API；或者系统只是某个更大平台里的一个模块，功能非常聚焦；再或者你只是想快速验证一个原型，Flask更灵活也更轻。研招平台这种“全流程管理、界面众多、角色众多”的系统，选Flask会浪费大量时间在拼装底座上，所以我最终选定了Django。版本选择上，我用了Django 4.2 LTS搭配Python 3.10以上，如果后续要单独提供移动端查询接口，再引入Django REST Framework，整个技术路线非常平滑。
3. 数据模型和权限设计，最值得花时间的两个环节
3.1 核心表结构：先画实体关系，再谈建表
数据模型是研招平台的地基。我最初用Excel画实体关系图，把表之间的关系理清楚，然后才在Django里定义models.py。核心表大致有这些：院系表（College）存名称、代码、招生负责人；专业方向表（MajorProgram）挂院系外键，存专业代码、名称、学制、学位类型；招生计划表（RecruitPlan）按学年关联专业，记录计划招生数和已录取数；考生报名表（CandidateApplication）是整套系统的主表，挂用户外键和专业方向外键，记录姓名、性别、身份证号、报考类别、材料提交状态、审核状态；学历信息表（EducationRecord）挂考生报名表外键，存毕业院校、毕业专业、学历层次、证书编号；初试成绩表（ExamScore）存政治、外语、业务课一、业务课二、总分和排名；复试批次与复试记录表（RetestBatch和RetestRecord）管理批次时间地点、面试分组、评委、面试成绩和综合评分；录取记录表（AdmissionRecord）存总成绩、排名、拟录取状态、公示时间；还有一张操作日志表（OperationLog），记录谁在什么时间做了什么操作。
这些表看起来多，核心其实就一条线索：考生报名表是枢纽，几乎所有的业务都围绕它的状态字段流转。招生计划关联专业，考生报名关联计划和考生本身，初试、复试、录取全部挂在报名记录下面。这样的设计有一个明显好处：无论审核、发布成绩还是生成拟录取名单，都能从一条报名记录把所有相关数据取出来，不需要到处join。比如要展示考生中心的完整信息卡片，只需一行查询就能把专业、院系、成绩、复试记录全部带出，ORM的关联查找能力在这里被发挥得淋漓尽致。
3.2 权限控制：既防功能越权，也防数据越权
研招系统的权限设计要回答两个问题：谁能访问什么页面或接口，谁能看到哪一行数据。第一个问题比较好解决，Django用Group给用户分配角色，然后按角色控制菜单和路由。我在项目里定义了四个组：candidate表示考生、college_staff表示院系秘书、admin_user表示研招办管理员、reviewer表示评委。接口层面用自带的装饰器做保护，简单直接。
from django.contrib.auth.decorators import login_required, permission_required @login_required @permission_required('auth.view_candidate_application', raise_exception=True) def review_list(request): ...比功能越权更隐蔽的是数据越权。院系秘书只能看到本院系的考生，评委只能看到分配给自己的复试考生，考生只能看到自己的记录。这类行级权限必须在QuerySet层统一处理，不能靠前端隐藏按钮。我习惯写一个公共查询方法，所有视图、Admin、导出逻辑都从这个方法出发，这样就不会出现“菜单看不见但URL能访问”的漏洞。
def get_user_visible_applications(user): qs = CandidateApplication.objects.all() if user.profile.role == 'college_staff': qs = qs.filter(major__college__staff=user) elif user.profile.role == 'candidate': qs = qs.filter(user=user) return qs.select_related('major', 'user')敏感操作必须留痕。谁改了成绩、谁改了审核状态、谁导出了名单，全部写进OperationLog表。这个设计在出问题追溯时特别有用。我遇到过考生质疑复试成绩被改动的情况，最后靠操作日志完整还原出修改人、修改前数值和修改后数值，几分钟就把争议说清楚了。没有这套日志，类似的质疑会变成无休止的口水战。
3.3 报名状态流转：用状态机把流程固化下来
研招系统的业务核心是一串有顺序的状态：从草稿到提交，到审核，到初试，到复试，到拟录取，再到确认。状态机可以避免系统出现“跳过步骤”和“回头乱改”的问题。我在项目里用choices字段实现状态列表，实际扩展性足够了，不需要引入复杂的状态机框架。
class CandidateApplication(models.Model): STATUS_CHOICES = [ ('draft', '草稿'), ('submitted', '已提交'), ('under_review', '审核中'), ('passed', '审核通过'), ('rejected', '审核驳回'), ('exam_done', '初试完成'), ('retest_invited', '复试通知'), ('admitted', '拟录取'), ('confirmed', '已确认录取'), ('not_admitted', '未录取'), ] status = models.CharField(max_length=32, choices=STATUS_CHOICES, default='draft')状态之间并不是任意可跳的。比如只有审核通过才能进入成绩录入，只有成绩发布后才能进入复试安排，只有复试成绩出来后才能生成拟录取。为了避免脏数据，我在状态变更的地方统一封装了一个service方法，里面写死状态转移规则，不再允许视图里直接update状态字段。这样做之后，业务逻辑变得非常清晰，接口层只需要调用服务方法，状态合法性由服务层保证，数据库里再也不会出现莫名其妙的中间态。
4. 核心功能模块怎么写，才能又稳又实用
4.1 考生报名与材料上传：校验比表单本身更重要
报名页是考生接触系统的第一关，形式上不复杂，麻烦的是材料。常见材料包括身份证扫描件、学历学位证书、成绩单、个人照片、专家推荐信等，每一份材料都要能区分“正在审核”“已通过”“已驳回”。我用ModelForm自动渲染表单，文件存储时按年份、考生号、文件类型三级目录归档，这样每个考生的材料都集中在同一个目录里，后续排查问题非常方便。
文件上传有几个必须处理好的细节。第一是文件类型校验，单纯看扩展名完全不够，改个后缀就能轻松绕过。我用文件头检测库读取真实格式，只有MIME类型匹配才保存，这样即使有人把脚本文件伪装成图片也能被拦下。第二是大小限制，我设置了5MB上限，同时把Nginx的client_max_body_size调成相同数值，否则会出现“前端显示上传成功、后端却拿不到完整文件”的诡异问题。第三是文件名处理，存储时统一用uuid重命名，原始文件名单独存在数据库字段里，这样既避免了中文文件名乱码，也防止了一些特殊字符引发的路径问题。
ALLOWED_UPLOAD_TYPES = { 'pdf': 'application/pdf', 'jpg': 'image/jpeg', 'png': 'image/png', }读取文件头时需要先取字节，再用MIME类型比对，推荐在文件流处理阶段就完成校验，而不是等文件落盘之后再检查。这一步做扎实了，后面审核材料的工作能省一大半力气。
4.2 初试成绩的录入、核对与发布
初试成绩来源于官方考试系统导出的Excel表格，不可能让秘书手工一条条录入。所以我在管理后台实现了一个Excel批量导入模块：先提供固定模板下载，然后使用pandas读取文件，按报考号匹配报名记录，逐行校验分数范围、缺考标记、总分是否等于各科之和，全部校验通过后再统一写入成绩表，同时生成导入报告。
import pandas as pd def import_scores(excel_file): df = pd.read_excel(excel_file) errors = [] valid_rows = [] for _, row in df.iterrows(): # 校验报考号存在、分数非负、总分一致等逻辑 ... # 全部合法才批量写入成绩入库后不能马上公之于众，要先进入“待发布”状态，由研招办负责人二次确认之后才批量发布。发布动作触发邮件通知，考生后台即刻可见。成绩查询页面做成只读，避免考生通过某些手段看到别人的成绩。排名计算在发布时统一写入成绩记录，而不是考生每次刷新都实时计算，这样可以明显降低查询高峰期的数据库压力。
4.3 复试安排与通知：给考生清晰的时间线
复试安排的复杂度容易被低估。每个院系可能有多个批次，每个批次的考生又要分成若干面试小组，每组的时间段和地点都不同。我的表结构设计是：复试批次表表示一次复试安排，包含开始时间、结束时间、地点和专业方向；复试记录表表示某个考生在某批次中的具体记录，包含面试序号、评委组、面试成绩、笔试成绩和综合评分。分组时同一考生不会被分配到同一时间段的两个组，这一点用数据库约束和代码双重保证，避免出现时间冲突。
复试通知必须包含足够信息：考生姓名、复试时间、报到地点、需要携带的材料、复试形式、联系方式。我用邮件模板批量发送，先生成完整通知文件，再走Celery异步任务逐步发送，避免同步发送大量邮件时请求超时。发送状态会被记录下来，未送达的单独生成列表，秘书只要看到未发送标记就能人工跟进。当邮件成功发出后，系统自动把考生状态改为“复试通知已发送”，考生的个人中心立刻能看到复试安排卡片，整个时间线非常清晰。
邮件通知模板我按场景分别维护，复试通知用一种语气，成绩发布又用另一种语气，不同模板之间不混用。文字尽量简洁，重点信息放在邮件开头，因为很多考生在手机上打开邮件，第一屏就能看到关键信息比什么都重要。
4.4 拟录取名单的计算、复核与公示
拟录取名单是整个系统的终局。我这里的算法是总成绩等于初试加权成绩乘以百分之六十加上复试成绩乘以百分之四十，比例可以在后台配置。初试加权成绩按满分五百分折算成百分制。生成列表时，系统按专业方向分组，在每组内按总成绩降序排列，同时过滤掉单科成绩未过线或复试不合格的记录。排序计算在数据库层面完成，坚决避免把全表捞回Python内存再做排序，否则数据量上来之后页面会变得非常慢。
from django.db.models import F, ExpressionWrapper, FloatField admitted = CandidateApplication.objects.filter( status='retest_invited', exam_score__total__gte=line_score ).annotate( final_score=ExpressionWrapper( F('exam_score__total') / 5 * 0.6 + F('retest_record__total_score') * 0.4, output_field=FloatField() ) ).order_by('-final_score')生成列表之后，必须进入复核环节。研招办核对单科线、复核报考资格、确认专项计划名额，然后再转入“公示中”状态。公示页面显示考生的报考号、姓名、专业、总成绩和排名，公示起止日期写清楚。姓名可以按学校要求做脱敏，比如只显示姓氏加星号。公示期结束之后一键锁定，系统自动生成上报用的导出文件，格式直接对接学校要求。公示列表的访问是高峰期热点，我会对公示页面单独做缓存，避免数据库被反复刷爆。候补名额也要预留，统一放在未录取状态里做特殊标记，等前面有人放弃录取后按序递补。
5. 部署上线与高峰期并发，踩过的坑都在这里
5.1 一套稳定可维护的线上部署方案
开发环境能跑通，上线是另一回事。我的生产部署方案是Nginx加Gunicorn加PostgreSQL加Redis，代码放在普通应用服务器上，用systemd管理Gunicorn进程，静态文件和上传文件交给Nginx处理。Django不开DEBUG，SECRET_KEY放到环境变量，数据库账户按最小权限创建。PostgreSQL存业务数据，Redis主要给缓存和Celery消息队列使用。
| 环境项 | 开发环境 | 生产环境 |
|---|---|---|
| Web服务 | runserver | Nginx + Gunicorn |
| 数据库 | SQLite | PostgreSQL |
| 缓存 | 无 | Redis |
| DEBUG | True | False |
| 密钥管理 | settings.py写死 | 环境变量 |
| 后台任务 | 同步执行 | Celery + Redis |
部署中最容易出问题的其实是静态文件和上传文件。Django的runserver会自动处理Static和Media，但生产环境Nginx配置不当就会出现样式全丢、图片加载不出来的情况。我的建议是：collectstatic收集到独立目录，media目录单独挂载，Nginx里写两个location分别指过去。另外，每天自动备份数据库，备份文件保留至少两周，同时定期手工恢复一次验证备份文件确实可用。很多团队每天都在备份，但从来没恢复过，真到出问题那天才发现备份也是坏的，这种教训不值得亲身体验一次。
5.2 报名高峰期，如何让系统不“塌方”
研招系统的流量尖峰非常明显，集中在报名截止前三天和初试成绩发布当天。前者是大量考生同时填表上传，后者是查询成绩的高并发。如果按峰值设计服务器资源基本是浪费，关键还是把热点请求降下来。我把招生简章、专业目录这些静态内容用页面缓存包起来，数据库层面只保留报名提交和成绩发布这两个核心写接口。
查询优化方面，列表页和详情页全程使用select_related和prefetch_related，杜绝N+1查询。成绩排名页面提前计算并写入字段，而不是每次展示都实时算。邮件通知全部进Celery队列异步发送，接口只负责把发送任务交给队列就立刻返回。数据库加了几条常用索引，比如报名表的用户和年份联合索引、成绩表的报名记录和科目联合索引、状态字段的单列索引。如果高峰期还有压力，可以考虑读写分离，但多数学校场景做到这一步已经非常稳了。
防重复提交这件事也很重要。报名截止前考生会紧张地反复点“提交”，有时一下点了好几次。我在报名表上加了用户、年份、专业方向三字段唯一约束，服务端用事务包裹检查加插入，同时在接口层做了简单的IP限流。这样即使前端按钮没有来得及禁用，数据库层也会直接拦下重复记录，后台数据不会变得一团糟。
6. 常见问题排查与实操心得速查
6.1 文件上传相关的三个“假正常”
文件上传这个功能看起来简单，我实际碰到过三种典型问题。第一种是改了扩展名就能绕过格式检查，只用扩展名判断类型完全不安全，用文件头检测库读取真实格式之后，这个问题彻底解决。第二种是超过上传大小限制后请求直接被截断，Nginx的client_max_body_size和Django的配置一定要保持一致，否则日志里会时不时出现“客户端关闭连接”的报错，排查起来非常迷惑。第三种是文件名乱码，解决方法是存储时用uuid重命名，原始文件名单独保存在数据库字段里，原始信息没有丢，展示时也方便。
6.2 权限相关的几个漏网之鱼
权限坑通常不在登录页面，而在那些忘了加装饰器的接口上。我排查时发现过一次，某个导出Excel的视图没有加登录校验，知道URL的人就能直接导出全库数据。这种事在多人协作开发时特别容易发生。我的检查习惯是：所有视图函数先统一过一遍装饰器清单，再用脚本扫描项目里所有视图，自动比对哪些没有权限校验。Admin后台也要定制权限类，不能让普通管理员看到考生身份证号这种敏感字段。操作日志里额外记录了导出行为和下载人，一旦出现数据外泄能快速定位到人。
6.3 数据正确性与性能的三处细节
Excel批量导入的成绩偶尔会出现“导入成功但总数对不上”的情况。根本原因是一些行没有报考号，或者报考号匹配到多条记录。我在导入前先检查重复值，导入后再统计成功行数和总行数，两边不一致就直接拒绝导入。更严格一点，可以给每行数据生成一个哈希值，导入完成后抽样比对，基本能杜绝脏数据混进来。
导出大名单时，我遇到过内存暴涨。直接all()到一个列表再交给Excel库处理不是好办法。我改成数据库流式游标分批读取，每五千行写一批，配合临时文件最终合并，内存占用从几百兆降到几十兆。这个方法在处理上万条记录导出时特别实用，建议所有导出功能都按这个思路处理。
Admin后台在数据量上去之后会明显变慢。常见优化是给list_display关联字段加list_select_related，以及给list_filter字段建好索引。我还在Admin的actions里增加了批量导出CSV的操作，老师们用起来效率高很多。这个环节虽然不直接面对考生，但内部运营体验直接影响研招办对系统的满意度，值得花时间调优。
做完整套研招平台，我最大的体会是：技术本身不是难点，难点在把招生业务流程啃透，再翻译成状态机、数据表和权限规则。先画流程图，再建数据表，最后写代码，这个顺序一旦颠倒，后期返工成本会成倍增加。如果你也在做类似项目，建议上线前一定找院系秘书和研招办老师完整走一遍流程，他们用起来顺不顺，才是系统好不好的最终标准。Django这种自带后台、权限和ORM的框架，在这种多角色、长流程的管理系统里确实省心，值得静下心把基础概念吃透再动手。
