performance.now() 返回毫秒为单位的浮点数，精度达微秒级（1–10 微秒），但非整数微秒；其绝对值无业务意义，仅差值可用于精确耗时测量，且需注意 timeorigin 基准、后台降频及跨上下文一致性。
performance.now 返回的是毫秒还是微秒？
performance.now() 返回的是以毫秒为单位的浮点数，精度可达微秒级（通常 1–10 微秒），但它本身单位仍是毫秒。比如 1234.567890 表示 1234 毫秒 + 567.890 微秒，不是整数微秒值。
别被“微秒级精度”误导——你不能直接把它当微秒整数用，更不能乘以 1000 当作纳秒时间戳。
- 它基于高分辨率系统时钟，不受系统时间调整影响（如 NTP 校正）
- 起点是
performance.timeOrigin，不是 Unix epoch，所以不能直接和Date.now()对齐 - 在 iframe 或 Worker 中调用，
timeOrigin可能不同，跨上下文比对需谨慎
如何正确用 performance.now 做性能打点？
核心原则：只做差值，不单独使用绝对值。因为 performance.now() 的绝对值无业务意义，但两次调用的差值可精确反映耗时。
const start = performance.now();
doSomeHeavyWork();
const end = performance.now();
console.log(`耗时: ${end - start} ms`); // ✅ 推荐：只关心差值
- 避免写
Math.round(performance.now())—— 会丢失亚毫秒精度，实测常见误差达 0.1–0.3ms - 若需格式化输出，保留 3 位小数足够：
end.toFixed(3)，再多小数位无实际意义（受硬件/浏览器限制） - 不要在循环内高频调用
performance.now()做采样（如每帧都记），开销虽小但累积可观；改用performance.mark()+performance.measure()
为什么有时 performance.now 精度不如预期？
精度下降通常不是 API 问题，而是运行环境或调用方式导致：
- 页面处于后台标签页时，Chrome/Firefox 会降频定时器，
performance.now()仍返回高精度值，但你的逻辑可能被节流（如 requestIdleCallback、setTimeout 延迟增大） - 在 Web Worker 中调用没问题，但若主线程和 Worker 同时打点并直接相减，结果不可靠——二者
timeOrigin不同，需统一换算到同一基准（用performance.timeOrigin对齐） - 某些旧版 WebView（如 Android 4.4 KitKat）或 Electron 低版本中，
performance.now()退化为Date.now()级别精度（15ms 左右），可用performance.timeOrigin是否为有限数来检测
和 Date.now()、process.hrtime() 的关键区别
三者定位完全不同，混用会引入偏差：
-
Date.now()是 Unix 时间戳（毫秒整数），受系统时钟跳变影响，精度通常 ≤16ms，仅适合记录事件发生时刻，不适合耗时测量 -
process.hrtime()（Node.js）返回[seconds, nanoseconds]数组，真正纳秒级，但仅限服务端；前端不可用 -
performance.now()是唯一前端标准高精度计时方案，但必须配合timeOrigin使用才能映射到 wall-clock 时间（如需上报带时间戳的性能数据）
如果你需要把 performance.now() 转成近似 UTC 时间戳，得这样算：performance.timeOrigin + performance.now()，注意结果仍是毫秒浮点数，且 timeOrigin 本身也有约 ±1ms 的不确定性。
真正难的不是调用函数，而是理解 timeOrigin 的漂移、跨上下文一致性、以及浏览器对后台页面的调度干预——这些地方一疏忽，微秒级数据就变成误导性数字。
