最稳妥的起点是 Date 对象配合 requestAnimationFrame 而非 setInterval，因其避免跳秒、主线程阻塞和标签页节流；应按实际秒数变化更新 DOM，用 toLocaleTimeString 自动适配本地格式，监听页面可见性以暂停更新，并始终与服务端时间对齐确保一致性。
直接用 Date 对象 + setInterval 是最稳妥的起点，但不处理时区、不防跳秒、不关定时器，页面一开就埋雷。
为什么 setInterval(update, 1000) 会跳秒或卡顿
浏览器主线程阻塞时，setInterval 的回调可能被延迟执行，导致连续两帧才更新一次，秒数“跳变”。更糟的是，如果用户切到其他标签页，部分浏览器会节流定时器，更新间隔拉长到 1 秒以上。
- 改用
requestAnimationFrame循环，在每次重绘前检查是否真到了下一秒再更新，视觉更稳 - 不要依赖“每 1000ms 执行一次”，而是每次取
new Date().getSeconds()，只在秒数变化时写 DOM - 避免在回调里做耗时操作（比如反复
querySelector或拼接大字符串）
toLocaleTimeString() 和手动拼接时间字段的区别
前者自动适配用户系统语言和习惯（如中文显示“下午3:25”，德语显示“15:25 Uhr”），后者完全可控但要自己补零、判 AM/PM、转星期名。
- 用
toLocaleTimeString('zh-CN', { hour12: false })能省掉小时进制转换逻辑 - 手动拼接适合需要固定格式（如
HH:mm:ss）或嵌入日志类场景，但getMonth()返回 0–11，getDay()返回 0–6，容易漏加 1 - 注意：
toLocaleString()在某些旧 Android WebView 中对hourCycle支持不全，建议降级兜底
如何让时间显示真正“动态”，又不浪费性能
核心是减少无效 DOM 写入。人眼根本看不出毫秒级变化，每秒更新一次就够了，但不必每 1000ms 都强制刷新。
立即学习“前端免费学习笔记（深入）”；
- 用
performance.now()或Date.now()做时间锚点，计算下次该更新的毫秒戳，比单纯setInterval更准 - 监听
document.visibilityState，页面不可见时暂停requestAnimationFrame或清除setInterval，防止后台跑空循环 - 把时间容器设为
textContent而非innerHTML，避免 HTML 解析开销和 XSS 风险 - 如果只是展示“最后更新时间”，用服务器注入时间戳 + 客户端相对计算（如 “2 分钟前”），比纯客户端时钟更可靠
最容易被忽略的一点：所有基于 Date 的时间都来自用户本地系统，时区、夏令时、手动改时间都会影响显示结果。需要强一致性的场景（如倒计时截止），必须和服务端时间对齐，不能只信 new Date()。
