动态时间显示依赖 JavaScript 的 Date 对象获取本地时间并手动更新 DOM，必须配合定时机制；setInterval 简单但有精度误差，requestAnimationFrame 更平滑但需自行判断秒变并做后台校准；textContent 是安全高效的文本赋值方式。
动态时间依赖 JavaScript 的 Date 对象
HTML 本身没有“实时”能力，所有动态时间显示都靠 JavaScript 的 Date 对象获取客户端本地系统时间。它返回的是毫秒级时间戳，后续格式化（比如 toLocaleTimeString() 或手动拼接 getHours()、getMinutes()）全在 JS 层完成。
关键点在于：Date 只负责“取”，不负责“推”。你必须主动调用它，并把结果写进 DOM —— 这就是为什么所有方案都绕不开定时触发机制。
setInterval 是最直接但有精度风险的方案
setInterval(updateTime, 1000) 每秒调用一次函数，看起来合理，实际会累积误差：主线程卡顿时，回调可能延迟执行，导致跳秒或连跳。例如页面切到后台再切回，setInterval 可能批量触发多次，但视觉上只看到一次更新。
- 适合对精度要求不高的场景，如页眉小字时间
- 务必确保 DOM 元素已存在，否则
document.getElementById("clock")返回null，后续赋值报错Cannot set property 'textContent' of null - 别忘了初始调用一次
updateTime()，否则页面加载后空白一秒才出现时间
requestAnimationFrame 更平滑，但需手动判断秒变
requestAnimationFrame 绑定浏览器重绘节奏，每帧执行一次，频率通常为 60fps。但它不是“每秒一次”，所以不能直接替换 setInterval；必须自己记录上一次秒数，仅当 new Date().getSeconds() !== lastSecond 时才更新 DOM。
立即学习“前端免费学习笔记（深入）”；
这样既避免高频无意义操作，又规避了 setInterval 的调度漂移问题。不过要注意：
- 首次调用
requestAnimationFrame(loop)必须在 DOM 就绪后，否则可能找不到目标元素 - 如果用户长时间离开标签页，
requestAnimationFrame会被浏览器节流甚至暂停，回来时需做一次强制同步校准 - 不要在回调里做耗时操作（如复杂格式化 + 多个 DOM 查询），否则拖慢帧率
textContent 比 innerHTML 更安全且快
时间字符串不含 HTML 标签，用 element.textContent = timeStr 即可。相比 innerHTML，它跳过 HTML 解析流程，性能更好，也杜绝了意外注入风险（比如时间字符串里混入 <script> —— 虽然现实中几乎不可能，但原则要守住）。
常见错误是误写成 innerText：它受 CSS 样式影响（如 display: none 元素内容不计入），且在某些旧浏览器中行为不一致，textContent 是更稳妥的选择。
另外，如果时间容器是空的（比如 <p id="clock"></p>），直接赋值没问题；但若含初始文字（如 <p id="clock">加载中...</p>），用 textContent 会完整替换，无需额外清空逻辑。
