简介基于Python的毕业生信息审核系统源码定位为高校教务、就业办与企业HR处理毕业生信息的管理工具覆盖信息录入、修改、查询、审核与状态流转等核心环节适合希望借助真实工程快速上手Web开发的初学者。资源压缩包共54个文件以45个py源文件为主干其余包括XML配置、Git忽略规则、Markdown说明、TXT依赖清单及IDE工程文件整体仅51KB结构清晰便于按模块阅读。py代码分工明确涉及启动入口、后台业务、接口测试与中间件配置可看到服务端如何组织和管理请求。系统内部还实践了Web框架路由、数据库模型设计、前端交互界面、认证授权、日志记录、状态机审核流以及异常处理已有123人学习浏览。通过研读这份源码可以同时理解ORM建模、权限控制、测试用例与工作流设计的具体写法对搭建同类型信息管理系统或准备Python后端开发岗位都有直接帮助。1. 毕业生信息审核系统是什么一套 Python 源码要解决的三个真实问题每年五月到七月负责毕业生工作的老师大概率会经历同一件事学生发来一连串“我改一下籍贯”“紧急联系人换人了”“家庭住址写错了”你这边收着邮件、改着 Excel还要担心自己改漏了哪一列。所谓“Python 毕业生信息审核系统源码”本质就是把这条“学生自填 → 审核复核 → 归档导出”的链路做成一个完整的 Web 应用。它不是一个只能做个增删改查的 CRUD 架子而是要把“谁可以改、改完谁审、审完怎么留痕、最后怎么批量导出”这四件事在代码层面闭环起来。这个标题里最容易被低估的词是“审核”。很多课程设计把系统做成了单一表单页提交即完成审核只是个摆设。真正在现场跑起来以后你会发现能不能拦住不合格信息、能不能说清每条信息是谁在什么时间改的才是这套源码有没有价值的判断标准。这篇笔记按我最常用的工程路径展开先是选型和目录结构再是数据模型和状态流转然后是核心代码实现最后把我在实际部署中踩过的坑一条条说清楚。适合两类人一是正在做毕业设计、想交一个“真能跑”项目的计算机相关专业学生二是确实需要给学院或班级搭一套内部审核工具、又不想用第三方收费表单的辅导员或教务老师。2. 选型与工程结构Flask 还是 Django源码从哪一层开始读2.1 轻量优先Flask SQLAlchemy 的思路拿到“Python 毕业生信息审核系统源码”这个需求第一个绕不开的选择是 Web 框架。Django 自带 Admin 后台、ORM、认证体系听起来很省事但我一般不建议在毕业生信息审核这种规模的项目上一上来就上 Django除非你明确知道要用它的权限框架做五六个角色的复杂分级。多数毕业生信息审核场景只有学生、班级审核员、学院审核员、管理员四种角色流程也是“填报-审核-通过/驳回-归档”的线性链路用 Flask 加 SQLAlchemy 反而更合适路由和视图在一个文件里就能读完出问题时定位路径短部署时资源占用也低。选 Flask 的第二个理由是“源码可读性”。这类系统大概率会被人拿去做二次开发或写进课程设计说明书Flask 用蓝图模块拆分后学生端的接口、审核端的接口各自独立别人拿到代码后十分钟就能找到“提交按钮对应的路由是哪一行”。如果是 Django光是 settings 和中间件就要花掉不少时间。Flask 的灵活性带来的代价是“很多功能要自己拼”登录会话要靠 Flask-Login 或自己写 Session后台管理页面要自己搭但这些拼装过程恰恰是这套源码体现工程量和技术含量的地方。如果你面对的是上千名学生同时提交的峰值场景Flask 同步模式下每个请求占一个线程确实不如 FastAPI 的异步扛压。但毕业生信息审核有一个天然的优势它不是连续高并发而是集中在三到五天内的间歇性提交每秒几个请求已经是峰值完全在 Flask 的舒适区内。真到了需要上异步的时候改动成本也有限只要把数据库 Session 和上传文件处理的代码收敛在 Service 层后续换框架不需要重写业务逻辑。2.2 目录结构与配置一个可以跑起来的骨架拿到源码后不要急着跑 main.py先把目录结构读懂。我习惯把项目拆成“入口、配置、蓝图、模型、服务、模板、静态”七个部分其中“模型”和“服务”分开是这套结构里最关键的设计决策模型层只放数据库表定义服务层放业务规则。举个例子“学生提交信息时如果已经通过审核就不能再改”这个规则属于服务层不应该写在路由函数里也不应该散落在模板的 JavaScript 里。这样后续要加“辅导员撤回已通过信息”这种新功能只需要在服务层加一个函数路由和页面都不用大改。一个典型的项目骨架长这样graduate_audit/ ├── run.py # 入口文件启动开发服务器 ├── config.py # 配置数据库、密钥、上传目录 ├── requirements.txt # 依赖清单 ├── app/ │ ├── __init__.py # 应用工厂注册蓝图 │ ├── models/ # SQLAlchemy 模型 │ │ ├── __init__.py │ │ ├── student.py # 学生信息表 │ │ ├── record.py # 审核记录表 │ │ └── log.py # 操作日志表 │ ├── services/ # 业务逻辑层 │ │ ├── audit_service.py # 审核状态流转 │ │ └── excel_service.py # 导出归档 │ ├── blueprints/ │ │ ├── auth.py # 登录注销 │ │ ├── student_api.py # 学生端接口 │ │ └── audit_api.py # 审核端接口 │ ├── templates/ # Jinja2 模板 │ └── static/ # 静态资源 └── uploads/ # 身份证照片等附件入口文件 run.py 基本是固定的三板斧创建应用、加载配置、调用app.run。真正花心思的是app/__init__.py里的应用工厂它要完成三件事初始化 SQLAlchemy 的数据库连接、注册三个蓝图对应的 URL 前缀、把上传目录和日志目录创建好。我见过不少源码把这部分全部堆在 run.py 里短期内能跑但一旦出现“数据库会话冲突”或者“蓝图注册顺序不对”这类问题排查起来就非常痛苦。config.py 的配置项建议拆分环境来写至少要有开发环境和生产环境两套import os class Config: SECRET_KEY os.environ.get(SECRET_KEY, dev-secret-key) SQLALCHEMY_DATABASE_URI os.environ.get( DATABASE_URL, sqlite:///graduate.db ) SQLALCHEMY_TRACK_MODIFICATIONS False MAX_CONTENT_LENGTH 5 * 1024 * 1024 # 限制上传 5MB UPLOAD_FOLDER os.path.join(os.getcwd(), uploads) ALLOWED_EXTENSIONS {jpg, jpeg, png, pdf} class ProductionConfig(Config): SQLALCHEMY_DATABASE_URI os.environ.get( DATABASE_URL, mysqlpymysql://root:passwordlocalhost/graduate_audit ) SECRET_KEY os.environ.get(SECRET_KEY)这段配置里有三个参数需要按现场情况调整。第一是数据库连接字符串开发环境用 SQLite 可以做到零配置开箱即用但生产环境一定要切 MySQL 或 PostgreSQL否则多个人同时连接时极易出现“database is locked”。第二是MAX_CONTENT_LENGTH毕业生要上传证件照很多学生手机拍的图一张就是七八兆5MB 限制一不留神就触发“请求实体过大”报错实际部署时我会按学校图像采集的规格放宽到 10MB。第三是UPLOAD_FOLDER别用相对路径写死在代码里因为后面用 Gunicorn 或 Nginx 部署时工作目录可能和开发时不一样相对路径会让你到处找不到文件。提示SECRET_KEY必须用环境变量注入不要提交到代码仓库里。开发时的默认值只能保证本地跑通如果连生产环境都用同一个默认值Session 就有被伪造的风险。Requirements 文件也值得说明一下Flask、Flask-SQLAlchemy、Flask-Login、openpyxl、pytest 这几个是主力依赖缺一不可。openpyxl 用来做审核通过后的批量导出pytest 用来给审核流程写自动化验证。版本号建议在 requirements.txt 里锁定到次要版本因为 Flask 的大版本升级经常伴随 Jinja2 和 Werkzeug 的兼容性变化源码交到别人手上时依赖版本不一致是“跑不起来”的第一大原因。3. 数据模型与状态流转毕业生信息为什么必须用状态机而不用布尔值3.1 三张核心表学生信息、审核记录、操作日志的字段设计毕业生审核系统里最核心的表不是学生信息表本身而是记录“谁在什么时候做了什么”的那几张表。学生信息表只负责保存当前状态审核记录表负责保存状态变更的历史操作日志表负责保存所有敏感操作。三者分开是因为它们的变化频率和查询方式完全不同学生信息表每秒都在被读审核记录表和日志表则在审计时才会被翻出来。先看学生信息表的定义。用 SQLAlchemy 写的话重点在于区分“学生自己填的字段”和“系统管理字段”class StudentInfo(db.Model): __tablename__ student_info id db.Column(db.Integer, primary_keyTrue) student_no db.Column(db.String(20), uniqueTrue, nullableFalse, indexTrue) name db.Column(db.String(50), nullableFalse) gender db.Column(db.String(2)) id_card db.Column(db.String(32)) # 加密后存储 phone db.Column(db.String(20)) emergency_contact db.Column(db.String(50)) emergency_phone db.Column(db.String(20)) home_address db.Column(db.String(255)) photo_url db.Column(db.String(255)) status db.Column(db.String(20), defaultDRAFT) submit_time db.Column(db.DateTime) reviewer_no db.Column(db.String(20)) # 最后审核人 review_time db.Column(db.DateTime) reject_reason db.Column(db.String(255)) update_time db.Column(db.DateTime, defaultdb.func.now(), onupdatedb.func.now()) def to_dict(self): return { student_no: self.student_no, name: self.name, gender: self.gender, phone: self.phone, emergency_contact: self.emergency_contact, status: self.status, review_time: self.review_time, }几个容易被忽略的设计点一是student_no上要建唯一索引同一时间只能存在一条学生档案如果从旧 Excel 系统迁移数据重复学号导入时必须先做去重。二是id_card这个字段建议加密存储推荐用cryptography库做 AES 加密密钥从环境变量读入至少在接口返回和页面展示时要做脱敏只显示前四位和后四位否则学生在列表页里互相能看到身份证号这就是事故。三是status用字符串常量而不是数字数字状态未来回头看代码你得翻字典才知道 2 和 3 各自代表什么直接写 DRAFT、SUBMITTED、APPROVED 让日志输出可读得多。审核记录表的设计更简单它存的是一次完整的“提交-通过/驳回”周期class AuditLog(db.Model): __tablename__ audit_log id db.Column(db.Integer, primary_keyTrue) student_no db.Column(db.String(20), indexTrue) # 关联学生 action db.Column(db.String(20)) # SUBMIT / APPROVE / REJECT operator_no db.Column(db.String(20)) # 操作人工号 operator_role db.Column(db.String(20)) # 操作人角色 comment db.Column(db.String(500)) # 审核意见或驳回原因 create_time db.Column(db.DateTime, defaultdb.func.now())这张表的operator_role字段很重要。审核的时候系统要区分“学生自己提交”和“辅导员代提交”同一张表里只有知道操作人角色后续查“某学院审核了多少条”才能统计得明白。业务上还有一个常见要求是“撤销后要有痕迹”如果这个系统连撤销记录都不保留后续如果上面追责下来你连原始凭证都拿不出来。3.2 状态机与权限把「谁能审核谁」写进代码而不是口头约定毕业生信息从学生首次填写到最终归档至少要经过五个状态DRAFT草稿、SUBMITTED待审核、APPROVED已通过、REJECTED已驳回、ARCHIVED已归档。网上很多开源项目的翻车点在于只用一个布尔字段is_approved然后页面里同时出现“通过”和“驳回”两个按钮谁点了都会把状态改成 True驳回和通过就变成了一回事完全失控。状态流转要有一个准入门槛函数式写法如下STATE_TRANSITIONS { DRAFT: [SUBMITTED], SUBMITTED: [APPROVED, REJECTED], REJECTED: [SUBMITTED], APPROVED: [ARCHIVED], ARCHIVED: [], } def transition_state(student, target_state, operator_no, operator_role, comment): old_state student.status if target_state not in STATE_TRANSITIONS.get(old_state, []): raise ValueError(f非法状态迁移: {old_state} - {target_state}) student.status target_state if target_state REJECTED: student.reject_reason comment db.session.add(AuditLog( student_nostudent.student_no, actiontarget_state, operator_nooperator_no, operator_roleoperator_role, commentcomment, )) db.session.commit()这段代码把状态机收在了一处。新加一种“撤回已通过信息”、回退到待审核状态只需要改STATE_TRANSITIONS字典和对应的服务函数路由层、模板层不用动。这是最省力的设计方式。权限控制的重点则在于“范围”系统里不同角色能看的范围就像一个漏斗管理员看全校学院审核员看本学院班级辅导员看本班学生只能看自己。实现上通常是在每一个查询接口里强制带上数据范围条件而不是把数据全部查出来再在内存里滤。我见过有源码在班级页面上写“本班所有学生”就直接StudentInfo.query.all()然后把筛选逻辑交给前端等于把权限管理做成了装饰品。其一会被授人以柄其二两三万条数据一次性推给前端浏览器直接卡死。注意对辅导员身份要校验“这条学生记录属于你的班级”对学院审核员要校验“这个学生的学院和你的学院一致”。很多人只在接口入口校验了“你有没有登录”没有校验“你有没有权限动这条数据”这是审核系统里性质最严重的一类漏洞。4. 核心流程实现从学生填报到审核员通过的最小闭环4.1 登录鉴别与角色识别一个 Session 怎么区分学生和辅导员登录是整套系统的入口也是所有权限判断的基础。用 Flask-Login 还是自己写 Session如果项目已经有现成的登录模块用现成的没问题从头开始的话我习惯自己封装一个轻量登录接口生成一个带过期时间的 Session把用户 ID、姓名、角色三个字段写进去校验时统一从 Session 里取。auth_bp.route(/login, methods[POST]) def login(): data request.get_json() account data.get(account, ).strip() password data.get(password, ) user User.query.filter( db.or_(User.student_no account, User.employee_no account) ).first() if not user or not check_password_hash(user.password_hash, password): return jsonify({code: 400, msg: 账号或密码错误}), 400 login_user(user, rememberdata.get(remember, False)) session[role] user.role return jsonify({ code: 0, role: user.role, redirect: /student if user.role STUDENT else /review })这个接口有两个容易踩的细节。第一查询条件里用了db.or_学生和辅导员从同一个用户表查询但区分身份靠的是 role 字段否则学号和工号重复时会出现“学生身份登录进去了看到的却是审核页面”。第二密码存储必须用hashlib的加盐哈希或 Werkzeug 的generate_password_hash有些源码直接明文存密码学生之间看到源码就能拿着别人的账号到处试这是底线问题。登录之后的权限校验每个需要身份的路由前都建议加一个装饰器from functools import wraps def role_required(*roles): def decorator(f): wraps(f) def wrapper(*args, **kwargs): if not current_user.is_authenticated: return jsonify({code: 401, msg: 未登录}), 401 if current_user.role not in roles: return jsonify({code: 403, msg: 无权限}), 403 return f(*args, **kwargs) return wrapper return decorator装饰器写好后路由上直接标注“这接口只有班级辅导员能调”权限就具象到了代码的每一行而不是只靠前端把“审核”按钮藏起来。4.2 填报与提交暂存草稿、触发审核、防止重复提交学生在系统里填写个人信息跟“审核”一样重要的是“提交”本身。这里要处理三个问题信息没填完怎么暂存填完了怎么触发审核提交之后发现自己填错了能不能撤回。很多学生是一边翻户口本一边填表的所以系统必须有暂存功能student_bp.route(/api/info, methods[POST]) role_required(STUDENT) def save_info(): form request.get_json() student StudentInfo.query.filter_by( student_nocurrent_user.student_no ).first() if student.status ARCHIVED: return jsonify({code: 400, msg: 已归档不能再修改}), 400 student.name form.get(name, student.name) student.gender form.get(gender, student.gender) student.id_card form.get(id_card, student.id_card) student.phone form.get(phone, student.phone) student.emergency_contact form.get(emergency_contact, student.emergency_contact) student.home_address form.get(home_address, student.home_address) db.session.commit() return jsonify({code: 0, msg: 保存成功})保存接口的截止条件只拦截了“已归档”这一种状态。也就是说即使在“待审核”状态下学生也还能保存信息草稿、修改里面尚未提交的部分。实际业务中这会引起一个问题学生先提交辅导员在审核页面上打开时看到的还是旧数据学生又保存了新的没提交两边信息对不上。所以正式提交动作必须跟暂存分开并且执行时校验当前状态必须为 DRAFT 或者 REJECTEDstudent_bp.route(/api/submit, methods[POST]) role_required(STUDENT) def submit_info(): student StudentInfo.query.filter_by( student_nocurrent_user.student_no ).first() if student.status not in (DRAFT, REJECTED): return jsonify({code: 400, msg: 当前状态不可提交}), 400 missing validate_required_fields(student) if missing: return jsonify({code: 400, msg: f缺少必填字段: {, .join(missing)}}), 400 student.status SUBMITTED student.submit_time datetime.now() db.session.add(AuditLog( student_nostudent.student_no, actionSUBMIT, operator_nocurrent_user.student_no, operator_roleSTUDENT, )) db.session.commit() return jsonify({code: 0, msg: 提交成功})必填校验写在服务层的好处是换一套前端框架也绕不过校验。身份证号和手机号这类字段前端做格式提示就好后端接口里必须再做一次完整校验否则学生把规定放一边直接从 Postman 里发请求脏数据照样进库。常见的后端校验用正则处理就能覆盖绝大多数场景import re def validate_required_fields(student): missing [] if not student.name: missing.append(姓名) if not student.id_card or not re.match(r^\d{17}[\dXx]$, student.id_card): missing.append(身份证号) if not student.phone or not re.match(r^1[3-9]\d{9}$, student.phone): missing.append(手机号) if not student.home_address: missing.append(家庭住址) return missing这里的要点是“身份证号格式是否正确由后端管、长度限制由数据库管、脱敏展示由模板管”三层各司其职。正则只管格式不管真伪真伪校验需要接入第三方实名接口一般校内系统不会做到这一步但格式校验能挡住八成的手误。4.3 审核动作与批量导出通过、驳回、批量通过、归档 Excel审核端是这套系统的价值高地。班级辅导员登录后看到的不是一张只读表格而是一个待办工作台按“待审核”“已通过”“已驳回”“已归档”四个页签区分每个页签都可以按学号、姓名、提交时间范围搜索待审核默认按提交时间升序排列确保先提交的先审。待审核列表的接口很直接但有一条容易漏辅导员只能看到自己班级的学生。查询要带一个class_id条件这个条件从当前登录用户的信息里取不能让学生自己传上来audit_bp.route(/api/pending, methods[GET]) role_required(CLASS_TUTOR, COLLEGE_REVIEWER) def pending_list(): page request.args.get(page, 1, typeint) page_size request.args.get(page_size, 20, typeint) keyword request.args.get(keyword, ).strip() query StudentInfo.query.filter_by(statusSUBMITTED) if current_user.role CLASS_TUTOR: query query.filter_by(class_idcurrent_user.class_id) if keyword: query query.filter( db.or_( StudentInfo.student_no.like(f%{keyword}%), StudentInfo.name.like(f%{keyword}%), ) ) pagination query.order_by(StudentInfo.submit_time.asc()).paginate( pagepage, per_pagepage_size, error_outFalse ) return jsonify({ code: 0, items: [s.to_dict() for s in pagination.items], total: pagination.total, })审核动作就两个通过、驳回。但驳回必须带理由否则学生被退回来不知道为什么改又要打电话来问浪费时间。驳回理由可以设计成常见选项加自由输入的组合身份证号与学籍信息不符、照片不清晰、紧急联系人电话打不通、地址不完整。每一项驳回理由存进AuditLog.comment页面上学生可以看到完整的审核历史不用再去微信群里问“我哪填错了”。这个 UX 细节比任何功能都能减少沟通成本。批量通过是这个系统能上手的真正原因。几百个学生集中提交后辅导员不可能一条条点通过按钮所以界面要支持勾选多条并批量操作audit_bp.route(/api/approve, methods[POST]) role_required(CLASS_TUTOR) def batch_approve(): data request.get_json() student_nos data.get(student_nos, []) if not student_nos: return jsonify({code: 400, msg: 未选择任何学生}), 400 students StudentInfo.query.filter( StudentInfo.student_no.in_(student_nos) ).all() for s in students: transition_state(s, APPROVED, operator_nocurrent_user.employee_no, operator_roleCLASS_TUTOR, comment批量通过) return jsonify({code: 0, msg: f已通过 {len(students)} 人})导出归档是毕业季的高频动作。学院需要把所有通过审核的学生信息按固定模板导成 Excel 交给就业办或档案馆。我在 excel_service.py 里封了一个函数核心是用 openpyxl 的 Workbook 创建表格把学生列表逐行写入from openpyxl import Workbook from openpyxl.styles import Alignment, Font from openpyxl.utils import get_column_letter def export_graduates(student_list, output_path): wb Workbook() ws wb.active ws.title 毕业生信息 headers [学号, 姓名, 性别, 身份证号, 手机号, 紧急联系人, 家庭住址] ws.append(headers) for cell in ws[1]: cell.font Font(boldTrue) cell.alignment Alignment(horizontalcenter) for s in student_list: ws.append([ s.student_no, s.name, s.gender, mask_id_card(s.id_card), # 脱敏后导出 s.phone, s.emergency_contact, s.home_address, ]) for col_idx in range(1, len(headers) 1): ws.column_dimensions[get_column_letter(col_idx)].width 18 ws.column_dimensions[A].width 22 wb.save(output_path)导出时身份证号必须做脱敏处理即使审核通过后供归档使用的 Excel 也一样。学号列格式必须设置为文本而不是数字否则超过 15 位的长数字会被 Excel 自动变成科学计数法这一条在下一章的避坑里还要展开说。导出文件名建议用“学院-年份-毕业生审核结果.xlsx”这种带生成时间的命名避免一个文件被反复覆盖后找不回旧版本。5. 常见问题与排查轮子装上就跑的四个坑5.1 现象身份证号在页面里变成“4.1029E17”导入或导出 Excel 时身份证号显示成科学计数法这是毕业生信息系统里最经典的黑匣子问题之一。原因不是 openpyxl 写错了而是 Excel 和 WPS 对超过 11 位的数字列默认按数值处理15 位以上的数字自动转成科学计数法显示更麻烦的是它只是“显示”成这样单元格里的原值可能已被截断后面的 4 位全变 0无法恢复。解决方法是写两处代码。一处是导出端对身份证号、学号这类长数值列设置单元格格式为文本。openpyxl 里最简单的方式是构造单元格时直接写字符串再显式设一下数字格式双保险cell ws.cell(rowr, column4) cell.value s.id_card cell.number_format cell.alignment Alignment(horizontalcenter)另一处是导入端当系统支持从 Excel 批量导入初始数据时pandas 读取身份证列必须指定 dtype 为字符串。经常有人在pd.read_excel里不写 dtype读出来变成 floatid_card 里出现.0的后缀后面匹配学号死活匹配不上。正确写法是pd.read_excel(path, dtype{身份证号: str, 学号: str})。这个坑几乎谁都会踩一到两次血的教训是只要字段内容可能有前导零或超长数字读的时候就按字符串读。5.2 现象学生提交了照片审核页却显示“文件不存在”文件上传功能在本地跑没问题部署到服务器上后学生一传照片就 404。这类问题的根源几乎都在路径拼接上。开发时uploads目录就在项目根目录下一切正常部署时如果用了 Gunicorn有些人的工作目录写的是/home/ubuntu而源码在/var/www/graduate_audit运行时os.getcwd()拿到的是启动目录而不是项目目录上传文件保存到了别处显示路径也就对不上。解决办法是上传目录在初始化应用时用绝对路径固定下来不要运行时再算import pathlib BASE_DIR pathlib.Path(__file__).resolve().parent.parent UPLOAD_FOLDER BASE_DIR / uploads同时建议把校验扩展名的函数单独写一个只允许 jpg、jpeg、png、pdf。不要用secure_filename后直接保存用户提供的文件名因为某些系统的文件名里带中文或括号保存到 Linux 上会触发 UnicodeEncodeError。保险做法是跟学号绑定重命名比如2021001001_idcard.jpg这样不仅避免乱码后续按学号找附件也方便。5.3 现象审核通过后学生还能改数据而且没留底有一次学院反馈说“某个学生自己把党员身份改了但审核记录里查不到”。排查下来原因很直接页面上的“编辑”按钮没有跟状态挂钩学生即使通过了审核也还能看到编辑入口而编辑接口只判断了登录状态没审核状态。改完数据后 UPDATE 语句执行成功但没有任何字段记录“这次修改是谁发起的”。解决方法是把“谁能修改什么状态的数据”收口到服务层并且强制所有修改操作写审计日志。最简单的实现是在模型上设置一个状态守卫只暴露一个服务入口def update_student_info(student, new_data, operator_no): if student.status not in (DRAFT, REJECTED): raise ValueError(当前状态不允许修改) for key, value in new_data.items(): setattr(student, key, value) db.session.add(AuditLog( student_nostudent.student_no, actionUPDATE, operator_nooperator_no, comment学生修改信息, )) db.session.commit()这里的重点是“修改”和“审核”共用同一个入口任何人改数据都必须经过这个函数日志就必须留下记录。很多源码的问题在于每个路由函数里自己写db.session.add和commit时间一长就有人绕过服务函数直接操作了模型审计链就断了。后来我把规则定死凡是修改表数据的操作一律走服务层函数路由里不允许出现db.session.add。5.4 现象学生提交后辅导员立即审核打开页面发现表单留空这是并发场景下常见的“灵异事件”本质是 HTTP 的 GET 和 POST 请求打到数据库时出现了读写竞争。学生先点了“提交”POST 请求刚把状态改成 SUBMITTED在同一秒内辅导员刷新列表GET 请求查出来的数据里 status 字段还是 DRAFT等辅导员点开详情页时浏览器的静态页面缓存又挡了一层。这个现象在 SQLite 开发环境里几乎不会出现但切到 MySQL 后因为事务提交时机不同就频繁冒出来了。解决的思路是让提交动作写库后强制提交然后前端用轮询或手动刷新拉取详情页的新数据。后端方面把提交接口里db.session.commit()挪到状态变更之后立即执行不要等到响应序列化之后再统一 commit因为有一些 ORM 的默认行为是延迟提交到路由结束时。前端方面详情页永远不要用浏览器缓存在审核页面的响应头上加一句禁用缓存的声明即可。另外一个容易被忽略的点是“提交”接口要加防重入限制学生在提交按钮上连点两次就会发两个 POST第二次进来时状态已经是 SUBMITTED必须返回“当前状态不可提交”而不是继续执行提交动作这条校验我在前面的代码里已经写进了submit_info。6. 验证方法与一个进阶技巧确认源码跑通之后怎么验收和加固系统写完不是一个登录页面能打开就算完事审核类系统尤其要验证“状态是否按规则流转”。我给这类源码做验收时会写一套 Pytest 接口测试模拟“学生注册并提交 → 辅导员驳回 → 学生修改并重新提交 → 辅导员通过 → 管理员归档”的完整链路每个环节都断言数据库里的状态值正确、日志表里有对应记录。这套测试脚本建议保存到 tests 目录中一并交付因为以后改代码时如果跑挂了测试能第一时间告诉你改了哪行破坏了哪个环节比黑匣子式的“点几次页面发现不对”高效得多。进阶技巧是给“批量通过”加一个“按班级模板预填”的功能。毕业生的家庭住址、紧急联系人这种字段同一个班的学生填出来的格式千奇百怪有的写“××省××市××区”有的只写“××小区”。班主任审核时看着不统一导出后也不像正式档案。常见做法是在学生端填报页的每一项旁边加格式提示审核端则提供一个“全表检查”的辅助脚本把常见的不规范写法比如地址里漏了省名、手机号写了两个连续数字扫描出来标黄。这个功能不需要复杂算法一条正则加一个规则列表就能做到七成效果。这套验证脚本和辅助功能都做完之后系统才能在毕业季真正扛得住事。我自己的教训是审核系统的价值不在于界面多花哨而在于每个状态变化都有依据、每个操作都能追溯编码实现时多写一个校验、多记一条日志现场就少一通解释电话。希望这份笔记能帮你把源码跑通、把流程看透做出一套自己心里有底的信息审核系统。希望帮到你。本文还有配套的精品资源点击获取