倒计时应优先用 setTimeout 递归实现并锚定服务端时间，而非 setInterval；数字位需独立 DOM 节点+textContent 更新+等宽字体防抖动；结束逻辑必须由后端校验，前端仅作提示。
倒计时逻辑用 setInterval 还是 setTimeout？
直接用 setInterval 每秒刷新，看似简单，但实际容易漂移——比如页面切到后台、JS 被节流、或某次渲染卡顿，就会导致倒计时不准，甚至跳秒、漏秒。抢购场景对时间精度敏感，必须靠服务端时间锚定。
实操建议：
- 页面加载时，先通过 AJAX 或内联 JSON 获取服务端当前时间（如
/api/time返回{"server_time": 1717023456000}） - 再计算剩余毫秒数：
remaining = server_end_time - server_now + client_now_offset，其中client_now_offset是客户端与服务端的时间差（首次请求时可一并返回） - 后续只用
setTimeout递归驱动，每次设为remaining % 1000毫秒后触发下一轮，确保每次校准
HTML 结构怎么避免重绘抖动？
别把整个倒计时数字包在同一个 <span> 里用 innerText 全量更新，尤其是「00:00:00」这种格式——哪怕只变个位数，浏览器也可能重排整个行。
更稳的做法：
- 每个数字位单独一个
<span class="digit">，小时十位、小时个位、分钟十位……共 6 个 - 只更新变化的位，用
textContent赋值单个字符（不是 innerHTML） - 加
font-variant-numeric: tabular-numsCSS，保证数字等宽不跳动
倒计时结束时如何防用户手动改时间或 F5 刷新？
前端倒计时只是提示，不能作为业务开关。抢购资格、库存扣减、订单生成，全部必须由后端控制。
关键动作：
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 按钮点击时，前端仍需携带当前倒计时剩余值（仅作参考），但后端必须重新校验活动状态和库存，不可信任前端传来的任何时间戳
- 接口返回
{ "code": 400, "msg": "活动已结束" }时，前端才禁用按钮、清空倒计时、显示“已结束”文案 - 不要用
location.reload()或监听F5来“重置倒计时”，这毫无意义——服务端已关闸，刷多少次都无效
endTime 变量，就能绕过倒计时直接下单。移动端适配和性能要注意什么？
iOS Safari 对 setInterval 在后台标签页会强制降频到 10s 以上，安卓 Chrome 也有类似策略。这意味着你写的“每秒刷新”在切屏后可能变成“每 10 秒跳一次”。
解决办法：
- 监听
visibilitychange事件，页面隐藏时暂停定时器，显示时立刻重新计算剩余时间并更新 UI - 避免在倒计时回调里做 DOM 查询（如反复
document.querySelector），把所有digit元素提前缓存为变量 - CSS 动画（如闪烁、缩放）慎用，低端机上叠加倒计时重绘容易掉帧，优先用 transform + opacity 做轻量动效
立即学习“前端免费学习笔记（深入）”；
倒计时本身不难，难的是它暴露的所有边界问题：时间同步、DOM 更新节奏、前后端职责划分、移动端生命周期……这些地方随便漏一个，抢购页面上线后就可能被用户截图发群：“我这边还有 3 秒，点进去却说已结束”。
