倒计时不准的关键在于以服务端时间为准：首次加载请求接口获取end_time或remaining_seconds，计算本地时间差值，每500ms重新计算剩余时间并校准，禁用setTimeout递归以防累积误差。
倒计时不准？用 setInterval 同步服务端时间才是关键
纯前端 setInterval 倒计时在页面切换、休眠或系统时间被修改时会漂移，竞拍场景下几秒误差就可能丢掉标的。必须以服务端返回的剩余秒数为基准，前端只做渲染和节奏控制。
实操建议：
- 首次加载时请求接口（如
/api/auction/123），返回字段含end_time（ISO 时间戳）或remaining_seconds - 前端用
new Date().getTime()对齐本地时间，计算初始差值，后续每秒用remaining = Math.max(0, serverEnd - Date.now() + offset)更新 - 避免用
setTimeout逐次递归倒计时——累积误差大；改用固定间隔（如 500ms）重新计算当前剩余，更稳 - 倒计时归零后立即禁用出价按钮，并触发一次最终状态拉取（防止网络延迟导致“最后一秒”仍可点）
出价失败常见报错：409 Conflict 和 422 Unprocessable Entity 怎么区分处理
这两个状态码背后逻辑完全不同，但前端常混为一谈，导致用户反复点“出价”却无反馈。
409 Conflict 表示并发冲突：你提交时，已有更高出价（或该标的已结束）。此时应直接刷新当前最高价和状态，而不是弹“出价失败”。
立即学习“前端免费学习笔记（深入）”；
422 Unprocessable Entity 是校验失败：比如出价低于当前价+加价幅度、非整数、超限、未登录等。需解析响应体中的 errors 字段，把具体原因（如 "bid must be at least 5000"）透出给用户。
实操建议：
- 提交前本地校验加价步长（从接口预取
min_increment），但不替代服务端校验 - 对
409，静默轮询最新状态（/api/auction/123/status），3 秒内最多查 2 次，再失败才提示“已被他人抢先” - 对
422，检查响应中是否有errors.bid或message，优先展示后者，避免暴露字段名
防重复点击：按钮置灰不是终点，要锁住整个出价流程
仅禁用按钮（disabled=true）不够——用户可能用 DevTools 改回可用，或快速双击触发两次 fetch。真正的防护在请求生命周期管理。
实操建议：
- 声明一个
isBidding状态变量，发起请求前设为true，无论成功失败都设回false（用finally） - 请求发出去后，若用户再次点击，直接
return，不发新请求 - 倒计时归零瞬间，除了禁用按钮，还要清除所有待处理的出价请求（用
AbortController） - 别依赖 CSS 类名判断是否可点——它和真实状态可能不同步；一切以 JS 状态为准
WebSocket 还是轮询？竞拍活跃期必须用 WebSocket 推送价格更新
每 2–3 秒轮询一次最新出价，在百人同时竞一个标的时，服务端压力陡增，且有延迟。WebSocket 能保证所有人看到的价格变化几乎实时（毫秒级），尤其适合“胶着战”场景。
实操建议：
- 连接建立后，先发一次
{"type":"sync","auction_id":123}获取当前快照，再监听bid_update事件 - 断线重连逻辑必须带退避（如 1s→2s→4s），并记录最后收到的
sequence_id，重连后请求补发缺失事件 - 若降级为轮询，间隔不能固定——根据最近 3 次响应时间动态调整，最低不小于 1.5 秒，避免雪崩
- WebSocket 仅推送变更，不传全量数据；前端用
last_bid_price和last_bidder做局部更新，别 reload 整个卡片
实际最难的不是倒计时或出价按钮，而是当多人同时操作时，前端如何信任自己看到的状态——它可能已经过期。所以所有交互动作都要带着乐观更新+服务端最终校验的思路，而不是等着 UI 跟上后端。
