必须用 setInterval 配合 new Date() 每秒更新 DOM 时间，避免 setTimeout 递归延迟；格式化须用 toLocaleTimeString() 并传参确保 24 小时制与双位秒数；需手动初调、监听 visibilitychange 暂停/重置，并通过服务端时间校准保证精度。
用 setInterval 配合 new Date() 实时更新页面时间
直接在页面里写死时间没用，必须靠 JavaScript 每秒刷新一次 DOM。核心就是用 setInterval 定期调用函数，函数里生成新时间字符串并写入元素。别用 setTimeout 递归——容易累积延迟，setInterval 更稳。
常见错误：把时间格式化逻辑写在定时器外，导致只初始化一次；或者用 document.write 覆盖整个页面（已淘汰，绝对不用）。
- 推荐把时间容器设为
<span id="clock"></span>，方便精准替换内容 - 用
toLocaleTimeString()自动适配本地格式，比手动拼接getHours()+getMinutes()更可靠（尤其处理 12/24 小时制、AM/PM、夏令时） - 启动定时器前先手动调用一次更新函数，避免页面加载后首秒空白
toLocaleTimeString() 的关键参数影响显示效果
默认行为依赖用户系统设置，但网页常需统一格式。比如中国用户可能看到 “上午10:26:30”，而产品要求是 “10:26:30” 或 “2026-08-26 10:26:30”。这时必须传配置对象：
new Date().toLocaleTimeString('zh-CN', {
hour12: false,
hour: '2-digit',
minute: '2-digit',
second: '2-digit'
})
注意：hour12: false 才能强制 24 小时制；漏掉 second: '2-digit' 可能返回单数字秒（如 “5” 而非 “05”），造成闪烁跳动；语言标签 'zh-CN' 影响 AM/PM 和分隔符，测试时务必切系统语言验证。
立即学习“前端免费学习笔记（深入）”；
避免 setInterval 内存泄漏和时钟漂移
页面长期开着，如果没清理定时器，切换标签页或关闭页面前未清除，会持续占用资源。更隐蔽的问题是：标签页休眠时，setInterval 可能被浏览器节流（比如降频到 1 分钟一次），再切回来就跳秒甚至错乱。
- 用
let timerId = setInterval(...)保存句柄，离开页面时调用clearInterval(timerId) - 监听
visibilitychange事件，在document.hidden === true时暂停，在false时重置时间（而不是继续计时） - 不要依赖 setInterval 的“精确 1000ms”，改用
performance.now()或服务器时间做校准（高精度场景才需要）
服务端时间同步不是前端能解决的
如果业务要求时间绝对准确（比如倒计时、金融操作），仅靠客户端 new Date() 不行——用户可以随意改系统时间。这时候必须从后端接口取时间戳，前端只负责格式化和插值动画。
典型做法：首次加载时请求 /api/time 获取服务器当前毫秒数，之后每 30 秒轮询一次修正偏差。但要注意，HTTP 请求本身有延迟，拿到的时间已是“过去时”，得结合 Date.now() 做简单补偿（例如减去平均 RTT）。
这个环节最容易被忽略：以为前端格式化好看就等于时间准确，其实只是“看起来准”。
