纯HTML+JS可部署新年倒计时页面的关键是“稳”：需手动指定东八区时间（如用带时区字符串或时间戳），避免时区偏移；用setInterval(1000ms)配合实时计算剩余秒数防累计误差；CSS禁缩放、选中与滚动条；JS独立于HTML并加版本号防缓存。
直接上手就能跑，不用框架、不依赖 CDN，纯 HTML + JS 就能做出一个可部署的新年倒计时页面。关键不是“怎么炫”，而是“怎么稳”——时间计算别偏移、时区别错乱、刷新不重置、移动端别缩放失真。
用 Date 算目标时间，但必须手动指定时区
浏览器的 new Date() 默认用本地时区，而新年是按东八区（UTC+8）算的。如果用户在洛杉矶打开页面，new Date('2025-01-01') 会按 PST 解析，导致倒计时提前或延后近 16 小时。
正确做法是写死 UTC 时间再转成本地显示：
const target = new Date('2025-01-01T00:00:00+08:00');或者更稳妥地用时间戳（避免字符串解析歧义）：
立即学习“前端免费学习笔记（深入）”；
const target = new Date(1735689600000); // 2025-01-01 00:00:00 CST 对应的时间戳
- 别用
new Date('2025/01/01')—— Safari 会报Invalid Date - 别用
setFullYear动态设年份 —— 如果页面跨年没刷新，倒计时会卡在去年 - 建议把目标时间写进 JS 变量里，而不是从 DOM 读取，避免 DOM 渲染延迟影响首次计算
setInterval 更新频率选 1000ms 还是 100ms？
倒计时本质是“每秒减 1”，但人眼对毫秒级跳动不敏感，且频繁触发 setInterval 会增加 CPU 占用，尤其在后台标签页中容易被节流。
实测下来，1000ms 是平衡点：
- 用
setInterval(fn, 1000)，每次执行前用Math.floor((target - now) / 1000)计算剩余秒数，避免累计误差 - 千万别用
setTimeout递归调用并动态算下次 delay —— 一旦 JS 主线程卡住，倒计时就跳秒甚至卡死 - 如果想加毫秒级动画（比如数字翻转），再单独起一个
requestAnimationFrame负责视觉过渡，和逻辑计时解耦
HTML 结构要防缩放、防选中、防滚动条干扰
新年倒计时常全屏展示，但默认 HTML 行为会破坏沉浸感：双击放大、长按选中文本、右侧出现滚动条、字体随系统缩放变模糊。
几行关键 CSS 就能锁死：
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no">
配合内联样式：
body { margin: 0; overflow: hidden; -webkit-user-select: none; user-select: none; }-
overflow: hidden必须加 —— 否则倒计时数字过长时（如“365 天”）会触发横向滚动条 -
-webkit-text-size-adjust: 100%防 iOS 自动放大文本 - 数字容器用
display: flex+font-size: clamp()比用 media query 更平滑适配不同屏幕
部署前必须检查时区与缓存问题
本地测试没问题，一上线就错 8 小时？大概率是服务器返回的 HTML 缓存了旧时间，或者 Nginx/Apache 把 .html 文件加了强缓存头。
- 把倒计时逻辑全部放在 JS 里，HTML 只留骨架 —— 避免服务端模板渲染时间硬编码
- 给 JS 文件加版本号或时间戳参数：
<script src="countdown.js?v=20241220"></script> - 检查响应头：
Cache-Control: no-cache或至少max-age=60，防止用户打开旧页面卡在去年倒计时 - 如果用 GitHub Pages 或 Vercel，确认没有启用“预渲染”—— 静态生成时跑的 JS 是构建机的时区，不是用户本地时间
真正麻烦的从来不是写代码，而是时间本身不认你写的逻辑 —— 它只认 UTC、只认设备时钟、只认 HTTP 头里那行 Cache-Control。
