必须锚定服务端时间戳初始化倒计时，用 ISO 8601 格式解析、校准客户端偏移；DOM 更新采用等宽单字符 span 精确控制；setInterval 设 500ms 间隔并防卡顿；按钮点击仍需后端二次校验时间与库存。
直接用 setInterval 每秒减 1 是最常见也最容易出错的做法——它完全依赖客户端本地时间，用户调快系统时钟，倒计时就“提前结束”；切到后台再切回来，可能跳秒甚至卡死。真正在意抢购公平性的项目，必须锚定服务端时间戳。
怎么初始化倒计时才不被用户篡改时间骗过？
别用 new Date() 直接解析后端传来的字符串（比如 "2026-08-04 10:00:00"），Safari 和旧版 Chrome 会返回 Invalid Date。
- 后端统一返回 ISO 8601 格式时间戳，例如：
{"end_time": "2026-08-04T10:00:00+08:00"} - 前端用
new Date(endTimeStr)安全解析 - 同时获取服务端当前时间，例如：
{"server_time": 1754294340000}，用于计算初始剩余毫秒数 - 别写
const now = new Date().getTime()—— 这是本地时间，不可信
倒计时 DOM 更新为什么总抖动、跳位、闪烁？
把整个 "00:00:00" 当字符串塞进 innerHTML，浏览器每次都要重排整行；数字宽度不一致（如 “1” vs “8”）还会导致左右晃动。
- 每个数字位单独一个
<span class="digit"></span>，共 6 个（时十位、时个位、分十位、分个位、秒十位、秒个位） - 只更新变化的位，用
textContent赋值单字符（不是innerHTML） - CSS 加上
font-variant-numeric: tabular-nums或font-family: monospace，强制等宽 - 避免用
display: inline-block+ 固定宽高模拟格子——补零逻辑没写好就会错位
用 setInterval 还是 requestAnimationFrame？
在抢购场景里，requestAnimationFrame 反而更危险：iOS Safari 在页面失焦或锁屏时会彻底暂停，用户回来发现已超时，但按钮还亮着。
立即学习“前端免费学习笔记（深入）”；
- 选
setInterval，间隔设为500ms（不是1000），视觉更顺，且便于做整秒判断 - 每次回调都重新算剩余毫秒：
remaining = serverEndTime - Date.now() + clientOffset，绝不累加或递减 - 监听
document.hidden，隐藏时clearInterval，显示时重新校准并启动 - 防卡顿：如果某次执行延迟 > 200ms，跳过本次 DOM 更新，避免连刷抖动
倒计时归零后，按钮为什么还能点？
前端禁用按钮只是体验层防护，用户删掉 disabled 属性或 curl 直发请求，照样能打进来。真正拦截发生在后端。
- 倒计时到 0 后，只把按钮文字改为“立即抢购”，仍保持可点击状态
- 点击时携带当前剩余毫秒数（仅作日志参考），但后端必须重新校验
server_time 和库存 - 接口返回
{"code": 400, "msg": "活动已结束"}才真正禁用按钮、清空倒计时、显示“已结束” - 别在倒计时函数里直接
location.href = '/pay'—— 后端可能还没开闸，得等接口响应确认状态
最难的部分从来不是写完倒计时，而是让「时间可信」和「行为可控」同时成立：服务端时间必须穿透 CDN 和浏览器差异，前端更新必须避开重排陷阱，而业务开关永远不能交给 JS 单方面决定。
