setInterval无法稳定显示毫秒，因浏览器最小调度间隔为4–16ms且受主线程阻塞影响；应使用performance.now()对齐初始Date，并通过requestAnimationFrame按帧更新时间，避免节流与丢帧。
为什么 setInterval 无法稳定显示毫秒
直接把 setInterval 的间隔设成 1 毫秒，页面不会每毫秒刷新一次——浏览器实际最小调度间隔通常在 4–16ms，且 JS 主线程繁忙时会严重丢帧。更关键的是，new Date().getMilliseconds() 返回的是“当前秒内的毫秒数”，但你无法靠它推算出“精确到毫秒的完整时间戳”，因为 Date 对象本身构造就有微小延迟（通常 0.1–2ms），连续调用两次取差值也不可靠。
performance.now() 是唯一靠谱的毫秒源
它返回的是相对于页面加载时刻的高精度时间（单位：毫秒，精度可达微秒级），不受系统时钟跳变影响，且不被浏览器节流。要显示“当前时间 + 毫秒”，必须把它和初始 Date 对齐：
- 页面加载时立刻记录
performance.now()和对应的new Date() - 后续每次更新，用初始
Date加上当前performance.now() - initTime得到高精度时间对象 - 再用
.getHours()、.getMilliseconds()等提取并格式化
示例代码片段：
const initTime = performance.now();
const initDate = new Date();
function updateClock() {
const now = new Date(initDate.getTime() + (performance.now() - initTime));
const h = String(now.getHours()).padStart(2, '0');
const m = String(now.getMinutes()).padStart(2, '0');
const s = String(now.getSeconds()).padStart(2, '0');
const ms = String(now.getMilliseconds()).padStart(3, '0');
document.getElementById('clock').textContent = `${h}:${m}:${s}.${ms}`;
}
requestAnimationFrame(updateClock); // 用 RAF 避免 setInterval 节流
用 requestAnimationFrame 替代 setInterval
setInterval(updateClock, 1) 不仅无效，还会在后台标签页被强制降频到 1s 甚至暂停，导致毫秒完全失准。而 requestAnimationFrame 在页面可见时按屏幕刷新率执行（通常 60fps），不可见时自动暂停，既省资源又保同步。
立即学习“前端免费学习笔记（深入）”；
- 不要在
requestAnimationFrame回调里无条件更新——需判断是否真过了 1ms 再渲染，否则只是空跑 - 实际毫秒更新频率受限于屏幕刷新率（如 60Hz ≈ 16.7ms 一帧），所以“每毫秒更新”本质是视觉错觉，真正有意义的是“每帧尽可能准确地算出当前毫秒值”
- 若需更高频逻辑（比如音频同步），得用
WebAssembly或AudioContext时间戳，纯 JS 无法突破主线程调度瓶颈
毫秒显示的视觉与实用性陷阱
人眼根本分辨不了 1ms 变化，强行显示三位毫秒数字只会造成高频闪烁，干扰阅读。更合理的做法是：
- 只在需要计时场景（如倒计时、性能监控面板）显示毫秒，且限制为 1–2 位（
.getMilliseconds() % 100） - 避免用
textContent频繁重写整个字符串——DOM 更新本身有开销，可只更新毫秒部分的<span>元素 - 注意时区：所有计算基于本地时区，若需 UTC 毫秒，请用
now.getUTCHours()等方法，别混用本地和 UTC API
真正难的不是“怎么显示毫秒”，而是理解毫秒在前端的意义：它不是为了炫技，而是服务于可测量的用户行为或系统反馈。一旦脱离这个前提，高精度反而成了 bug 温床。
