用requestAnimationFrame+performance.now()计算FPS：记录每帧时间差，每秒统计帧数并取整，避免单帧抖动；需监听visibilitychange确保页面隐藏时暂停统计。
直接在页面上显示实时 FPS 数值，用 requestAnimationFrame + performance.now() 就够了，不需要第三方库，也不必动用 WebGL 或 video API。
怎么用 requestAnimationFrame 算出当前 FPS
核心是记录两帧之间的时间差，再换算成每秒帧数。浏览器不提供“当前 FPS”变量，得自己算：
-
performance.now()返回高精度时间戳（毫秒，带小数），比Date.now()准得多 - 每次
requestAnimationFrame回调里计算与上一帧的时间差delta - FPS =
Math.round(1000 / delta)，但注意：单帧抖动大时这个值会剧烈跳变，不适合直接展示 - 更稳的做法是滑动窗口平均——比如每秒统计一次，用
frameCount累计该秒内执行了多少次 rAF
示例代码片段（可直接塞进 <script>）：
let lastTime = performance.now();
let frameCount = 0;
let fps = 0;
<p>function updateFPS() {
const now = performance.now();
frameCount++;</p><p>if (now - lastTime >= 1000) {
fps = frameCount;
frameCount = 0;
lastTime = now;
}
}</p><p>function render() {
updateFPS();
document.getElementById('fps').textContent = <code>FPS: ${fps}</code>;
requestAnimationFrame(render);
}
render();为什么不用 setInterval(fn, 16) 模拟 60FPS
它看起来简单，但实际会破坏帧同步，带来三类问题：
立即学习“前端免费学习笔记（深入）”；
- 定时器本身不和屏幕刷新对齐，容易导致画面撕裂或微抖
- JS 主线程卡顿时，
setInterval会积压回调，切回前台瞬间狂刷一堆帧，造成“突增—卡顿”循环 - 浏览器无法对其节流（比如标签页隐藏时仍照常触发），白耗 CPU 和电量
requestAnimationFrame 是浏览器原生调度的，自动适配刷新率、后台降频、设备节电策略，setInterval 在这方面完全不可控。
Canvas 动画里怎么避免 FPS 显示失真
如果你在 Canvas 渲染循环里同时做计算、绘制、更新 FPS，单帧耗时可能超过 16.67ms，导致 rAF 实际掉帧，而你显示的 FPS 却还是“60”——那是错觉。
- 确保
updateFPS()只做计时和计数，别在里面塞 drawImage、getImageData 这类重操作 - 如果 Canvas 逻辑本身已接近瓶颈，建议把 FPS 更新逻辑拆到独立的 rAF 循环里（哪怕只每 200ms 更新一次 DOM），和渲染解耦
- 低端设备上，
ctx.drawImage()或ctx.putImageData()调用开销大，可加帧率限制开关，例如用if (frameCount % 3 === 0)控制每 3 帧处理一次像素
页面不可见时要不要停掉 FPS 统计
要停。不是因为“省电”这种泛泛的理由，而是行为一致性问题：
-
document.visibilityState === 'hidden'时，rAF 会被浏览器暂停或大幅降频（如降到 1–2FPS），此时继续用performance.now()算出的“FPS”毫无意义 - 用户切回来瞬间，
lastTime可能是 30 秒前的值，1000 / delta直接算出 0 或 NaN - 正确做法是监听
visibilitychange事件，在隐藏时清空计数器、暂停 rAF；恢复时重置lastTime并重启循环
最容易被忽略的一点：FPS 显示本身是 UI 反馈，不是性能指标源。它只是帮助你判断“当前动画是否卡”，而不是替代 Performance 面板里的帧分析。真要定位卡顿，还得看 Chrome DevTools 的 “Performance” 录制结果，特别是主线程阻塞时长和 Raster 线程占用率。
