直接用 Date + setInterval 易致卡顿、跳秒、时区错乱和首屏延迟；Date 实例是快照，需每次新建获取实时时间；setInterval 不精确，应改用 setTimeout 动态对齐毫秒级时间；须确保 DOM 就绪再操作元素。
直接用 Date 对象 + setInterval 就能跑起来，但真上线时容易卡顿、跳秒、时区错乱或首次渲染延迟——这些问题不靠实操踩一遍很难意识到。
为什么 new Date() 每次调用都得重新格式化？
因为 Date 实例是“快照”，不是活数据源。你不能只创建一次然后监听它变化；每次要显示新时间，必须新建实例或调用方法刷新值。
-
new Date()返回的是调用那一刻的时间戳，之后不会自动更新 - 直接写
document.getElementById('clock').textContent = new Date().toLocaleTimeString()是可行的，但可读性差、复用难 - 如果需要年月日+星期+12/24小时制切换，硬拼字符串极易出错（比如
getMonth()返回 0–11，漏加 1 就少一个月）
setInterval(updateTime, 1000) 为什么有时会跳秒？
浏览器定时器不精确，尤其在标签页非激活、系统休眠或高负载时，setInterval 可能被节流甚至暂停，导致连续两次回调间隔远大于 1000ms，视觉上就是“跳秒”或“卡住”。
- 别依赖
setInterval的“每秒一次”承诺，它只是最小间隔，不是保底精度 - 更稳的做法：每次执行时用
new Date()算当前真实时间，再计算下一次应触发的时间点，用setTimeout动态调度 - 示例逻辑：
function tick() { const now = new Date(); const nextSecond = new Date(now.getTime() + (1000 - now.getMilliseconds())); updateDisplay(now); setTimeout(tick, nextSecond - new Date()); }
toLocaleTimeString() 和手动拼接，哪个更适合生产环境？
优先用 toLocaleTimeString() 配合 Intl.DateTimeFormat，除非你明确需要固定格式（如日志时间戳）。
立即学习“前端免费学习笔记（深入）”；
-
toLocaleTimeString()自动适配用户本地时区和语言习惯（比如中文用户看到“上午10:23”，英文用户看到“10:23 AM”） - 手动拼接（
getHours()+padStart(2,'0')）绕过本地化，但可控性强，适合后台管理页等需统一格式的场景 - 注意：
toLocaleTimeString('zh-CN', { hour12: false })可强制 24 小时制，避免 AM/PM 切换带来的宽度抖动
最易被忽略的一点：页面加载完成前就执行 updateTime()，会导致 getElementById 找不到元素而报错 Cannot set property 'textContent' of null。务必确保 DOM 就绪，或者把脚本放在 </body> 前，或用 DOMContentLoaded 包一层。
