浏览器无法稳定执行毫秒级setinterval，因最小间隔限制（≥4ms）和单线程任务堆积；应使用performance.now()配合requestanimationframe，在每帧计算当前应显示的时间值实现视觉连续。
为什么 setInterval 无法稳定刷新毫秒级时间
浏览器对 setInterval 的最小间隔有硬性限制（通常 ≥ 4ms），且 JS 是单线程的，任务队列堆积会导致实际回调延迟远超预期。直接写 setInterval(() => { update(); }, 1) 不会每毫秒执行一次，多数时候是 10–16ms 一跳，甚至卡顿后批量触发。
- 真实刷新频率取决于事件循环空闲程度，不是定时器设定值
-
Date.now()或performance.now()获取的是“采样时刻”，不是“渲染时刻” - 用
requestAnimationFrame也无法突破屏幕刷新率（通常 60Hz ≈ 16.7ms）
用 performance.now() + requestAnimationFrame 实现视觉上连续的毫秒变化
核心思路是：不追求每毫秒调用一次更新函数，而是在每一帧开始时，用高精度时间戳计算“当前应显示的时间值”，再格式化输出。这样既避开定时器抖动，又让数字变化看起来平滑。
let startTime = performance.now();
function render() {
const elapsed = performance.now() - startTime;
const ms = Math.floor(elapsed) % 1000;
const sec = Math.floor(elapsed / 1000) % 60;
const min = Math.floor(elapsed / 60000);
document.getElementById('timer').textContent =
`${min}:${sec.toString().padStart(2, '0')}:${ms.toString().padStart(3, '0')}`;
requestAnimationFrame(render);
}
render();
-
performance.now()返回浮点数（单位 ms），精度可达微秒级，比Date.now()更适合差值计算 - 必须在首帧记录
startTime，避免每次取绝对时间导致毫秒位跳跃（如跨秒时从 999 突变回 000） - 不要用
setTimeout递归模拟高频定时器——它会累积误差，且无法对齐帧节奏
需要真·毫秒级更新时，只能靠服务端时间戳或 WebAssembly 计时器
纯前端无法做到精确到毫秒的周期性触发，但某些场景（如倒计时同步、日志打点）需要可信毫秒源。这时得绕过 JS 事件循环：
- 从后端 API 拉取带毫秒的 ISO 时间（如
"2024-05-22T14:23:18.427Z"），用new Date().getTime()校准本地偏移，之后靠本地performance.now()推算 - 用 WebAssembly 编写一个忙等待计时器（不推荐：耗 CPU、阻塞主线程、浏览器可能强制降频）
- Web Workers 中用
setInterval+postMessage向主线程广播时间，能略缓解主线程压力，但依然受最小间隔限制
显示时的常见错觉和修复点
用户觉得“毫秒没动”，往往不是计时不准，而是渲染或格式问题：
- 用
Math.round()或Math.floor()处理performance.now()返回值——它本身是浮点数，直接取整可能因舍入导致跳变（如 123.999 → 123，下一帧 124.001 → 124，中间缺了 124） - DOM 更新太慢：把毫秒字段单独放在
<span id="ms"></span>里，只更新该节点，避免重排整个时间字符串 - CSS 动画/transition 干扰：给时间容器加
will-change: contents或禁用过渡效果，防止浏览器优化掉快速变化
真正难的不是“怎么拿到毫秒”，而是“怎么让毫秒变化在人眼看来是连续的”。这要求你放弃“每毫秒执行一次”的执念，转而信任 requestAnimationFrame 的帧节奏，并用高精度时间戳做插值。否则，越用力调 setInterval，越容易暴露浏览器底层的不稳定性。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
