必须用服务端时间，因客户端时间可被篡改；后端应返回带时区的精确截止时间戳，前端用 new Date(serverTimestamp) 初始化倒计时，避免依赖本地时间或估算偏移。
倒计时依赖服务端时间还是客户端时间？
必须用服务端时间，否则用户手动改本地时间就能跳过限制。浏览器 Date 对象读的是用户本机时间，不可信。
实操建议：
- 后端接口返回一个精确的截止时间戳（如
expire_timestamp: 1741234567），单位为秒或毫秒，带时区信息（推荐 UTC） - 前端拿到后立刻用
new Date(serverTimestamp)初始化倒计时起点，别用new Date().getTime() + offset这类估算 - 如果只能走纯前端方案（比如静态页），至少每 30 秒用
fetch('/api/time')同步一次服务端当前时间，校准倒计时偏差
setInterval 更新倒计时但页面切后台就卡住？
浏览器对非活跃标签页会节流 setInterval，最低频率可能降到 1s 甚至更慢，导致倒计时不准、按钮状态延迟触发。
正确做法是用 requestAnimationFrame 或时间差动态计算：
立即学习“前端免费学习笔记（深入）”；
- 记录上一次渲染时间
lastTick，每次执行时用Date.now() - lastTick算出真实流逝毫秒数 - 避免写
setInterval(() => { sec-- }, 1000)—— 这只是“尝试每秒减 1”，实际执行间隔不可控 - 示例逻辑：
function tick() { const now = Date.now(); const remainMs = Math.max(0, expireTime - now); updateButton(remainMs); if (remainMs > 0) requestAnimationFrame(tick); }
优惠券领取按钮状态切换的边界条件
倒计时归零不等于能立即领券，得防并发和状态不同步。
关键点：
- 倒计时结束时，按钮文案变“立即领取”，但点击后仍要调用领券接口，且接口必须做幂等校验（比如用
user_id + coupon_id做唯一索引） - 不要仅靠前端禁用按钮来阻止重复点击，
disabled可被绕过；按钮点击后应立即设disabled=true并加 loading 状态 - 接口返回
{ code: 400, msg: "已过期" }时，要同步把按钮打回“已失效”，而非只提示错误 - 注意时区：服务端返回的
expire_timestamp是 UTC，前端显示时用toLocaleString('zh-CN', { timeZone: 'Asia/Shanghai' })转本地时间，但计算逻辑全程用毫秒数，不格式化
移动端 Safari 上倒计时跳秒不准？
iOS 15+ 的 Safari 对 requestAnimationFrame 在后台标签页有特殊行为，且部分低端安卓 WebView 会降频定时器。
稳妥方案：
- 用
performance.now()替代Date.now()获取更高精度时间差（尤其在动画帧内） - 增加兜底检测：每 5 秒比对一次服务端当前时间，若偏差 > 500ms，重新计算剩余时间
- 避免在倒计时组件里做重渲染（如每秒
setState({ sec })），改成只更新 DOM 文本节点，减少 layout thrashing
倒计时看着简单，真正难的是时间源可信、状态同步、边界容错——尤其是用户网络抖动、切后台、跨时区这些情况，光靠前端 setInterval 加个 disabled 就上线，大概率出问题。
