html函数工具本身不直接调用gpu，真正触发gpu加速的是代码行为，如getcontext("webgl")、transform动画、willreadfrequently: true的canvas 2d；puppeteer/playwright需手动传参并绑定显卡才可用egpu；fabric.js/konva.js等库需显式开启webgl或合成层配置；webgpu依赖驱动、系统、浏览器三者协同且实验标志必须启用。
哪些HTML函数工具真会用到GPU加速
“HTML函数工具”本身不直接调用GPU——浏览器才是调度者。真正触发GPU加速的是你写的代码行为，比如调用 getContext("webgl")、大量使用 transform 动画、或启用 willReadFrequently: true 的 Canvas 2D 上下文。工具是否“支持好”，取决于它是否默认启用这些路径、是否封装了易出错的底层配置、以及是否暴露调试入口。
Puppeteer / Playwright 启动 Headless Chrome 时能否用上 eGPU
能，但必须手动传参，否则默认走软件光栅化。这两个工具本身不直连 GPU，但它们启动的 Chromium 实例可以继承宿主的 GPU 能力。关键在初始化参数和系统绑定是否到位：
-
executablePath必须指向你本地安装的 Chrome（而非系统自带的旧版），确保版本 ≥ 115（WebGPU 和 Metal 支持更稳） -
args中至少包含：--ignore-gpu-blocklist、--use-gl=metal（macOS）、--use-gl=angle（Windows）、--enable-gpu-rasterization - macOS 下需提前执行
sudo pmset -a gpuswitch 2，否则即使传参也常 fallback 到核显 - Windows 下仅靠 Puppeteer 参数不够，还必须在 NVIDIA 控制面板中为
chrome.exe单独指定高性能处理器
Canvas 2D 工具类库（如 fabric.js、konva.js）对 GPU 加速的实际依赖程度
这类库多数默认走 CPU 渲染路径，除非你主动开启硬件友好配置。它们不是“不支持”，而是把 GPU 加速开关藏在了实例化选项里：
-
fabric.Canvas初始化时加enableRetinaScaling: true+renderOnAddRemove: false可减少重绘压力，但不会自动触发合成层 -
konva.Stage需配合listening: false（静态图）+ 手动加style="transform: translateZ(0)"才可能提升为 GPU 图层 - 所有批量绘制操作（如
ctx.drawImage循环）若未加willReadFrequently: true，像素读取会强制同步回 CPU，GPU 流水线中断 - 真正吃 GPU 的是
filter应用（如 blur、brightness）和createPattern带纹理的绘制，但 fabric.js 默认禁用 WebGL 后端，需手动开启canvas.useWebGL = true
WebGPU 工具链（如 Tauri + wgpu、WebGPU Playground）目前的硬件适配瓶颈
WebGPU 是未来方向，但当前支持远不如 WebGL 成熟。它对 GPU 加速“支持好”的前提是：你的显卡驱动、操作系统、浏览器三者同时满足最低门槛：
- Chrome/Edge ≥ 125 且启用
chrome://flags/#enable-webgpu-developer-features；Safari 17.5+ 仅支持 Metal 后端，无 Vulkan - Windows 需启用 WDDM 3.0 驱动（NVIDIA 536+ / AMD Adrenalin 23.12+），旧驱动即使型号达标也会报
GPUDevice lost - macOS Ventura+ 且设备带 M1 或 AMD RX 6000 系列以上，Intel 核显全系不支持 WebGPU
- Tauri 应用若用 wgpu 后端，必须在
tauri.conf.json中设"webgpu": true，否则 runtime 默认禁用
最容易被忽略的是：WebGPU 的 requestAdapter 返回 null 并不等于显卡不行，大概率是没开实验标志，或系统未启用硬件加速——此时 chrome://gpu 页面里 “WebGPU” 项会显示 “Disabled” 而非 “Unavailable”。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
