用textContent替代innerHTML可避免重排和XSS，用requestAnimationFrame替代setInterval可防跳秒卡顿，且应缓存Date实例减少GC压力。
用 textContent 替代 innerHTML 防止重排与 XSS
每次更新时间时若用 innerHTML，浏览器会重新解析字符串、重建 DOM 子树，哪怕内容只是纯数字，也会触发不必要的样式计算和布局重排。更关键的是，如果未来时间来源不可控（比如从 URL 参数或用户输入拼接），innerHTML 可能执行意外 HTML 标签，造成 XSS。
改用 textContent 是最直接的优化：它只设置文本节点，跳过 HTML 解析，性能更高，也天然免疫注入风险。
- ✅ 正确写法：
el.textContent = "11:21:45" - ❌ 避免写法：
el.innerHTML = "11:21:45"（除非你明确需要渲染 HTML） - ⚠️ 注意：如果元素内原本有子节点（如图标、span），
textContent会清空它们——确保目标元素是纯容器，比如<p id="clock"></p>
用 requestAnimationFrame 替代 setInterval 减少跳秒与卡顿
setInterval(update, 1000) 看似精准，但实际执行受 JS 主线程阻塞影响：如果某次更新耗时略长，或页面被切换到后台再切回，就容易出现“连跳两秒”或“卡住半秒后猛刷”。而 requestAnimationFrame 绑定浏览器刷新节奏，在页面可见且帧率稳定时更新更平滑。
核心逻辑是：不每帧都更新，而是只在秒数真正变化时才写入 DOM。
立即学习“前端免费学习笔记（深入）”；
- ✅ 推荐模式：用
Date.now()记录上一次更新时间戳，每次 rAF 回调中判断是否已过整秒 - ✅ 启动方式：
requestAnimationFrame(tick)，函数末尾递归调用自身 - ⚠️ 注意：必须监听
visibilitychange事件，在document.hidden === true时暂停 rAF 循环，否则后台标签页仍会持续请求帧，浪费 CPU
避免每毫秒都新建 Date 实例
很多人习惯在更新函数里反复写 new Date()，看似无害，实则每次都会创建新对象、触发内存分配。尤其在高频更新（比如 rAF 每秒 60 次）下，GC 压力明显上升。
实际只需要在秒级变化点获取一次精确时间，其余帧可复用或仅做差值计算。
- ✅ 更优做法：在秒数变更时调用
new Date()获取完整时间，其余 rAF 帧中用Math.floor((now - startTime) / 1000)推算当前秒数 - ✅ 或直接缓存
const now = new Date()，然后用now.getHours()等方法读取——比重复构造快得多 - ⚠️ 不要这样：
for (let i = 0; i （rAF 下每秒可能达此量级）
DOM 查询只做一次，别在循环里反复 getElementById
把 document.getElementById("clock") 写在定时器或 rAF 回调里，等于每秒执行 1～60 次 DOM 查找。虽然现代浏览器做了缓存，但仍是冗余开销。
初始化阶段查一次，存为变量，后续直接复用即可。
- ✅ 正确顺序：先
const clockEl = document.getElementById("clock")，再启动定时器或 rAF - ✅ 如果元素可能延迟加载（比如异步组件），可用
document.querySelector配合if (clockEl) {...}守卫，而不是每次无条件查找 - ⚠️ 特别注意：服务端渲染（SSR）或框架环境（如 React）中，DOM 可能尚未挂载，需确保脚本执行时机，比如监听
DOMContentLoaded或使用if (clockEl?.textContent !== undefined)判定可用性
真实项目里最容易被忽略的，其实是 visibilitychange + rAF 的组合：不加这个，标签页切到后台时 rAF 依然活跃，既耗电又干扰性能分析；而只加 clearInterval 却不用 rAF，则无法规避 setInterval 的固有抖动。这两者得配齐，才算真正落地。
