用setinterval每秒更新textcontent显示实时时间最稳妥，因其不依赖渲染帧率、后台仍能触发、逻辑直白；requestanimationframe则因后台暂停、刷新率依赖而不适合秒级更新。
用 setInterval 每秒更新 textContent 最直接
浏览器里显示带秒的实时时间，核心就是每 1000ms 触发一次时间获取和 DOM 更新。用 setInterval 是最稳妥的选择——它不依赖渲染帧率，也不受页面失焦时 requestAnimationFrame 暂停的影响。
常见错误是写成 setInterval(() => { new Date() }, 1000) 却没更新 DOM；或者用 setTimeout 递归但没处理好延迟累积（比如上一帧卡顿导致下一帧跳秒）。
- 把时间格式化逻辑放在定时器回调内，每次调用都重新生成字符串
- 用
textContent而非innerHTML更新，避免 HTML 解析开销和 XSS 风险 - 初始化时立即执行一次，避免首次显示空白或旧值
const clock = document.getElementById('clock');
function updateTime() {
const now = new Date();
const h = String(now.getHours()).padStart(2, '0');
const m = String(now.getMinutes()).padStart(2, '0');
const s = String(now.getSeconds()).padStart(2, '0');
clock.textContent = `${h}:${m}:${s}`;
}
updateTime(); // 立即显示
setInterval(updateTime, 1000);
为什么不用 requestAnimationFrame 做秒级刷新？
requestAnimationFrame 适合动画帧同步（如 canvas 动画），但不适合秒级时间显示。它的触发频率由屏幕刷新率决定（通常是 60fps），且在标签页后台、系统节电或高负载时会被主动降频甚至暂停——这意味着你可能连续几秒看不到秒数变化，甚至“卡住”。
而 setInterval 在页面后台仍能按设定间隔触发（Chrome 对后台 tab 的 setInterval 有最小 1000ms 限制，恰好符合需求），时间感知更可靠。
- 后台 tab 中
requestAnimationFrame可能完全停止，setInterval至少保证 1s 一 tick - 即使主线程阻塞，
setInterval的定时器仍在计时，恢复后会尽快补调（虽可能略延迟，但不会丢秒） - 不需要手动计算 delta 或做防抖，逻辑更直白
格式化时注意 getSeconds() 和系统时钟精度
浏览器中 new Date().getSeconds() 返回的是当前系统时间的秒数，它本身没有毫秒级误差，但 JS 执行和 DOM 渲染存在微小延迟（通常
- 不要用
Date.now() % 1000推算下一秒时间——这绕过系统时钟，易因执行延迟导致显示比真实时间慢 - 避免在格式化前缓存
new Date()实例并复用多个getXXX()方法——不同方法调用之间可能跨秒（尤其在 59→00 边界） - 如果需要毫秒级显示（如倒计时），才需用
getMilliseconds()并配合更细粒度定时（但要注意setInterval无法稳定达到 16ms 级别）
服务端时间不准时，前端怎么对齐？
纯前端用 new Date() 依赖用户本地系统时间。如果用户手机/电脑时间错了几分钟，显示再“准”也没意义。真要对齐标准时间，必须走网络校准：
- 首次加载时发一次
fetch('/api/time')拿服务器返回的 ISO 时间字符串，解析为Date，记录与本地时间的偏移量 - 后续每秒用「本地 new Date() + 偏移量」估算真实时间，避免频繁请求
- 偏移量建议每 5–10 分钟重拉一次，防止本地时钟漂移（如笔记本休眠后唤醒）
- 注意：HTTP 响应头里的
Date字段也可读取，但需处理时区和格式，不如 API 统一返回ISO 8601
这个逻辑一旦引入，就不再是“纯前端动态显示”，而是带状态的时间同步客户端——很多金融、投票类场景必须这么干，但普通页面通常没必要。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
