开学第一周的上午，几个年级被排在同一节课集中做心理普查。上千人几乎同时点开链接，测评页面开始转圈，有的加载不出题目，有的交卷卡住。老师在群里催，学生在教室里干等，这种时候临时加机器已经来不及。真正能救场的，是开学前就想好的降级方案。降级的核心思路只有一条：保住最要紧的动作，把不急的往后挪。
先把「作答」和「出报告」拆开
报告生成通常是最吃资源的一环，要算分、套常模、渲染排版。高峰期先把报告这一步停掉，只保证学生能打开题目、能交卷。作答和报告一解耦，系统的压力立刻小一大截，而学生这一侧几乎感觉不到差别，因为他们本来也不需要当场看到报告。
缓存题干，让作答不依赖实时接口
一次任务里的题目是固定的，没必要每次加载都回源去查。把题干和选项提前缓存到 CDN 或客户端，学生打开链接直接读缓存，哪怕后台计分服务在排队，题目照样显示、照样能答。作答数据先落到一个轻量的接收接口，别让它和沉重的计算挤在同一条路上；接收接口只做一件事——把答卷稳稳收下来、给一个「已提交」的确认。题干缓存要挂一个版本号，任务一改题就换号刷新，免得学生读到已经改掉的旧版题目。
延后报告，交卷即存、报告排队生成
学生交的卷先原样存下来，报告不当场出，改成放进任务队列慢慢跑，高峰过去再批量生成。对普查来说报告晚几个小时几乎没影响，但「交卷成功」这件事必须当场就给到明确回执。这里还要顺手管好提示文案：告诉学生「已提交、报告稍后生成」，避免他们以为没成功而反复点交卷，反而把接口又压垮一次。队列本身也要限住并发，按固定的处理速度慢慢消化，别让积压的计分任务一涌而上把数据库拖垮。橙星云在集中普查场景下支持把报告生成转成异步队列，高峰期只保交卷、错峰出报告，走的就是这个路子。
降级要能一键切回，还得事先演练
降级不是崩了才手忙脚乱翻配置。开学前就该把开关备好：关报告、开缓存、限流排队，最好一个动作切过去、高峰过了再切回来。限流也要配上友好的排队提示，而不是直接甩一个报错页。高峰这段还得盯住一两个关键指标——交卷成功率、接口错误率，一旦异常就知道要不要进一步限流，而不是等群里开始催才反应过来。没演练过的预案，真到那天照样乱——所以开学前最好挑个低峰时段，把这套开关整体切一遍试试。
开学周的集中普查，故障几乎是可以预料的。与其等页面转圈时现场救火，不如提前把降级这条路铺好——让最要紧的作答先活着，其余的往后排。