直接用 setInterval 配合 new Date() 可实现时间更新，但需手动处理时区、补零、校准和 DOM 更新频率：用 getHours()/getMinutes()/getSeconds() 拼接并 padStart 补零；设 250ms 刷新并 Math.floor(Date.now()/1000) 对齐整秒；改用 setTimeout 链式调用并动态计算 nextTick 避免累积误差；显示本地时间用 new Date()，固定时区用 timeZone 选项；DOM 更新用 textContent、只刷变动字段、避免耗时操作。
直接用 setInterval 配合 new Date() 更新 DOM 就行，不需要框架或第三方库——但必须手动处理时区、补零和 DOM 重绘频率，否则时间会跳、卡顿或显示错乱。
为什么 innerHTML = new Date().toLocaleTimeString() 会跳秒？
浏览器默认的 toLocaleTimeString() 返回字符串不含毫秒，且受系统区域设置影响（比如中文环境可能带“上午/下午”，英文环境可能用 12 小时制）。更关键的是：如果只在 setInterval 里每秒更新一次，但 JS 执行+DOM 渲染耗时波动，就可能出现视觉上的“跳帧”或“卡半秒”。
- 用
getHours()/getMinutes()/getSeconds()手动拼接，可控性强 - 补零必须显式写：
String(date.getSeconds()).padStart(2, '0')，不能依赖toLocaleTimeString('zh-CN', { hour12: false })的隐式行为 - 推荐设为
1000 / 4（即 250ms）刷新，再用Math.floor(Date.now() / 1000)对齐整秒，视觉更稳
如何避免 setInterval 累积误差导致时间偏移？
原生 setInterval(fn, 1000) 并不精确：JS 主线程忙时回调会被推迟，多次延迟后，显示时间和真实时间可能差几百毫秒。尤其页面切到后台再切回，setInterval 可能批量触发，造成“连跳几秒”。
- 改用
setTimeout链式调用，每次计算下一次目标时间戳：nextTick = Math.floor(Date.now() / 1000) * 1000 + 1000 - 每次执行前先校准：
const now = Date.now(); if (now >= nextTick) { update(); nextTick += 1000; } - 不要在定时器里做耗时操作（如遍历大数组、触发重排），否则必然拖慢
时区和本地化怎么处理才不翻车？
用户看到的时间，应该反映其设备本地时区，而不是服务器时间或 UTC。但 new Date() 默认就是本地时区，所以别手动加减小时数——除非你明确要固定显示某个时区（如北京时间 UTC+8）。
立即学习“前端免费学习笔记（深入）”；
- 显示本地时间：直接用
new Date()，所有getXXX()方法都返回本地值 - 强制显示北京时间：用
new Date().toLocaleTimeString('zh-CN', { timeZone: 'Asia/Shanghai' })，注意timeZone是标准 IANA 名，不是+0800 - 避免混用：
Date.now()是 UTC 毫秒数，但new Date().getHours()是本地值，二者别直接运算
DOM 更新太频繁导致页面卡顿怎么办？
哪怕只是改一个 <span> 的文本内容，如果每 100ms 刷一次，又没节流，在低端机或复杂页面里，layout 和 paint 会明显拖慢主线程。
- 只更新必要字段：秒变化时更新秒，分钟变时才更新分钟，不用每帧都全刷
- 用
textContent替代innerHTML，避免 HTML 解析开销 - 把时间容器设为
display: inline-block或加will-change: contents（慎用），减少重排范围 - 极端场景可降频：秒级精度够用就别刷 250ms，用 1000ms + 校准逻辑更省资源
真正难的不是让数字动起来，而是让每一次更新都落在该落的地方——时区对得上、毫秒不漂移、DOM 不抢主线程。这些细节不显眼，但用户盯着看三分钟，就会发现哪里不对劲。
