HTML/JS行为中，transform或opacity动画掉帧、Canvas 2D像素读取延迟、MediaSource视频解码卡顿、WebGL上下文创建失败等场景实际依赖硬件加速；需确认chrome://gpu中“Video Decode”为硬件加速且mediaCapabilities.decodingInfo返回supported与powerEfficient均为true。
绝大多数 HTML 函数运行本身不需要硬件加速——document.getElementById、addEventListener、JSON.parse 这类操作完全在 CPU 和内存中完成，开不开硬件加速毫无影响。真正需要它的是那些触发合成层、Canvas 2D 批量绘制、WebGL 上下文或 MediaSource 解码的场景。
哪些 HTML/JS 行为实际依赖硬件加速
硬件加速不是全局开关，而是按需启用的渲染路径。以下行为若卡顿或掉帧，大概率需要确认 GPU 通路是否打通：
-
transform或opacity动画在滚动中出现掉帧，且will-change: transform未生效 -
canvas.getContext('2d', { willReadFrequently: true })下像素读取延迟明显升高 -
new MediaSource()初始化成功，但sourceBuffer.appendBuffer后视频解码卡顿、CPU 占用飙升 -
getContext('webgl')返回null，或着色器编译失败、drawArrays调用耗时异常
Chrome/Edge 中必须检查的三项设置
仅开启「使用硬件加速模式」远远不够，这三个地方常被忽略，缺一不可：
- 地址栏输入
chrome://settings/system（或edge://settings/system），确认「使用硬件加速模式(如果可用)」已开启，并重启浏览器 - 地址栏输入
chrome://flags/#ignore-gpu-blacklist，设为Enabled；否则某些集成显卡会被 Chrome 主动屏蔽 GPU 解码能力 - 地址栏输入
chrome://flags/#disable-software-rasterizer，同样设为Enabled；否则即使有独显，文本和图层仍可能走 CPU 光栅化
Windows 下独显绑定不等于硬件加速生效
NVIDIA 控制面板里把 chrome.exe 设为「高性能处理器」，只解决了 GPU 调度问题；但浏览器内部仍可能因 MIME 类型不匹配或 MediaSource.isTypeSupported 校验失败而退回到软件解码：
立即学习“前端免费学习笔记（深入）”；
- 在 JS 中调用
MediaSource.isTypeSupported('video/mp4; codecs="avc1.640029"')，返回false就说明当前环境不支持该格式的硬件解码 - 确保
sourceBuffer.appendBuffer前没有对ArrayBuffer做Uint8Array逐字节修改——这种操作会破坏帧对齐，强制触发软件回退 - 验证是否真走 GPU：打开
chrome://gpu页面，搜索「Video Decode」，状态应为「Hardware accelerated」；再运行navigator.mediaCapabilities.decodingInfo(...)，确认supported和powerEfficient均为true
最容易被忽略的一点：硬件加速生效的前提是「浏览器进程被系统正确调度到 GPU」+「网页代码主动触发了可合成的渲染路径」+「媒体或图形 API 的参数恰好命中驱动支持的硬解格式」。三者缺一，都只是开着开关而已。
