Django+微信小程序实现导师双选：状态管理与并发控制实战-北京尧图网络

1. 导师双选到底难在哪从两张Excel表到抢人现场的升级每年毕业设计季很多高校都在做同一件事把几百个学生分配给几十位导师。表面上看这不就是发个通知、填个表、按成绩排个序吗真去现场盯一轮流程就知道完全不是这么回事。我接手这个项目是在某高校计算机学院当时教务老师给我看了上一年的双选战况几个热门导师的邮箱一天能收到四十多封申请邮件学生在群里反复问老师你收到我的申请了吗导师一边上课一边手动回邮件回到手酸最后还有一批学生没着落教务处只能按专业方向硬调剂。整个过程大概持续了两周期间充斥着乌龙、漏发、误解以及学生反复催问的焦虑。所谓毕业设计导师选择系统本质就是把这条混乱的流程搬上线让双向选择变得透明、有序、可追踪。它不是做一个表格收集工具而是一套包含发布计划、学生填报志愿、导师确认或拒绝、时间窗口控制、结果公示、异常调剂的完整业务系统。核心难点也不是CRUD而是三个字状态管理。谁选了谁、什么时候确认、满了没有、能不能反悔、窗口期过了怎么办——这些状态如果理不清后面全是坑。这篇文章适合三类人读准备自己动手做类似毕设题目的学生需要给学院或实验室搭一个双选流程的工具负责人以及任何想了解一个小程序一套Django后端怎么落地成一整个业务流程的开发者。我会把从需求分析到数据库设计、从接口实现到并发排障、从小程序联调到部署上线的完整链路拆开讲重点写那些文档里查不到、只有真正跑过一版才会明白的细节。先说结论这个系统的成败不取决于你用了多新的前端框架、多牛的云服务而取决于你把双选规则吃透了多少。规则吃透了代码随便写都是顺的规则没吃透堆再多功能上线也是一团乱麻。1.1 高校双选的三个真实痛点三个必须解决的业务问题第一个痛点是信息不对称。学生不知道导师今年带几个名额、研究方向还收不收人、自己的选题跟老师的方向匹配不匹配。导师也不知道学生的成绩、兴趣、有没有已经心仪的课题。传统做法是发一个PDF名单学生照着邮箱海投导师逐个手动回。这个模式下信息是静态的、单向的、延迟的。第二个痛点是流程不可见。学生交了申请表之后唯一能做的就是等。等不到回复就焦虑焦虑就催问催问多了导师也烦。整套流程没有一个统一的进度概念——是提交了被拒了待确认还是已经被调剂每个环节都靠人肉同步就会产生大量无效沟通。第三个痛点是并发与资源争夺。热门导师名额可能只有5个但提交申请的学生有80个。先到先得还是按成绩排序如果同一瞬间五十个学生同时提交系统怎么保证只有前5个能成功这是技术问题也是规则问题处理不好就容易变成抢课系统一样的灾难现场。我做需求分析的时候没有直接去画用例图而是把教务老师、几位导师代表、几个学生叫到一起把上一年的流程从头到尾走了一遍把每个角色在每个时间点要做什么、能看到什么、能改什么一项项列出来。这一步特别重要——需求调研的输出不该是一堆功能列表而应该是一张面向时间的流程状态图。1.2 系统边界画到哪里三个角色四条核心流程这个项目的用户角色很清楚就是三类人学生查看导师信息、填报志愿通常可以填多个、查看确认结果、在允许时段内撤回或改志愿导师维护个人主页方向、名额、简介、查看学生志愿列表、逐条确认或拒绝、查看最终成组结果管理员/教务处创建双选批次、设置时间窗口、手动调整异常状态、导出最终名单。四条核心流程分别是批次启动流程管理员创建批次设置填报开始/结束时间、确认开始/结束时间批次内绑定参与导师和学生名单。学生填报流程学生在窗口期内提交志愿志愿按优先级排序。系统限制志愿数量比如每人最多填3个限制一个导师录满后不再接收新志愿。导师确认流程导师在确认窗口期内处理收到的志愿。关键规则是每个学生最终只能被一位导师确认一旦确认该学生在该批次中的其他志愿自动作废。结果与调剂流程确认窗口结束后系统生成双选结果。没有任何录取结果的学生进入调剂池由管理员手动分配或导师再次挑选。这条流程里最容易出问题的是第3条。很多第一次做这类系统的人会把它做成导师直接抢人也就是导师看到合适的学生就直接点录取。这个模式看起来效率高实际会引发一个问题热门导师第一时间把最好的学生全抢走冷门方向的导师没得选学生也不能表达自己的方向兴趣整个过程会变成纯比手速的游戏。我最终采用了先提交志愿、再导师确认的模式给双方都保留了选择空间。1.3 为什么说规则先行才能避免返工状态机是最重要的设计在写第一行代码之前我先画了一张完整的状态流转表。这个表是整个系统的地基数据库设计、接口设计、前端交互全都挂在它上面。志愿记录的状态字段我设计成五个枚举值状态含义允许的流向PENDING学生已提交导师未处理→ACCEPTED/REJECTED/WITHDRAWNACCEPTED导师已确认录取→WITHDRAWN仅限管理员取消REJECTED导师已拒绝→ 无不可重新激活WITHDRAWN学生撤回或被系统自动作废→ 无EXPIRED窗口结束仍未处理→ 由管理员批量处理这张表定下来之后我再去看需求发现很多问题瞬间变清晰了。比如学生填了3个志愿第一个被拒了第二个是PENDING第三个是ACCEPTED——那么系统应该怎么展示答案也变了展示的顺序应该以状态优先级ACCEPTED PENDING REJECTED来决定而不是以填报顺序。再比如导师确认了一个学生之后学生其他PENDING志愿要不要自动撤销我的答案是不自动撤销但展示给其他导师时标记为已被录取。如果你动态地去撤销会出现一个可怕的竞态两个导师同时对同一个学生点确认前一个刚提交完事务后一个发现学生已经被录走——如果按撤销逻辑走后一个操作会白白把学生的记录删掉。状态机定完数据库表结构基本就有了一半。这也是我最想强调的一点做流程类系统先定状态再谈接口这是避免后期反复改表的不二法门。2. 技术选型与数据建模Django、小程序、还有一张救命的志愿表2.1 为什么选Django而不是Flask或Spring Boot后端框架我直接选了Django没有犹豫。原因有三条每一条都跟这个项目的具体场景强相关。第一Django自带Admin后台。这个系统的管理端需求其实不复杂创建批次、看统计、调状态、导Excel。用Django Admin稍加定制就能满足80%的需求完全不需要再单独写一套Web管理界面。我做这个项目的时候管理员端只额外写了两三个视图函数其余全是靠Django Admin的list_display、list_filter、search_fields撑起来的前后只花了半天时间就配好了。省下来的时间全部投入到核心的学生端和导师端开发里性价比极高。第二ORM让多表关联的心智负担降到最低。导师信息、学生信息、志愿记录、批次、公告这些表之间关系并不复杂但数量多、关联多。用原生SQL写七八个联表查询或者用Spring Data写一堆Entity映射对我的项目节奏来说都偏重。Django ORM的select_related和prefetch_related用起来顺手还能直接写aggregate统计。实际开发中我统计每个导师收到多少志愿这种需求用一个annotate就搞定了。第三社区成熟度和部署经验丰富。Django的部署链路uWSGI/nginx/MySQL非常标准化出问题一搜就有答案。这一点在项目后期上线阶段帮了大忙。我不是说Flask不好而是双选系统这种偏业务管理、偏CRUD、后台需求重的项目Django的全家桶模式天然匹配。2.2 前端为什么不选H5而是微信小程序前端选择微信小程序理由也很直接。该校学生和导师都已经在微信生态里小程序不需要安装、扫码或搜索就能进比发一个网址让大家用手机浏览器打开还要面对各种浏览器兼容问题要顺滑得多。更关键的是微信小程序的登录体系比H5简单调用wx.login()拿code后端用code换openid天然就有了一个稳定、不会重复的学生标识不用自己再做一套手机号密码注册体系。当然小程序也有代价审核是个麻烦事类目如果选的不对被驳回很常见。我这里用的是个人/高校主体的小程序不涉及支付类目选教育-教育信息服务审核基本没遇到问题。另外小程序对前端开发者的JS功底有一定要求如果你完全不熟悉小程序语法前期会有学习成本但网上资料很多跟着官方文档走很快就能上手。还有一个很实际的考虑在校园场景里触达比工具重要。学生可能两三天才打开一次H5网站看有没有新消息但微信每天都会打开。系统内产生的确认通知通过订阅消息模板推送到微信效果远比站内信好。这也是微信小程序方案的独特价值。2.3 数据表设计五张核心表一张状态表承载整个业务下面是这个系统中几张核心表的架构我挑重点讲。用户表直接用Django自带的User扩展出一个Profile模型增加role字段student/teacher/admin。学生和导师各有一个Profile关联到同一个User实例登录入口统一。导师信息表字段包括姓名、职称、研究方向、个人简介、今年可带名额quota、剩余名额remaining、是否接受调剂、状态是否可被选。有一个很重要的字段叫is_active如果导师今年不带毕业设计这个字段置False学生端前端就不展示这位导师。学生信息表学号、姓名、专业、方向、联系电话、平均绩点用于导师参考、个人备注。志愿表核心表这是整个系统的心脏字段包括student_id外键、teacher_id外键、priority第几志愿、status状态枚举、created_at、updated_at、batch所属批次。我对这张表加了一个数据库唯一约束unique_together [(student_id, teacher_id, batch)]保证同一个学生在同一批次不能对同一个导师提交两次志愿。这个约束在并发场景下能挡住不少脏数据。批次表批次名称、填报开始时间、填报结束时间、确认开始时间、确认结束时间、状态未开始/填报中/确认中/已结束。所有的时间控制都挂在批次表上。五张表之外还有一个我当时特意加的字段在后期排障帮了大忙志愿表上额外记录了一次last_operated_by和last_operated_at。这个字段用来追踪这个状态是谁在什么时候改的方便出问题的时候回溯。虽然业务上不一定用得到但运营阶段有它真的省心。2.4 权限模型Django自带权限体系加一层角色判断Django自带的Group和Permission很适合做粗粒度的权限控制但实际开发中我发现双选系统的权限控制不需要太细重要的是角色区分数据范围隔离。我的做法是写一个简单的装饰器检查request.user.profile.role。学生端只能访问学生相关的API导师端只能访问导师相关的API。数据范围隔离靠查询时强制加上用户ID过滤比如导师查询志愿列表时视图函数里强制filter(teacher_idrequest.user.profile.teacher.id)而不是信任前端传过来的teacher_id参数。这个习惯帮我避免了很多权限越权问题。Admin后台则是把用户分成超级管理员和普通管理员普通管理员只能看不能改或者只能改自己批次的数据。我没有做特别复杂的行级权限Django Admin的has_change_permission重写一下就能满足需求。3. 核心接口与业务逻辑实现志愿填报、导师确认、时间窗口与消息触达3.1 学生端志愿填报接口事务与唯一约束并行学生端的核心接口是提交志愿列表。前端一次提交三个志愿按优先级排序后端用一个事务把整批志愿写入数据库。这里有个很重要的设计决策不能一条一条插必须一次事务提交一整批并且要保证要么全成功、要么全失败。我实际用的代码逻辑大概是这样的api_view([POST]) permission_classes([IsAuthenticated]) def submit_application(request): student request.user.profile.student batch get_current_batch() # 检查时间窗口 if not batch.application_open(): return Response({error: 不在填报时间内}, status400) # 检查是否已有志愿 if Application.objects.filter(studentstudent, batchbatch).exists(): return Response({error: 你已经提交过志愿请先撤回修改}, status400) data request.data.get(applications) # 预期是list of teacher_id # 检查志愿数量 if len(data) MAX_APPLICATIONS: return Response({error: 志愿数量超限}, status400) # 事务提交 with transaction.atomic(): for idx, teacher_id in enumerate(data): teacher Teacher.objects.select_for_update().get(pkteacher_id) if teacher.remaining 0: raise ValidationError(导师名额已满) Application.objects.create( studentstudent, teacher_idteacher_id, priorityidx 1, statusPENDING, batchbatch ) return Response({message: 提交成功})这段代码里有两个关键点。第一个是select_for_update()。这个东西在并发抢选的时候特别重要。它会对导师记录加行锁保证在事务提交前其他事务不能修改这条记录。如果没有这行两个学生同时提交同一个导师的志愿时两个事务都先SELECT remaining发现还有名额然后都UPDATE remaining-1最后remaining只减了一次名额却被占了两次——这就是经典的超卖问题。Django的ORM直接支持行锁用起来很顺手。第二个是检查是否已提交过的逻辑。这个检查不是绝对的因为事务隔离级别不同两个并发请求可能同时通过这个检查。但因为有唯一约束unique_together兜底即使并发穿透了检查也会在INSERT时报IntegrityError事务回滚不会产生脏数据。这里有一个值得注意的坑transaction.atomic()内如果抛出异常Django会自动回滚整个事务。但如果你用的是try ... except把异常吞掉了再返回一个错误响应要注意此时事务已经被标记为需要回滚后续的数据库操作会一直报TransactionManagementError。我最初写的时候没注意结果第二个请求进来直接报错。正确做法是在except里先调用transaction.atomic.__exit__或者直接让异常抛出去由中间件统一处理。3.2 导师端确认/拒绝逻辑不是一键录取而是审核式录取导师端处理志愿的交互我设计成列表逐条确认/拒绝而不是抢人式的一键录取。列表页展示所有向自己提交志愿的学生学生信息包括学号、姓名、专业、平均绩点、个人备注。导师逐条查看点击确认或拒绝。确认操作后该学生的状态变为ACCEPTED同时该学生在本批次的其他待处理志愿自动标记为WITHDRAWN由于状态机设计这里的标记不是删除而是状态字段更新。导师确认的接口我加了两个重要校验api_view([POST]) permission_classes([IsAuthenticated]) def confirm_application(request): application_id request.data.get(application_id) with transaction.atomic(): app Application.objects.select_for_update().get(pkapplication_id) teacher app.teacher # 校验导师配额是否已满 if teacher.remaining 0: return Response({error: 您的名额已用完}, status400) # 校验学生是否已被其他导师录取 if Application.objects.filter( studentapp.student, batchapp.batch, statusACCEPTED ).exclude(pkapp.pk).exists(): return Response({error: 该学生已被其他导师录取}, status400) # 更新状态 app.status ACCEPTED app.last_operated_by request.user.username app.last_operated_at timezone.now() app.save() teacher.remaining - 1 teacher.save() return Response({message: 已确认})这里就体现出状态机价值了冲突校验不是靠前端隐藏按钮而是靠数据库和事务兜底。两个导师同时点确认第二个会被已被其他导师录取挡住。因为select_for_update锁住了志愿记录第二个事务会等待第一个提交之后再执行这时候检查statusACCEPTED就会命中返回错误。remaining字段的更新我采用的是在确认时直接减一而不是实时重算统计结果。前者简单、实时、无并发压力后者要用Count聚合在大并发下会慢。实际运营中没有出现过不一致因为所有更新都在事务里select_for_update保证互斥。3.3 时间窗口控制定时任务与状态字段双重保障时间窗口是个容易被忽视但极其重要的模块。如果学生能在截止时间之后提交哪怕只晚了一秒都会引发投诉。我的方案是双重保障应用层校验定时任务兜底。应用层校验就是上述代码里写的在提交接口、确认接口里都检查批次当前状态。但光靠请求时检查还不够——如果学生卡在23:59:59提交请求到达服务器是00:00:00批次状态已经切换此时要保证拒绝。这个问题解决办法很直接请求进来时服务端获取的是服务器当前时间而不是前端传的时间。前端的时间是客户端时间不可靠一切以服务器时间为准。定时任务我用的是Django-Celery-Beat。跑两个任务一个在填报结束时把批次状态从填报中切到确认中并给所有未提交志愿的学生推送提醒另一个在确认结束时把批次置为已结束并批量把仍为PENDING的志愿置为EXPIRED同时把所有未成功匹配的学生标记为待调剂。定时任务的精确度不需要到毫秒级因为应用层校验已经把晚一秒的场景兜住了定时任务只是个修复兜底。这里有一个隐藏问题Celery在开发环境是可用可不用的但生产环境一定要配好. 如果服务器资源紧张也可以写一个简单的cron脚本去调管理命令效果一样。实际上我后期为了简化部署把两个定时任务直接从Celery拆出来改成了两个Django management command crontab反而更省心少维护一个redis。3.4 消息触达微信订阅消息的一次性授权难题微信小程序的订阅消息规则是这样的用户必须主动点一次允许发送订阅消息按钮你才能给他发一条模板消息。也就是说你不能在用户没有交互的情况下直接推送。这个规则对双选系统来说非常致命学生填报之后不一定会主动点允许订阅即便点了最多只能发一条。双选流程中学生可能要收到导师确认了你的申请你的志愿被拒绝了调剂结果出来了等多条消息。我的解法是把订阅行为和关键操作绑定。在学生提交志愿时弹窗请求订阅确认结果通知在导师确认时请求订阅有新志愿提醒。每条消息对应一次授权这样能保证授权数量与消息数量大致匹配。如果某个学生授权用完系统退化为站内信通知小程序里有一个消息中心模块存消息记录学生打开小程序就能看到实际效果可接受。这个模块最核心的经验是不要试图绕过微信的订阅消息限制。网上有一些滥用长期订阅消息的做法但这种灰色操作既不稳定也不合规。老老实实做一次性订阅站内信兜底是长期运营最稳妥的方案。4. 并发抢选与冲突处理热门导师被秒光的实测排障记录4.1 问题场景十秒内五十个志愿同时进来接口直接卡住这个系统第一年上线第一次并发高峰出现在填报开放日中午12点整。教务老师设置12:00开放填报我在后台监控面板上看着日志12:00:00到12:00:10十秒钟内收到了来自不同学生的50多个志愿提交请求。其中一个热门导师的名额是5个意味着同时有20多个人在抢这5个名额。刚开始的30秒一切正常但很快日志里就出现了超时和TimeoutError部分学生反馈提交转圈圈半天没反应还有好几个说明明显示名额已满但我提交成功后又弹出了错误提示。我立刻打开服务器看到数据库的Threads_running飙到了30多Innodb_row_lock_current_waits显示有大量行锁等待。这说明并发超过了数据库能承受的阈值请求在排队等待锁资源排队多了就把连接池挤满了。4.2 排查链路从接口响应时间到数据库锁等待的分析过程排查这类问题我习惯按三步走。第一步看接口响应时间的分布。用django-silk或者简单的日志中间件记录每个API的耗时。结果发现submit_application接口P99耗时达到了3.2秒而平时是80毫秒。这说明不是网络问题是服务端处理慢。第二步开MySQL慢查询日志。结果抓到了几十条UPDATE teacher SET remaining remaining - 1 WHERE id ...的语句每条耗时都在几百毫秒以上。问题很清楚了更新同一行record时锁等待导致耗时飙升。第三步故意用两个账号并发提交同一个导师的志愿登录服务器手动复现同时开启SHOW ENGINE INNODB STATUS确认是LOCK WAIT。到这里根因已经明确了并发提交时所有请求都在抢同一行导师记录的行锁导致串行化执行。更关键的是我的事务里除了更新导师记录还做了检查是否已提交过循环插入多志愿记录等操作整个事务时间越长锁持有的时间就越长数据库就越拥堵。4.3 方案落地乐观锁、唯一索引与异步队列的组合拳这个问题我最终不是靠一个方案解决的而是三个措施配合。第一把检查-更新变成原子操作。原来代码是SELECT remaining、IF remaining 0、然后UPDATE remaining-1三步操作在事务里串行。我把它改成了带条件的UPDATEupdated Teacher.objects.filter( pkteacher_id, remaining__gt0 ).update(remainingF(remaining) - 1) if updated 0: raise ValidationError(名额已满)UPDATE ... WHERE remaining 0是数据库原生的原子操作并发情况下只有remaining 0的行能被更新成功。更新返回0说明条件不满足名额已满直接报错。这比select_for_update更轻量因为它不需要先取锁再判断是一个原子操作。当然这只是针对扣名额这一步整个事务还是保留的。第二加唯一索引守住一个学生不能对一个导师重复提交。前面已经说了unique_together是最后一道防线。并发下即使业务逻辑没拦住数据库也会报IntegrityError拒绝写入。第三引入Redis做前置流量削峰。这个措施是后期优化的时候加的针对前几秒大量请求打进来的场景。具体做法是在接口入口处用redis的INCR记录每个导师ID在当前批次下的请求次数超过某个阈值比实际名额大一些比如名额外加10直接返回已达访问高峰请稍后再试把超过处理能力的请求挡在数据库之外。这只是一种体验优化真正抢到名额的判定仍然以数据库为准。实测结果改造后重新压测用JMeter模拟100个并发请求抢5个名额接口P99从3.2秒降到400毫秒事务成功率100%没有出现超卖或重复录取。之后正式开放也没有再出现卡顿。4.4 边界情况漏选、误选、反悔撤回还有最容易被忽略的静默失败并发问题解决之后还有一个意想不到的业务边界坑学生提交时选了3个志愿但导师确认阶段的耗时窗口长达48小时这段时间里可能导师已经确认了第一志愿而学生又提交了新的申请虽然理论上应该撤回后再提交。这里就涉及一个撤回操作的语义问题。我做的撤回功能比较简单学生在志愿状态全部为PENDING或REJECTED时可以撤回整份志愿重新提交。如果已有ACCEPTED状态不允许撤回。这个规则在需求阶段就和教务处确认过因为一旦导师已经确认反悔会造成流程混乱。撤回到提交之间有一个小时冷静期防止手滑误操作。另外还有一个容易被忽略的场景学生提交志愿时选了同一导师的两个名额比如把同一导师填了第1志愿和第2志愿。前端校验可以拦住但API层也要校验。我在事务里增加了一个检查如果data中有重复的teacher_id直接拒绝提交。这个错误在代码审查时发现后来写成了一个单元测试防止回归。静默失败是另一个大坑。有一次有学生反馈为什么我提交成功了但导师端看不到。查了半天发现是因为他提交时网络超时前端显示失败但后端事务实际已经提交了。学生以为是失败就又提交了一次结果第一次提交成功、第二次提交时被已有志愿挡回来才出现混乱。这个问题的根本原因在于接口超时和结果返回的不可靠性最终我用一个幂等键解决了前端每次进入填报页生成一个submit_token提交时带上这个token后端只处理一次。重复提交相同token的请求直接返回上次结果这样即使网络超时重复重试也不会产生重复数据。5. 小程序端联调与体验优化从能用到好用的关键细节5.1 登录态与Token刷新静默登录不能省小程序端的登录流程是wx.login()拿到code后端用code换openid再生成一个自己的token我用的Django REST framework的TokenAuthentication后来换成JWT。这个token的过期时间我设成7天小程序每次启动时调用静默登录接口刷新token有效期。这里有个组件级的小坑小程序冷启动时wx.login()必须在App.onLaunch里尽早调用否则页面请求会因token不存在而失败。我加了一个全局请求拦截器在请求头里带上token如果返回401就先重新走一遍登录流程再重试原请求。这个逻辑一定要在最底层处理好否则会出现用户眼看进来了却所有接口报错的诡异现象。导师端登录时我加了额外的一步角色路由。一个账号可能既是学生又是导师比如研究生助教兼任导师登录之后根据profile.role决定跳转哪个首页同时小程序端做一个切换身份的入口。实际使用中这个功能被几个老师表扬了因为很多系统默认一个账号只能是一种角色用户体验很僵硬。5.2 列表加载与缓存策略导师列表上千条也不卡导师列表是学生端首页的核心模块。几百位导师的信息一次性加载会很慢我采用的方案是分页加载本地缓存增量更新。分页采取20条一页下拉触底加载的方式后端用offset/limit或者Django REST framework的PageNumberPagination实现。前端拿到第一页数据后存到wx.setStorageSync做本地缓存。缓存更新的策略是每次进入首页先展示缓存数据同时后台发一个轻量请求如果后端返回的数据版本号比如批次表更新时递增的version字段跟缓存不一致就刷新整页否则沿用缓存。这个方法比每次进页面都重新拉数据体验好很多特别是在校园WiFi信号不稳、接口时快时慢的场景下缓存的价值非常明显。导师端查看学生志愿列表时我用了INFINITE滚动加载批次记录。每个批次下的志愿数量不定多的有几十条一页一页翻没问题。这里有一个体验细节志愿列表的每一项前端都要实时展示当前状态待确认/已确认/已拒绝状态变化要能反映到列表上不能让学生导师生等刷新。我的做法是在每次导师操作完确认/拒绝后本地更新一下对应项的UI文案同时保留一个下拉刷新按钮让用户手动拉取最新数据。5.3 状态同步轮询与下拉刷新的抉择双选过程中学生最关心的就是导师确认了没有。这属于典型的异步事件前端没有能力实时收到通知只能靠拉取。解决方案有两个方向轮询和WebSocket。我最终选择了轮询下拉刷新的组合没有上WebSocket。原因很实际第一这个系统的实时性要求并不高确认操作通常在导师点完按钮后几秒内发生学生晚几分钟看到完全可接受第二WebSocket需要额外的长连接成本小程序端的WebSocket在切后台时会被微信杀掉维护成本高第三轮询逻辑极其简单——学生在停留在志愿详情页时每隔30秒调一次接口查询状态离开页面时清掉定时器对数据库的压力在可控范围内。我甚至还在后端做了个小型轮询聚合接口一次返回该学生所有志愿的最新状态、剩余名额等关键字段避免前端为了刷新状态发起五六个子请求。这个优化让前端代码清爽很多也减少了对数据库的查询次数。5.4 表单校验与防重复提交前端不能只靠后端前端表单校验除了基本的必填、长度合法之外双选系统里最关键的校验是提交锁。学生点击提交志愿按钮后按钮立刻进入loading状态并禁用防止用户手抖连点两次导致重复请求。这只是第一步。更保险的是我在前端用一个全局变量保证同一时刻只能有一个提交请求在进行另一个用上述的submit_token幂等键兜底。这两个机制叠加前端线上的重复提交几乎绝迹。还有一个跟手滑相关的细节确认弹窗。导师点击确认之后会弹出一个二次确认框文案是确认后该学生将占用你的一个名额确认操作不可撤回。这个弹窗的文案是跟教务老师认真打磨过的目的是让导师在操作前充分意识到后果减少误操作。同理学生撤回志愿时也弹这个风格的警示框。6. 部署上线与运维避坑一台2核4G服务器扛住整个毕业季6.1 环境搭建没有用Docker直接裸机部署更省心对于这种小型校园系统我觉得Docker不是必需的。不是说Docker不好而是对于一个维护者可能只有一两个人的项目Docker会引入额外的排障成本。我最终采用的是最传统的裸机部署一台2核4G的云服务器装好Python 3.10、MySQL 8.0、nginx用venv管理依赖用uWSGI跑Django。整个部署脚本就几十行非常稳定。uWSGI配置的要点是processes4 threads2harakiri30表示每个请求最长30秒超时自动杀死防止个别慢请求卡死整个worker。nginx配置相对简单静态文件交给nginx直接服务动态请求走uwsgi_pass。HTTPS用的是免费证书这个在微信小程序里是必须的——小程序要求所有请求必须是HTTPS不能是明文HTTP。6.2 数据库备份与崩溃恢复一条命令保住整个毕业季数据是这个系统的命根子。双选进行到一半如果数据库崩了几百个学生的志愿数据全丢那是灾难性的。我的备份策略是每天凌晨3点用mysqldump全量备份保留最近7天的备份文件同时每次批次状态切换填报结束、确认结束前手动再备份一次。恢复演练我做过一次。当时是把备份文件在另一台机器上导入模拟恢复流程确认从备份到恢复完好的时间在20分钟以内。这个演练很有必要——第一年做的时候我连备份文件的恢复命令都得翻半天文档真出了事肯定手忙脚乱。后来我把恢复命令写成一个脚本放在服务器固定路径下并添加了README说明万一出问题任何人都能照着手册恢复。6.3 监控告警与日志别等到学生发截图了才发现系统挂了监控方面我没有用很重的监控平台而是做了三件事第一接口错误率告警。用一个简单的中间件统计每个API的错误率如果5分钟内错误率超过10%往自己的企业微信群机器人发一条告警。我用的是很原始的requests.post调群机器人Webhook配合一个定时任务检查统计表。这块逻辑一共也就五六十行代码但效果立竿见影——系统崩了5分钟我就知道了。第二数据库慢查询监控。MySQL的slow_query_log打开慢查询阈值设为1秒定期检查慢查询日志分析是否有索引缺失或全表扫描。生产环境实际跑下来偶尔出现几条超过1秒的查询基本都是批次结束时的批量状态更新任务我用索引和分批UPDATE解决了。第三业务日志。每个关键操作提交志愿、导师确认、批次切换都打一条结构化日志包含操作用户、操作时间、操作对象、结果状态。出问题时我直接grep相关日志就能还原整个操作链不需要翻数据库临时拼。这个习惯我一直保留后来帮本地教务处排查过几次学生说没收到通知但系统显示已发送的纠纷全靠日志还原了真实情况。6.4 上线前安全与合规检查几个容易被忽略的细节上线前做安全检查我梳理了几个常见但容易被忽略的点。接口鉴权。所有API都必须带有效的token不允许有一个无鉴权即可访问的调试接口。我在代码审查时专门搜索了api_view下面是否都挂了permission_classes防止漏写。后台入口保护。Django Admin路径我用了一个不常见的URL前缀比如/admin-panel-2023/避免被扫描器直接撞到。同时给Admin加了二次验证至少两步认证防止密码泄露后被暴力登录。隐私数据。学生的学号、手机号属于个人信息导师的私人联系方式也不能随意展示。我的策略是学生端列表只展示导师的研究方向和简介不展示私人手机号导师端看学生信息时学生手机号默认星号隐藏导师确认后才公开。这个小细节在需求评审时被特别强调因为涉及个人隐私保护和高校数据合规。接口限流。对登录接口和填报接口做了简单的IP/学号维度的限流防止恶意脚本刷接口。虽然校园系统面对的威胁不算大但养成这个习惯没有坏处。做完这个项目我最大的感受是像导师双选这种看似普通的业务系统真正考验人的不是某个技术难点而是对流程规则的理解程度和对边界情况的敏感度。状态机定清楚、并发兜底做扎实、消息触达保底线、后台运维留记录——这四件事做完了系统基本就不会出大乱子。如果你正准备动手做类似的毕设题目或校内工具我强烈建议你先花几天时间把业务方拉过来聊透把每一个状态、每一个例外场景都确认明白然后再上手写代码。技术选型反而是最容易的部分流程设计才是决定成败的胜负手。

Django+微信小程序实现导师双选：状态管理与并发控制实战

相关推荐

Java固定资产管理系统源码解析与二次开发实战指南

C++工厂模式详解：从简单工厂到抽象工厂的工程实践指南

Linux进程深度解析：从task_struct到僵尸进程排障

更多资讯

C#实现平面直角坐标与极坐标转换：从数学原理到工程实践

Python办公文档自动化：Word与Excel创建解析实战

【Cursor文档】Cursor中文官方文档教程：从VS Code迁移到AI代码库索引的完整配置指南（含TaoToken统一Key接入）

AI 领域联邦学习通信效率优化的创新之路：TaoToken 统一 Key 通道下的参数同步调优

当你用来做自动化测试编排的Openclaw崩了时，对走在AI赋能软件测试前排的你有什么启事？TaoToken统一Key通道的排查清单

Cocos2d-x 3.0源码精读：从Ref内存管理到Renderer渲染管线

今日更新

Cephadm实战指南：Linux系统工程师的生产级Ceph集群部署与排障

不想再被 Token 额度卡脖子？把免费 API 接入 WorkBuddy 的完整教程

ITK中SpatialObject几何体系解析：坐标系、变换与管道集成

本周精选

交通拥堵预测毕设：基于Python+LSTM的车辆流量预测系统全流程解析

MATLAB/Simulink搭建10机39节点电力系统暂态稳定仿真实战

无人机航拍三维重建全流程：从SfM到网格生成的避坑指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？