优先选 setInterval，简单可靠；requestAnimationFrame 适合动画帧同步场景，但秒杀倒计时对精度要求不高，且需兼容低版本 Android WebView 和微信内置浏览器——这些环境里 requestAnimationFrame 可能被降频或暂停（比如切到后台），导致倒计时跳秒、卡顿甚至停走。
倒计时用 setInterval 还是 requestAnimationFrame？
优先选 setInterval，简单可靠；requestAnimationFrame 适合动画帧同步场景，但秒杀倒计时对精度要求不高，且需兼容低版本 Android WebView 和微信内置浏览器——这些环境里 requestAnimationFrame 可能被降频或暂停（比如切到后台），导致倒计时跳秒、卡顿甚至停走。
实操建议：
-
setInterval的间隔设为1000毫秒，不要用500或更小值，避免频繁触发和时间漂移累积 - 每次执行前用
Date.now()对比服务端返回的截止时间戳，动态校正剩余秒数，不依赖 setInterval 累加计数 - 页面切后台再切回时，手动触发一次时间重算（监听
visibilitychange事件）
怎么防止用户改本地时间作弊？
纯前端倒计时无法防作弊，所有“剩余时间”必须以服务端下发的绝对时间戳（如 end_timestamp: 1717027200000）为唯一依据。前端只做格式化和渲染，不参与逻辑判断。
关键点：
立即学习“前端免费学习笔记（深入）”；
- 接口返回必须带服务端当前时间戳（
server_time）和活动结束时间戳（end_timestamp），两者差值即初始剩余毫秒数 - 前端初始化时立刻计算本地时间与
server_time的偏移量，后续所有时间比对都先修正这个偏移 - 按钮禁用、价格切换、库存状态变更等动作，必须以服务端返回的
status字段为准，不能仅靠前端倒计时归零就触发
clearInterval 忘了调用会怎样？
倒计时组件销毁（比如 Vue 组件 beforeUnmount、React useEffect 清理函数）时没调用 clearInterval，会导致定时器持续运行、闭包持有 DOM 引用、内存泄漏，严重时多个商品页同时打开会让页面卡顿。
安全写法：
- 声明定时器 ID 时统一用变量名
countdownTimer，不要用匿名setInterval - 在组件卸载/路由离开前明确调用
clearInterval(countdownTimer)，并置空变量（countdownTimer = null） - 倒计时归零后也要主动清理，避免“归零后还跑一两秒”的视觉 bug
秒杀开始瞬间高并发请求怎么不压垮接口？
前端不能在倒计时归零那一刻疯狂调用下单接口。真实场景中，90% 的失败来自重复提交和未限流的点击。
必须做的三件事：
- 倒计时结束前 1 秒就禁用按钮，并显示“即将开始”，避免最后一秒集中点击
- 按钮点击后立即置为 loading 状态、禁用，并用
AbortController控制请求生命周期，防止用户连点发多个请求 - 首次请求成功（无论成功/失败）后，3–5 秒内禁止再次点击，用本地
localStorage记录最后请求时间戳做兜底
服务端是否限流是另一回事，但前端这层防护漏掉，连第一波流量都扛不住。
