用 setInterval 更新页面时间最直接，核心是「读取当前时间 → 格式化 → 写入 DOM → 每秒重复」；需将 new Date() 放在回调内、用 textContent 安全更新、注意页面隐藏时的节流问题，并在框架中由生命周期管理定时器。
用 setInterval 更新页面时间最直接
页面上显示实时时间，核心是「读取当前时间 → 格式化 → 写入 DOM → 每秒重复」。不用框架、不依赖第三方库，setInterval 就是最贴切的工具。它比 setTimeout 循环调用更简洁，也比监听系统事件更可控。
常见错误是把 new Date() 放在定时器外，导致时间只取初始值；或忘记清除定时器，在单页应用中造成内存泄漏。
- 时间格式化建议用
toLocaleTimeString()，自动适配本地时区和格式（如 24 小时制/12 小时制） - 若需固定格式（如
"HH:MM:SS"），用date.getHours()等手动拼接，并补零（String(date.getSeconds()).padStart(2, '0')） - 定时器间隔设为
1000毫秒即可，不必更短——DOM 渲染和 JS 执行本身就有延迟，500ms 反而可能跳秒
innerHTML vs textContent：选哪个更新时间？
两者都能写入时间字符串，但语义和安全性不同。如果只是纯文本（比如一个 <div id="clock"></div>），优先用 textContent —— 它不解析 HTML，避免意外注入，性能也略好。
只有当你需要嵌入样式标签（例如加 <span class="second">12</span> 单独控制秒数颜色）才用 innerHTML，但必须确保内容完全可控，不能拼接用户输入。
立即学习“前端免费学习笔记（深入）”；
- 示例：
document.getElementById('clock').textContent = now.toLocaleTimeString(); - 避免：
element.innerHTML = '<b>' + timeStr + '</b>'—— 若timeStr来自不可信来源，有 XSS 风险 - 注意：频繁设置
textContent不会触发重排，但若父容器有 CSS 动画或 transition，仍可能间接影响帧率
页面隐藏时时间停止更新？这是正常行为
多数浏览器会在标签页非激活状态（切换到其他 tab 或最小化窗口）下节流 setInterval，将间隔拉长到 1s 甚至数秒。这不是 bug，而是省电与性能优化机制。
如果你的应用必须保持精确（比如倒计时、协作状态同步），不能依赖 setInterval 的“准时”，得改用时间差计算：
- 记录上一次更新的时间戳（
performance.now()或Date.now()） - 每次触发时，用当前时间减去上次时间，推算应显示的时间，再更新 DOM
- 这样即使定时器被节流，显示时间仍连续、不跳变
简单说：靠“等间隔执行”不如靠“算时间差”。尤其在后台恢复时，能立刻修正偏差。
Vue/React 项目里别手写 setInterval
在响应式框架中，手动管理定时器容易出问题：组件卸载了定时器还在跑；多次挂载重复创建；状态更新未走响应式流程导致视图不刷新。
应该交由框架生命周期接管：
- Vue 3 Composition API 中，
onMounted启动，onUnmounted清除clearInterval(id) - React 函数组件中，
useEffect返回清理函数，且依赖数组为空（[]），确保只初始化一次 - 避免在
render或setup函数体里直接调用setInterval—— 每次渲染都新建一个，旧的却没清，内存就涨上去了
真实项目里，时间显示往往还要考虑时区切换、国际化格式、暂停/恢复控制——这些逻辑一旦混进 setInterval 回调，很快就会变成难调试的面条代码。
