页面上看见一题，不代表服务端仍停在这一题

网络慢、重复点击或页面恢复，都可能让客户端持有旧题号。这里先把它视为待排查的故障模型：客户端请求中的questionNumber、Redis flow 当前题号和题目缓存内容必须一起看，单独刷新页面未必能解释问题。

服务端做了两次校验

InterviewAnswerPipeline先从 flow 得到当前题号和内容，并拒绝与请求题号不一致的答案，同时记录stale_question_reject_total。之后才申请按 session 和题号构造的 Redisson 锁。拿到锁后，代码重新读取 flow，再比一次题号并刷新题目内容。

第二次校验解决的是“锁前读到的状态，在等待锁期间已经变化”的竞态。它让题号检查与实际处理更接近同一个临界区。校验通过后才进入评分和推进流程。

前端的useInterviewSessionFlow根据响应更新当前题和进度；如果请求失败，会展示错误并保留重试入口。恢复页面时，前端状态只是显示材料，最终是否允许答题仍由服务端 session 和 flow 决定。

我会按这个顺序定位

先拿一条请求的 sessionId、requestId 和题号，再检查锁前 flow、锁后 flow、当前缓存题目以及响应错误码。若服务端拒绝旧题，应该让页面重新拉取当前题；若题号一致但内容为空，再查缓存重建路径。日志中不应输出完整用户答案，排查可用长度、摘要和关联 ID。

我的复盘

两次校验多了一次 Redis 读，但避免把过期题答案交给评分模型。并发边界处的额外检查比让模型替我们判断“这是不是当前题”可靠得多；代价是前端必须把服务端拒绝当成状态刷新信号，而不是盲目重复发送旧 payload。

源码入口

• admin/src/main/java/com/hewei/hzyjy/xunzhi/interview/flow/answer/InterviewAnswerPipeline.java
• admin/src/main/java/com/hewei/hzyjy/xunzhi/interview/flow/answer/InterviewQuestionLockService.java
• ../AI-Meeting-Frontend/src/hooks/interview/session/useInterviewSessionFlow.ts