应将 new Date() 放入定时器回调内以获取实时时间，避免放在外层导致时间“卡住”；使用 toLocaleTimeString() 自动适配本地格式；确保 DOM 加载完成后再执行 JS，推荐脚本置于 </body> 前或用 DOMContentLoaded；setTimeout 递归对齐秒级起点比 setInterval 更精准。
直接用 JavaScript 更新 <span> 或 <div> 的 textContent，别用 document.write() 或内联 onload——它要么只执行一次，要么破坏页面结构。
为什么 new Date() 放在定时器外会“卡住”
常见错误是把 new Date() 写在 setInterval 外面，比如：
const now = new Date(); // ❌ 只执行一次，时间不会变
setInterval(() => {
document.getElementById('time').textContent = now.toLocaleTimeString();
}, 1000);这会导致显示的时间永远停在脚本加载那一刻。必须把 new Date() 放进定时器回调里，每次触发都重新取值。
- 每次更新都要调用
new Date()获取实时对象 - 用
toLocaleTimeString()比手动拼接getHours()/getMinutes()更省心，且自动适配本地格式（含 12/24 小时制、秒数、AM/PM） - 如果只要时分（不显秒），可用
toLocaleTimeString([], {hour: '2-digit', minute: '2-digit'})
如何避免首次渲染空白或闪动
DOM 元素还没加载完就执行 JS，getElementById 会返回 null，后续更新直接报错：Cannot set property 'textContent' of null。
立即学习“前端免费学习笔记（深入）”；
- 把脚本放在
</body>前，确保 HTML 已解析完成 - 或者用
DOMContentLoaded事件包裹初始化逻辑 - 更稳妥的做法：先写一个默认文本（如
<span id="time">--:--:--</span>），再由 JS 覆盖，避免白屏感
setInterval 的间隔设成 1000 还是 500？
设成 1000 是常规做法，但存在“跳秒”现象：比如 10:00:00.999 开始执行，到 10:00:01.998 才再次触发，中间有近 1 秒没更新。用户可能看到 10:00:00 → 10:00:02。
- 设为
500可缓解跳秒，但增加 CPU 开销（对普通页面影响极小） - 真正精准的方案是用
requestAnimationFrame+ 时间差计算，但对多数场景属于过度设计 - 更实用的折中：用
setTimeout递归代替setInterval，每次根据当前毫秒数对齐下一秒起点
例如：
function updateClock() {
const now = new Date();
document.getElementById('time').textContent = now.toLocaleTimeString();
const msUntilNextSecond = 1000 - now.getMilliseconds();
setTimeout(updateClock, msUntilNextSecond);
}
updateClock();注意：时区依赖浏览器本地设置，服务端时间需通过 API 获取并转换，前端无法绕过用户系统时钟。
