倒计时应使用 setInterval 每秒更新 DOM，保存定时器 ID 以便 clearInterval 清理；用 Math.floor((targetTime - Date.now()) / 1000) 计算剩余秒数，避免时区误差；务必处理结束逻辑，防止负数或异常跳变。
用 setInterval 更新 DOM 是最直接的方式
倒计时本质是「定时更新页面上的一段文本」，不需要框架或复杂状态管理。核心就是启动一个定时器，每次执行时重新计算剩余时间，并写入 textContent 或 innerHTML。
常见错误是把倒计时逻辑写在事件回调里却没清空旧定时器，导致多个 setInterval 同时运行，数字跳变甚至负得飞快。
- 必须用变量保存
setInterval返回的 ID，后续可调用clearInterval停止 - 建议使用
Math.floor((targetTime - Date.now()) / 1000)算秒数，避免Date.getTime()和本地时区偏差带来的误差 - 每秒更新一次足够，别设成 100ms——既无必要，又可能因重排/重绘拖慢渲染
处理倒计时结束后的状态切换
很多实现只顾着“倒”，忘了“停”。一旦 remainingSeconds ，必须手动清除定时器并更新 UI，否则它会继续跑出 <code>-1、-2……甚至触发意料外的逻辑（比如重复提交按钮被误点）。
典型场景是活动页的“立即抢购”按钮：倒计时中禁用，结束后启用。这个开关动作不能依赖定时器“自然停止”，必须在每次回调里显式判断。
立即学习“前端免费学习笔记（深入）”；
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 判断条件优先用
remainingSeconds ，而不是 <code>=== 0，因为 JS 执行有延迟，可能直接跨过 0 - 清除定时器后立即将 DOM 设为终态，例如
btn.disabled = false、timerEl.textContent = '已结束' - 如果倒计时需支持“重启”，不要复用原定时器 ID，应先
clearInterval再新建
避免 Date 对象引发的时区与精度问题
用户本地时间 ≠ 服务端时间。直接用 new Date('2025-06-01') 构造目标时间，在夏令时切换日或跨时区设备上容易差 1 小时；而 Date.now() 本身精度只有 ~15ms，高频读取也不稳定。
真正可靠的做法是：服务端返回一个精确到毫秒的时间戳（如 1748764800000），前端直接用它做减法，完全绕过字符串解析和时区转换。
- 后端传时间尽量用 Unix timestamp（毫秒级整数），不要传 ISO 字符串
- 前端计算用
targetTimestamp - Date.now()，结果为毫秒，再换算成天/时/分/秒 - 如果必须用字符串，强制指定 UTC 时区：
new Date('2025-06-01T00:00:00.000Z')，末尾Z很关键
移动端 Safari 下 setInterval 被节流怎么办
iOS Safari 在标签页后台或低功耗模式下，会把 setInterval 的最小间隔拉长到 10 秒以上，导致倒计时“卡住”。这不是 bug，是浏览器主动省电策略。
解法不是硬扛，而是改用基于时间差的被动更新：定时器仍保留（比如每秒触发），但每次不依赖“上次+1秒”，而是实时算「当前离目标还剩多少」。
- 每次回调都重新调用
Date.now()，不累加、不缓存上一次值 - 哪怕定时器被推迟了 3 秒，下次一执行就立刻修正显示，用户感知不到跳帧
- 补充一个
visibilitychange监听，在页面切回前台时主动触发一次更新，弥补后台期间的缺失
倒计时看着简单，但真正在生产环境跑稳，关键不在“怎么动”，而在“怎么停”和“怎么对齐时间源”。尤其当倒计时关联支付、库存、抽奖等敏感操作时，服务端时间戳 + 每次重算 + 显式终止，这三步少一步都容易出岔子。
