Chrome DevTools Rendering面板可定位掉帧元凶：启用Paint flashing和FPS meter可识别重绘区域，Continuous page repainting配合Performance面板能区分script/layout/paint阶段瓶颈，需警惕同步layout、强制回流API及Canvas 2D离屏合成等隐性开销。
Chrome DevTools 的 Rendering 面板能直接暴露掉帧元凶
打开 Chrome，按 Ctrl+Shift+P（Win）或 Cmd+Shift+P（Mac），输入 Rendering，勾选 Paint flashing 和 FPS meter。真实掉帧时，屏幕右上角的 FPS 数字会跌破 60，同时频繁闪动的绿色矩形就是重绘区域——如果整个 canvas 每帧都在闪，说明不是局部更新问题，而是整帧重绘开销过大。
更关键的是开启 Continuous page repainting：它会强制每帧触发一次完整渲染流程，配合 Performance 面板录制，能清晰区分是 script（JS 执行）、layout（布局计算）还是 paint（绘制）阶段耗时超标。
常见误判点：
- requestAnimationFrame 回调里做了 DOM 插入或 class 切换 → 触发同步 layout，卡顿源不在 canvas 本身
- 使用了 getComputedStyle 或 offsetTop 等强制同步回流的 API → 即使只调用一次，也可能打断渲染流水线
- Canvas 2D 上用了 shadowBlur 或多次 globalAlpha 叠加 → 每次绘制都触发离屏合成，GPU 负担陡增
Canvas 2D 绘制性能差，优先检查 drawImage 的参数和图集使用方式
drawImage 是 HTML5 小游戏中最常被滥用的性能黑洞。传入 9 个参数的切片版本（drawImage(image, sx, sy, sw, sh, dx, dy, dw, dh)）比 5 参数版本（drawImage(image, dx, dy, dw, dh)）慢 3–5 倍，尤其当 sx/sy/sw/sh 不是整数时，浏览器需做子像素采样，CPU 解码压力激增。
实操建议：
- 所有精灵图（sprite sheet）切分坐标必须对齐整数像素，用 Math.floor 显式截断浮点坐标
- 同一帧内重复绘制同一张图（如粒子效果），先用 canvas.getContext('2d').createPattern 缓存为 pattern，再用 fillRect 复用
- 避免在每帧中动态创建 Image 或 Canvas 实例；预分配好双缓冲 canvas，用 ctx.drawImage(offscreenCanvas, ...) 替代逐元素重绘
requestAnimationFrame 时间戳不准？别信 event.timeStamp，用 performance.now()
requestAnimationFrame 回调传入的时间戳（rafTime）是相对页面加载的高精度毫秒值，但很多人误用 event.timeStamp（来自 mousemove 等事件）做 delta 计算，这会导致时间跳变甚至负值——因为 event.timeStamp 在某些浏览器中会受系统休眠、tab 切换影响而“倒流”。
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
立即学习“前端免费学习笔记（深入）”；
正确做法：
- 在首帧记录 let lastTime = performance.now()
- 每次 requestAnimationFrame 回调开头立即执行 const now = performance.now(); const delta = now - lastTime; lastTime = now;
- 不要依赖 Date.now()：它的精度通常只有 1–15ms，无法支撑 60fps 下 16.6ms 级别的帧间隔控制
- 若游戏逻辑需固定步长（如物理模拟），用累积 delta 做多次小步更新，而非直接乘以 delta —— 否则快设备上会“跳帧”
WebGL 渲染卡顿却没报错？大概率是纹理上传或着色器编译阻塞主线程
WebGL 看似“不卡”，但实际帧率波动大、触控响应延迟，往往是因为 gl.texImage2D 或 gl.compileShader 在首次调用时同步阻塞了 JS 主线程。DevTools 的 Performance 面板中能看到长达 20–200ms 的黄色 “Parse HTML” 或 “Function Call” 块，点开会发现堆栈停在 WebGL 相关调用上。
解决路径很明确：
- 所有纹理资源在游戏启动阶段预上传：用 gl.pixelStorei(gl.UNPACK_FLIP_Y_WEBGL, true) 配合 gl.texParameteri 设置好过滤模式，再调用 texImage2D
- 着色器代码提前编译：把 gl.compileShader + gl.getShaderParameter(..., gl.COMPILE_STATUS) 放在加载完 shader 字符串后立即执行，失败时立刻报错，不等到首帧渲染才触发
- 避免在 raf 回调里做 gl.bindTexture / gl.useProgram 频繁切换：合并绘制调用，用 texture array 或 atlas 减少 bind 次数
真正棘手的卡顿，往往藏在“看起来没问题”的地方：比如用 canvas.toDataURL() 截图调试、用 console.log 打印每帧状态、甚至只是开了 Vue/React 的 devtools。这些都会让原本 8ms 的绘制帧拖到 30ms 以上。性能优化不是加功能，是持续剔除干扰项。
