倒计时抢购必须以服务端endTime为唯一依据，前端需用serverTime校准本地时间偏移offset，再通过setTimeout递归计算剩余毫秒，禁用setInterval和自减逻辑，确保多商品独立倒计时且精准对齐服务端。
倒计时抢购功能必须以服务端 endTime 为唯一可信依据，前端不能靠 setInterval 累减、也不能用 this.remaining-- 维护状态——锁屏、切后台、低端机节流会让它彻底失准，用户看到“剩余 3s”时活动可能已结束 5 秒。
为什么不能用 setInterval 或自减逻辑
系统不保证定时器准时执行：iOS 后台冻结 JS、Android 省电模式下 setTimeout 延迟可达 2–5 秒、WebView 切页后恢复可能跳过多次回调。更危险的是，setInterval 不感知页面生命周期，onHide 时不清理会持续跑，onShow 时又叠加新定时器，导致按钮卡死或请求并发。
- 现象：用户切到微信聊天再回来，倒计时还显示“12s”，但接口返回“活动已结束”
- 根本原因：本地时间没对齐服务端，所有计算都基于漂移后的累减值
- 正确思路：每次渲染前都用
Date.now() + offset对齐服务端时间，再算剩余毫秒
如何用 serverTime 和 endTime 校准本地时间
后端必须返回两个字段：serverTime（当前服务器毫秒时间戳）和 endTime（活动截止毫秒时间戳）。前端只做一次偏移校准，后续全部复用。
- 校准时机：在 API 成功回调中立刻执行
offset = serverTime - Date.now() - 全局共享：所有商品倒计时共用同一份
offset，无需每个 item 单独算 - 计算剩余时间：
Math.max(0, props.endTime - (Date.now() + offset))，结果单位是毫秒 - 注意：服务端时间戳必须是毫秒级（如
1743165680000），秒级会丢失精度
怎么安全启动并持续更新倒计时（Vue3 setup）
用 setTimeout 递归替代 setInterval，节奏可控、无残留、易中断。刷新频率设为 200ms，兼顾视觉流畅与性能。
- 定义响应式变量：
const remaining = ref(0)、const isCounting = ref(false) - 写递归函数：
function tick() { const left = Math.max(0, props.endTime - (Date.now() + offset)); remaining.value = left; if (left > 0) setTimeout(tick, 200); } - 启动时机：在
onMounted和onShow中都调用tick()；onHide中不用清定时器——它本就不在运行 - 防重复点击：点击前先判断
if (isCounting.value) return，请求成功后再设isCounting.value = true并立即tick()
多商品列表里倒计时如何互不干扰
每个商品必须有独立的 remaining 和 isCounting，但时间校准仍用全局 offset。不能靠数组索引改值，也不能共用一个定时器 ID。
- 数据结构：每个订单对象上挂载响应式字段，例如
item.countdown = reactive({ remaining: 0, isCounting: false }) - 初始化：新订单加载后，对每一项调用
initCountdown(item)，内部仍走setTimeout + offset逻辑 - 结束处理：倒计时归零时，显式设
item.countdown.isCounting = false，并用orders.splice(index, 1)真实删除，而非仅v-if隐藏 - 容易被忽略的点：服务端需监控时钟误差，若
serverTime与真实 NTP 时间偏差超 500ms，应告警并暂停下发新活动
