服务端必须用原子操作（如Redis SETNX或Lua脚本）按消息到达顺序唯一仲裁抢答者，禁用客户端时间与内存非原子判断；前端需立即禁用按钮并校验连接状态，题目与倒计时均由服务端主动推送驱动。

抢答时序锁定不能靠客户端点击时间或 Date.now() 判断，必须由服务端按消息到达顺序做原子仲裁——这是多人在线答题系统最常崩坏的环节。

服务端如何用原子操作锁定第一个抢答者

关键不是“谁先点”，而是“谁的请求最先被服务端不可分割地确认”。常见错误是：收到请求后先查状态、再写状态，中间可能被并发请求插队。

• 用 Redis 的 SETNX 命令（或 Lua 脚本）一次性完成「检查是否未锁定 + 设置抢答者 + 设置过期时间」，避免竞态
• 不依赖本地时间戳，改用服务端单调递增序列号（如 process.hrtime() 拼接自增ID），保证严格顺序
• 一旦 SETNX 成功，立即广播 { type: "locked", answerer: "userA" }；失败则返回 { type: "rejected", reason: "already locked" }
• 不要在内存 Map 里手工 if (!locked) { locked = true; ... } —— Node.js 单线程也不能保原子，多实例部署下更不可靠

前端按钮防连点与状态反馈怎么写才不翻车

用户快速双击、键盘回车+鼠标点击并行、React 中事件未及时禁用，都会导致多个 ws.send() 并发发出。服务端拒绝第二个不是兜底，而是必须前置防御。

WebSocket 8.18.2

WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。

下载

• 点击后立刻设 button.disabled = true，并加视觉置灰（比如 opacity: 0.6），别只靠 CSS :disabled 样式
• 发送前必查 ws.readyState === WebSocket.OPEN，否则提示“连接异常”，不静默重试
• UI 上显示弱提示：“已提交”（收到服务端 locked 或 rejected 后）、“等待确认…”（发送后到响应前）
• 不要用 setTimeout 模拟防抖——它解决不了网络延迟导致的重复发送，反而掩盖真实问题

题目同步为什么不能靠轮询或客户端分发

题目内容、倒计时、当前题号等状态若由某客户端广播或定时拉取，极易因丢包、延迟、重连导致各端不一致。必须服务端统一驱动。

• 新题下发必须走服务端主动推送，格式如 { type: "new_question", id: 123, content: "...", time_limit: 15 }
• 倒计时由服务端起始并广播初始值，前端仅做本地倒计时显示（用于 UI 流畅），但答题截止以服务端收到答案的时间为准
• 禁止前端自己维护 currentQuestionIndex++，所有题号推进由服务端消息触发，避免跳题/漏题
• 若使用房间机制（如 wss://host/ws?room=quiz-001），服务端需校验 session 是否属于该 room，防止跨房间污染

真正难的不是写通 WebSocket 连接，而是让所有客户端对「当前谁在抢」「现在答哪题」「谁算答对了」达成瞬时共识——这要求每条关键消息都带可排序 ID、每次状态变更都走原子存储、每个 UI 反馈都严格绑定服务端响应，缺一不可。