实现精准时钟需避免setInterval精度缺陷，改用setTimeout校准整秒触发；优先调用toLocaleTimeString()处理时区与格式化；DOM更新用textContent并缓存元素引用，统一管理多时钟以保稳定。
直接用 setInterval 配合 new Date() 就能实现，但真正在页面上稳定跑起来，关键不在“能不能动”，而在“动得准不准、卡不卡、要不要考虑时区和格式化细节”。
为什么 setInterval 不能设成 1000ms 精确刷新？
浏览器的定时器不是原子钟——setInterval 只保证“至少间隔 1000ms”，实际执行可能被 JS 主线程阻塞、重绘调度或节流策略拖慢。尤其在后台标签页中，Chrome 会把间隔拉长到 1000ms 以上（甚至冻结），导致秒针跳变或停走。
- 别写
setInterval(updateClock, 1000)就完事，要用performance.now()或Date.now()校准下一次触发时间 - 更稳妥的做法是每秒检查一次当前时间，而不是依赖定时器节奏：每次更新后立刻计算下一个整秒时刻，再用
setTimeout精确对齐 - 如果只是显示“时分秒”，其实不需要每秒都重绘 DOM；只有秒数变化时才更新，能减少不必要的 layout
toLocaleTimeString() 比手动拼接 getHours() 更靠谱
手撕 date.getHours() + ':' + date.getMinutes()... 看似简单，但一碰到 24 小时制/12 小时制切换、AM/PM、夏令时、多语言环境就容易翻车。浏览器原生的 toLocaleTimeString() 能自动适配用户系统设置。
- 基础用法：
new Date().toLocaleTimeString('zh-CN', { hour12: false, hour: '2-digit', minute: '2-digit', second: '2-digit' }) - 想强制 UTC 时间？加
timeZone: 'UTC'参数，不用自己算偏移 - 注意：Safari 对
timeZoneName支持较弱，若需显示 “CST” 这类缩写，建议 fallback 到手动映射
DOM 更新太频繁会导致卡顿？用 textContent 替代 innerHTML
时间字符串不含 HTML 结构，用 innerHTML 不仅多余，还可能因转义问题意外破坏内容（比如时间里有 & 字符——虽然现实中不会出现，但原则不能破）。更重要的是，innerHTML 触发解析和重建子树，而 textContent 是纯文本替换，性能更稳。
立即学习“前端免费学习笔记（深入）”；
- 正确写法：
clockEl.textContent = timeStr - 避免反复查 DOM：
const clockEl = document.getElementById('clock')提前缓存，不要在定时器里每次都querySelector - 如果页面有多个时钟（比如本地+UTC+东京），用一个主定时器统一驱动，别给每个钟单独开
setInterval
真正难的不是让数字动起来，而是让它在各种设备、后台标签、低功耗模式、不同系统语言下都保持可读、不跳、不卡。校准逻辑、格式化策略、DOM 操作粒度，这三处不动手调，光贴一段“实时刷新代码”只是看起来热闹。
