setInterval(1000)跳秒因主线程阻塞导致回调延迟，两次getSeconds()返回相同值后突变+2；应改用requestAnimationFrame+performance.now()时间差推算，并监听visibilitychange确保准确恢复。
为什么setInterval(1000)显示的时间会跳秒或卡顿
因为 setInterval 只保证「平均间隔」，不保证「准时触发」。主线程忙（比如执行长任务、重排重绘）时，回调会被推迟，导致时间更新滞后甚至连续两次更新挤在同一次渲染里——你看到的“跳秒”，其实是两次 getSeconds() 返回了相同值，然后突然变成+2。
更麻烦的是：即使每秒调用一次，如果更新时机落在两帧中间，用户肉眼也能感知到闪烁或延迟。
- 避免用
setInterval(updateTime, 1000)直接驱动视觉更新 - 不要依赖
new Date().getSeconds()的变化来判断是否该刷新——它本身就不稳定 - 优先用时间差推算，而不是靠定时器“数秒”
requestAnimationFrame + 时间差推算才是真平滑
浏览器原生的 requestAnimationFrame 和屏幕刷新强绑定，每次回调都发生在帧开始前，天然适合做时间渲染。关键是：别让它每帧都写 DOM，而是只在「真实秒数变化时」才更新。
核心逻辑是记录上一次更新的时间戳，每次回调用 performance.now() 算差值，当差值 ≥ 1000ms 时再更新并重置基准。
立即学习“前端免费学习笔记（深入）”；
let lastUpdate = performance.now();
function clockTick() {
const now = performance.now();
if (now - lastUpdate >= 1000) {
document.getElementById('clock').textContent = new Date().toLocaleTimeString();
lastUpdate = now;
}
requestAnimationFrame(clockTick);
}
requestAnimationFrame(clockTick);
- 比
setInterval更省资源，页面后台时自动暂停 - 不会因 JS 阻塞丢帧，也不会出现“连跳两秒”
- 注意：必须用
performance.now()，不能用Date.now()——后者精度低且可能被系统时钟调整干扰
toLocaleTimeString() 的时区陷阱和格式失控风险
直接调 new Date().toLocaleTimeString() 看似省事，但输出完全取决于用户本地系统设置：有人开了 12 小时制、有人关了秒数、还有人系统语言是日语——你的“HH:mm:ss”可能变成“午後2時44分”。
若需统一格式或指定时区（比如展示服务器所在时区），必须显式传参：
new Date().toLocaleTimeString('zh-CN', {
hour12: false,
hour: '2-digit',
minute: '2-digit',
second: '2-digit',
timeZone: 'Asia/Shanghai'
});
- 不传
timeZone就是用户本地时区，不是服务器时间 - 不传
hour12: false，iOS Safari 默认用 12 小时制，且 AM/PM 位置不固定 - 避免用
innerHTML写入，改用textContent——防止格式字符串意外含 HTML 字符（比如某些 locale 的 AM 符号是<span>AM</span>）
隐藏标签页时要不要停？停了又怎么恢复？
用户切走标签页后，requestAnimationFrame 自动降频甚至暂停，这是好事；但 setInterval 不会——它照常跑，等用户切回来时一堆积压更新全涌出来，时间直接跳好几秒。
所以无论用哪种方案，都要监听 visibilitychange：
document.addEventListener('visibilitychange', () => {
if (document.hidden) {
// 暂停更新逻辑（如 cancelAnimationFrame 或 clearInterval）
} else {
// 恢复，并手动触发一次更新，避免醒来时显示旧时间
updateTime();
}
});
- 仅靠定时器自动恢复不行——用户切回来那刻，时间已经过了几秒，得立刻重读
new Date() - 别在 hidden 状态下还让
requestAnimationFrame循环空转，浪费 CPU - 移动端 WebView（如微信内嵌）对 visibilitychange 支持不一，建议加 fallback：每 30 秒强制同步一次
实际最难的不是“怎么让时间动起来”，而是“怎么让它动得准、不动歪、不瞎跳、不耗电”。所有优化都围绕一个事实：DOM 更新是昂贵的，而用户对时间跳变极其敏感。
