倒计时应每次重算毫秒差而非硬减秒数，用Date.now()和带时区的ISO目标时间（如"2026-12-31T23:59:59+08:00"），requestAnimationFrame驱动更新，预存DOM引用，统一UTC运算再本地化显示。
直接用 setInterval + Date 对象就能跑起来，但多数人卡在时间计算不准、DOM 更新卡顿、目标时间时区错乱这三处。
倒计时核心逻辑：别硬减秒数，要重算差值
很多人写成「每秒减 1」，结果页面切后台再切回来就跳变或停走。真实场景中必须每次取当前时间，重新算和目标时间的毫秒差。
- 用
new Date().getTime()获取当前毫秒戳，不是new Date().getSeconds() - 目标时间必须是完整
Date实例，不能只传字符串（如"2026-12-31"），否则 Safari 和部分安卓 WebView 会解析失败 - 推荐写法：
const target = new Date("2026-12-31T23:59:59").getTime();—— 显式带时区（T和Z或时区偏移）避免本地时区误判
DOM 更新频率：用 requestAnimationFrame 替代 setInterval
setInterval(fn, 1000) 看似合理，但实际执行可能延迟、累积误差，尤其页面失焦后恢复时容易跳秒。浏览器节流下，setInterval 在后台标签页里可能被降频到 1 分钟一次。
- 改用
requestAnimationFrame驱动，配合时间差校准：每次帧开始时读当前时间，算剩余秒数，再决定是否更新 DOM - 示例关键片段：
function tick() {<br> const now = Date.now();<br> const remaining = Math.max(0, target - now);<br> if (remaining > 0) {<br> updateDisplay(remaining);<br> rafId = requestAnimationFrame(tick);<br> } else {<br> finish();<br> }<br>} - 这样既顺滑，又不会因系统调度偏差导致漏帧或重复渲染
HTML 结构绑定：避免反复 querySelector
每次更新都去查 document.querySelector(".days")，性能不差但冗余。更麻烦的是，若结构稍有变动（比如加了 wrapper 层），JS 就失效。
立即学习“前端免费学习笔记（深入）”；
- 初始化时一次性获取所有 DOM 引用，存为变量：
const $days = document.getElementById("days"); - 用
id比class更快、更稳；如果必须用 class，至少加唯一前缀，如countdown-days - 不要把时间单位塞进一个
div里靠空格分隔（如"00天00小时"），后期想加动画、换行、响应式就束手无策
时区与本地化：别依赖用户设备系统时间
你设的目标是「北京时间 2026-12-31 24:00」，但用户在纽约打开页面，new Date("2026-12-31") 默认按本地时区解析，结果差 13 小时。
- 统一用 UTC 时间戳做运算，显示时再转本地或固定时区：
new Date(targetTime).toLocaleString("zh-CN", {timeZone: "Asia/Shanghai"}) - 更稳妥的做法：后端返回带时区的目标时间（如 ISO 格式
"2026-12-31T16:00:00+08:00"），前端直接 parse，不拼字符串 - 注意：iOS Safari 对
toLocaleString的timeZone支持较晚，低于 iOS 14 可能忽略该参数，需 fallback 到手动偏移计算
真正难的不是写完倒计时，而是它在 Chrome/Firefox/Safari/微信内置浏览器里行为一致，且切后台再回来不丢秒、不跳变——这些细节堆起来，才是上线前最后一道坎。
