uni-app倒计时应以服务端endTime为唯一可信源，用serverTime与Date.now()计算offset校准，每100–200ms更新DOM；关键钩子为onLoad（初始化）、onShow（防后台误差）、WebSocket心跳（微调offset）；多端统一用Date.now()+offset，禁用setInterval累减。
uni-app 里倒计时不准？别用 setInterval 简单减毫秒
真实秒杀场景下，setInterval 每 1000ms 减 1 秒必然漂移——手机锁屏、WebView 后台节流、JS 主线程阻塞都会让倒计时“跳秒”或“卡住”。淘宝系做法是：只把服务端下发的 endTime 当唯一可信源，本地只做「时间差映射」，不靠累加/递减维持状态。
- 服务端返回必须带
serverTime（当前服务器毫秒时间戳）和endTime（活动结束毫秒时间戳） - 客户端首次拿到后立刻计算偏移量：
offset = serverTime - Date.now()，后续所有时间都基于此校准 - 倒计时渲染用
Math.max(0, endTime - (Date.now() + offset))，每 100–200ms 更新一次 DOM，不依赖 setInterval 节奏 - 避免在
onShow里重置倒计时——页面切后台再回来时，Date.now()已滞后，但offset仍有效，直接继续算即可
uni-app 生命周期中哪几个钩子该更新倒计时？
不是所有生命周期都适合触发时间刷新。重点盯住三个节点：页面挂载、App 切前台、WebSocket 心跳响应。其他如 onLoad 或 onReady 只负责初始化，不负责持续更新。
-
onLoad：请求接口拿serverTime和endTime，计算并保存offset -
onShow：检查是否从后台切回，若距上次更新 > 500ms，立即重算一次倒计时值（防锁屏期间误差累积） - 如果用了 WebSocket 长连，可在每次收到心跳包时用包里带的服务器时间微调
offset（可选，提升精度到 ±100ms 内） - 千万别在
onHide里清除定时器再onShow重建——这会丢掉中间流逝的时间，导致倒计时“多出几秒”
uni-app 多端兼容时，Date.now() 和 performance.now() 怎么选？
performance.now() 在 H5 端精度高（微秒级），但在微信小程序、App 端不支持；而 Date.now() 全平台可用但只有毫秒精度，且受系统时间修改影响。实际方案是分层兜底。
- H5 端优先用
performance.now()做相对计时（比如动画帧间隔），但倒计时主逻辑仍用Date.now() + offset，因为最终对齐的是服务端绝对时间 - 小程序/App 端统一用
Date.now()，无需降级处理 - 不要尝试用
plus.navigator.getNetworkTime或第三方 NTP 库——uni-app 的plusAPI 仅限 5+ App，且网络时间同步有延迟和失败风险 - 真要保精度，服务端可每 30s 推一次新
serverTime，前端只做平滑过渡，不硬切
倒计时归零后还要防用户手动改系统时间
哪怕时间同步做得再准，用户把手机时间往回调 1 小时，Date.now() 就会暴跌，导致倒计时“复活”。这不是前端能彻底拦住的，但可以加一层业务兜底。
- 倒计时显示为 0 后，禁用所有交互按钮，并弹出提示：“活动已结束，请稍后再试”
- 点击按钮时不再查本地时间，而是直接发请求到服务端校验活动状态（
/api/seckill/status返回布尔值） - 服务端判断逻辑必须是：
currentTime >= endTime，而不是依赖客户端传来的“是否归零” - 如果发现本地
Date.now() + offset比上次记录小超过 10 秒，主动丢弃当前 offset，重新拉一次serverTime
时间同步的本质不是“让手机时间变准”，而是“让本地计算始终向服务端看齐”。偏移量只要不长期漂移，±300ms 内都是可接受的；真正致命的是逻辑错把客户端时间当权威，或者以为 setInterval 能精确控制节奏。
