开启willReadFrequently: true可加速getImageData读取2–3倍，但会禁用GPU加速、使绘制变慢15%，适合滤镜/OCR等读多写少场景；核显友好，独显反降效。
集成显卡够用，独立显卡不自动生效——关键不在“有没有”，而在“浏览器是否真把任务交给了它”。
getContext("2d") 的 willReadFrequently 参数要不要开
这个 flag 会强制 Canvas 使用 CPU 可读的像素缓冲区，对集成显卡（如 Intel UHD Graphics 620）是友好选项；但对独立显卡（如 RTX 3060），开启后反而绕过 GPU 纹理管线，导致 getImageData() 变慢 2–3 倍。
- 高频读像素（如滤镜、OCR 预处理）→ 开
willReadFrequently: true，适合核显或内存带宽受限设备 - 高频写像素 + 少量读取（如游戏帧合成、粒子系统）→ 关闭该 flag，让
putImageData()走 GPU 纹理上传路径，独显优势才明显 - 验证方式：在 DevTools Console 执行
canvas.getContext('2d', {willReadFrequently: true}).getImageData(0,0,1,1)，对比关闭时的耗时
WebGL 上下文初始化失败时先查这三处
getContext("webgl") 返回 null，90% 不是显卡不行，而是通道被拦在系统层。
- Windows 图形设置里没给
chrome.exe指定“高性能 GPU” → 即使有 RTX 4090，浏览器进程仍被调度到核显 - 电源计划为“平衡” → GPU 动态降频，
webglcontextcreationerror事件频繁触发 -
chrome://flags中#enable-webgpu或#ignore-gpu-blocklist被误关 → 某些旧驱动版本会主动屏蔽 WebGL
CSS 合成层触发策略要按 GPU 能力分级
transform: translateZ(0) 和 will-change: transform 不是“开了就快”，而是“开了就占显存”。低端核显（如 HD Graphics 400）每开一个 will-change 就多占 8–12MB 显存，10 个元素就可能触发回退渲染。
立即学习“前端免费学习笔记（深入）”；
- 检测支持：用
CSS.supports('transform', 'translateZ(0)')判断基础能力 - 检测负载：在
chrome://gpu页面查看 “Compositing” 是否显示 “Hardware accelerated” - 安全做法：只对动画容器加
transform: translateZ(0)，禁用全局will-change，改用requestAnimationFrame+transform组合节流
真正卡住的从来不是显卡型号，而是把 will-change: transform 写在循环生成的 200 个 DOM 节点上，或者在低功耗模式下反复调用 getBoundingClientRect() 强制同步布局——这些行为在 RTX 4090 上一样卡。
