想象你在一座城市里开了六家甜品分店，每家店的厨房设备都不一样：有的装了最新款烘焙机器人，有的还守着老式烤箱，有的甚至只能靠手动打蛋器出餐。你要推出一份由 AI 生成配方的爆款甜点，理想状态是每家分店都能端出一样的产品，但你不可能强迫每家店都立刻购买新设备。于是你开始做三件事：先翻出每间厨房的设备台账，再在开火前逐项检查设备是否真的能用，最后准备一套“老设备也能出餐”的备用流程。这就是 WebGPU 跨浏览器兼容性处理的本质。 WebGPU 就是那台新式烘焙机器人，它能让浏览器直接调用 GPU 做并行计算，成为在网页端运行 AI 模型的关键加速器。Chrome、Edge、Firefox、Safari 各自的“厨房”进度不同，移动端和桌面端差异更大。兼容性处理不是简单地写“支持/不支持”两个分支，而是用支持矩阵做规划、用特性探测做体检、用 WebGL2/CPU 做回退、用渐进增强保证体验，最后再通过性能调优和调试技巧把每一家分店的出品速度提上去。

岗位关联

对 AI 从业者的职业价值：WebGPU 是把 AI 推理从服务器搬到浏览器的重要通道，掌握兼容性处理，才能让模型产品在真实用户设备上大规模落地，而不是只活在 Demo 里。

目录
  1. 可视化演示
  2. 支持矩阵：先看厨房台账
  3. 特性探测：开动前先体检
  4. 降级回退：老烤箱也能出餐
  5. 渐进增强：先做基础款再加料
  6. 性能调优：控制出餐节奏
  7. 调试技巧：顺着烟雾找火源
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

展示WebGPU浏览器支持矩阵、渐进增强回退策略及WebGPU与WebGL性能基准对比。切换模式查看不同维度。

本节配有交互动效（进入视口后自动加载，约 3KB）。

支持矩阵：先看厨房台账

如果你是 AI 甜品中央厨房的负责人，第一件事绝不是马上烤蛋糕，而是让每家分店交一份厨房设备台账。这家有没有新式烘焙机器人？那家的插座电压够不够？隔壁的老烤箱还能不能用？把这些信息汇成一张表，你才知道哪些甜品能全城通卖，哪些只能在特定门店做限量款。

在 WebGPU 的世界里，这张“厨房台账”就是支持矩阵。Chrome 和 Edge 在主流桌面平台上已经默认开放 WebGPU，Firefox 的支持仍在推进中，Safari 则还在实验开关后面，移动端的支持又比桌面端慢半拍。更麻烦的是，同一款浏览器在不同操作系统、不同 GPU 驱动下的表现也不一样。所以支持矩阵不是一个简单的勾选框，而是“浏览器 × 操作系统 × GPU 硬件”的三维清单。

有了台账之后，我们还要把它量化。兼容性不是 0 或 1，而是“这份 AI 配方需要的 GPU 能力，当前环境能覆盖多少”。

台账不是做一次就结束。浏览器版本每两周更新一次，新 GPU 驱动也在不断出现，所以支持矩阵要持续维护。就像甜品店每月盘点设备一样，只有台账常更常新，兼容性方案才不会被突如其来的“新烤箱”打乱节奏。

可支持度=已确认可用特性数配方必需特性总数\displaystyle \text{可支持度} = \frac{\text{已确认可用特性数}}{\text{配方必需特性总数}}
这个公式把一个模糊的“能不能用”问题，变成了清晰的覆盖率数值。覆盖率越高，越可以放心启用 WebGPU 主流程；覆盖率不足，就要准备回退方案。
  1. 统计可用项把浏览器能力清单里确认可以使用的特性数量点出来。
    已确认可用特性数\textstyle \text{已确认可用特性数}
  2. 统计必需项把配方中必须要的特性总数点出来。
    配方必需特性总数\textstyle \text{配方必需特性总数}
  3. 做除法看覆盖度两者相除，越接近 1 说明这台“厨房”越够用。
    可用必需→1\textstyle \frac{\text{可用}}{\text{必需}} \to 1

特性探测：开动前先体检

有了台账还不够，因为台账是“上个月的记录”。真正开火之前，你还要亲自走进厨房，检查插座有没有电、烤箱门能不能关上、燃气接口是否漏气。这套动作，对应到 WebGPU 就是特性探测。

WebGPU 的入口是 navigator.gpu，但这只说明浏览器装了“新式烤箱”的说明书，并不代表烤箱真的能启动。你需要调用 navigator.gpu.requestAdapter() 去异步请求一个 GPU 适配器。适配器就像一个万能插座，它告诉你当前硬件到底支持哪些能力，以及最多能承受多大的并发负载。请求可能成功，也可能返回 null，比如浏览器跑在远程桌面环境，或者用户关闭了硬件加速。

所以，一段可靠的初始化代码绝不是“有入口就直接用”，而是一连串体检：入口存在吗？适配器请求到了吗？我需要的特性在 adapter.features 里吗？设备建立后，limits 够不够用？这些条件必须同时满足。

特性探测是异步的，因为 GPU 驱动和浏览器在背后可能要做大量协商。想象你问店长“烤箱能预热到几度”，店长要去配电房看一眼才能回答你。所以千万不要用同步思路去写 WebGPU 初始化，否则只会提前踩坑。

WebGPU 可用⟺入口存在∧适配器非空∧必需特性被支持\displaystyle \text{WebGPU 可用} \Longleftrightarrow \text{入口存在} \land \text{适配器非空} \land \text{必需特性被支持}
这个公式强调“缺一不可”。很多人只检查了入口就以为万事大吉，结果在用户机器上拿到 null，整个页面直接白屏。
  1. 入口存在navigator.gpu 这个“厨房门牌”必须存在，否则后面都不必谈。
    入口存在\textstyle \text{入口存在}
  2. 适配器非空requestAdapter() 返回的“插座”不能是 null。
    适配器≠∅\textstyle \text{适配器} \neq \varnothing
  3. 特性被支持配方需要的特性必须包含在适配器公布的能力清单里。
    必需特性集⊆适配器特性集\textstyle \text{必需特性集} \subseteq \text{适配器特性集}
  4. 同时成立三个条件用“与”连接，任何一个失败就回到回退分支。
    A∧B∧C\textstyle A \land B \land C

降级回退：老烤箱也能出餐

如果一家分店确实没有新式烘焙机器人，你会直接挂上“今日停售”的牌子吗？不会。你会转身打开那台老式烤箱，虽然它没有智能温控，但只要配方调整得当，依然能烤出像样的甜点。在浏览器里，这台老式烤箱就是 WebGL2。

WebGL2 是 WebGPU 之前浏览器主流的 3D 绘制接口，生态成熟、支持面广，能完成很多渲染类任务。如果连 WebGL2 都没有，你还能退到 CPU 后端，用 WebAssembly 或纯 JavaScript 跑计算。回退不是追求一模一样的效果，而是保证核心功能不缺席：实时抠图可以慢一点，但不能直接报错；AI 滤镜可以降分辨率，但不能让用户看到一片白屏。

降级回退还需要给用户一个明确信号。就像老烤箱烤出来的蛋糕可能口感不同，我们要在界面上提示“当前处于兼容模式”，避免用户误以为产品出了问题。

设计回退链时，最好把“当前后端”写成一个可枚举状态。这样日志、界面提示、埋点上报都能共用同一套语言，而不是在十几个 if 分支里各说各话。

渲染后端={WebGPU,若适配器可用WebGL2,若支持 WebGL2CPU,否则\displaystyle \text{渲染后端} =\begin{cases}\mathsf{WebGPU}, & \text{若适配器可用} \\\mathsf{WebGL2}, & \text{若支持 WebGL2} \\\mathsf{CPU}, & \text{否则}\end{cases}
这是一条非常直观的优先级链：能用新烤箱就用新烤箱，不行就开老烤箱，再不行就手工作坊，总之要让顾客有东西可吃。
  1. WebGPU 优先新烤箱体验最好，性能上限最高。
    WebGPU,若适配器可用\textstyle \mathsf{WebGPU}, \text{若适配器可用}
  2. WebGL2 次选老烤箱覆盖面广，适合做渲染型任务回退。
    WebGL2,若支持 WebGL2\textstyle \mathsf{WebGL2}, \text{若支持 WebGL2}
  3. CPU 兜底再没有 GPU 能力，也要用 CPU 保住核心功能。
    CPU,否则\textstyle \mathsf{CPU}, \text{否则}

渐进增强：先做基础款再加料

和“降级回退”相反，渐进增强的思路不是“从最好的开始慢慢砍”，而是“先给所有人一碗基础款，再根据厨房能力往上加料”。基础款是普通糖水，人人能喝；有余力的厨房再挤上奶油、撒上坚果、加一球冰淇淋。这个顺序能保证最差环境下的用户体验是完整的，而不是残缺的。

在 AI 应用里，基础层可以是 CPU 上的简化模型或 WebGL2 渲染管线，负责完成核心推断；增强层则是 WebGPU 独有的高并发计算，用来做超分辨率、实时特效、大模型加速等锦上添花的功能。只有那些通过特性探测的环境，才会被分发到增强层。

渐进增强还可以延伸到发布策略上。即使目标用户都支持 WebGPU，也不要一次性全量放开。先让 5% 的用户试跑，观察崩溃率和帧耗时，再逐步扩大到 20%、50%、100%。这就是灰度发布。用户教育也很重要：当用户因为浏览器太老只能使用基础款时，要告诉他“升级浏览器可以解锁更丝滑的 AI 体验”，而不是让他以为产品就这么简陋。

渐进增强听起来比降级回退更“温柔”，但它对架构的要求更高。你需要把渲染、计算、模型推理都抽象成可替换的后端模块，而不是在业务代码里堆满环境判断。

体验等级=基础层+增强层×I(WebGPU 可用)\displaystyle \text{体验等级} = \text{基础层} + \text{增强层} \times \mathrm{I}(\text{WebGPU 可用})
这里的 I 是指示函数：WebGPU 可用时等于 1，不可用等于 0。体验等级永远至少等于基础层，绝不会因缺少新设备而归零。
  1. 基础层所有用户都能获得的核心功能，是体验的下限。
    基础层\textstyle \text{基础层}
  2. 增强层只有在 WebGPU 可用时才叠加的高级能力。
    增强层\textstyle \text{增强层}
  3. 指示函数条件成立为 1，不成立为 0。
    I(WebGPU 可用)∈{0,1}\textstyle \mathrm{I}(\text{WebGPU 可用}) \in \{0, 1\}
  4. 相加得到最终体验没有增强也不会破坏基础体验。
    基础层+增强层×0=基础层\textstyle \text{基础层} + \text{增强层} \times 0 = \text{基础层}

性能调优：控制出餐节奏

兼容性解决了“能不能跑”的问题，接下来要解决“跑得爽不爽”。假设你的 AI 甜品大受欢迎，每家分店门口都排起长队，这时候厨房里最大的敌人就是节奏混乱：有人洗杯子，有人切水果，还有人堵在烤箱前等出炉，整个出餐流程就卡住了。

WebGPU 性能调优管的就是这件事。先给自己定一个帧预算：60 帧每秒意味着每帧只有约 16.7 毫秒，所有 GPU 工作都要在这个时间里完成。然后是资源复用：创建渲染管线、绑定组、缓冲区都很昂贵，不能每帧都重新做一遍，要像反复使用的模具一样提前备好。再就是减少上传和回读：把数据从 CPU 搬到 GPU，或者把结果从 GPU 读回 CPU，都像把食材从仓库搬到厨房，路径越短越好。

还要学会批量提交。与其一会儿提交一个渲染命令，不如把所有订单集中在一次 device.queue.submit() 里交给 GPU。GPU 喜欢一口气处理一整批任务，讨厌断断续续的加急单。同步等待更是大忌，它会阻塞主线程，让页面看起来像厨房着火一样卡死。

性能调优做完后，你会惊喜地发现，回退到 WebGL2 的“老烤箱”也能撑住基础体验。这再次印证了兼容性的目标：不是让低端设备跑出高端性能，而是让所有设备都有可接受的表现。

t帧=t计算+t上传+t回读+t同步\displaystyle t_{\text{帧}} = t_{\text{计算}} + t_{\text{上传}} + t_{\text{回读}} + t_{\text{同步}}
帧耗时是四项之和。优化方向不是只看计算有多快，而是在上传、回读、同步等待上都做减法。
  1. 计算时间GPU 真正执行着色器和并行计算的时间。
    t计算\textstyle t_{\text{计算}}
  2. 上传时间CPU 把模型权重、图像纹理等数据交给 GPU 的时间。
    t上传\textstyle t_{\text{上传}}
  3. 回读时间GPU 把处理结果传回 CPU 的时间，常用于统计和调试。
    t回读\textstyle t_{\text{回读}}
  4. 同步等待时间CPU 等 GPU、或者 GPU 等数据造成的空闲时间。
    t同步\textstyle t_{\text{同步}}

调试技巧：顺着烟雾找火源

后厨最怕什么？不是火太小，而是火太大冒了烟，大家却不知道烟从哪里来。WebGPU 开发也一样，很多问题在开发机上完全正常，一到用户浏览器就黑屏、掉帧、甚至设备直接丢失。这时候不能干瞪眼，而要有一套顺着烟雾找火源的调试方法。

首先要监听设备丢失事件。device.lost 一旦触发，说明 GPU 设备已经不可用，比如驱动崩溃、系统睡眠唤醒、浏览器后台回收等。此时不能继续提交命令，而要重建设备、重新创建资源，并把用户带回初始化流程。其次是监听 uncapturederror，它能捕获那些没有被显式错误作用域接住的 GPU 错误，相当于厨房里的烟雾报警器。

WebGPU 还提供了错误作用域机制：用 pushErrorScope() 圈住一段操作，再用 popErrorScope() 取出错误。就像你怀疑某个烤箱有问题，就单独盯着它烤一轮，而不是等整间厨房冒烟才知道出事了。浏览器自带的 GPU 调试面板和性能分析工具同样重要，它们能显示每一帧的 GPU 占用、缓冲区大小和调用耗时，帮你从烟雾中精确定位火源。

调试的第一原则是保留现场。就像火灾调查要保存监控录像一样，一旦 device.lost 或 uncapturederror 触发，就要把适配器信息、浏览器版本、当前后端、错误堆栈全部记录下来，再上传到日志平台。这样你才能知道“哪家分店、哪台设备、哪份配方”最容易出问题。

定位=设备丢失事件∨未捕获错误∨GPU 调试面板\displaystyle \text{定位} = \text{设备丢失事件} \lor \text{未捕获错误} \lor \text{GPU 调试面板}
这个公式表达的是“多路排查”。设备丢失负责大崩溃，未捕获错误负责小异常，调试面板负责性能隐患，三者结合才能覆盖从崩溃到卡顿的全过程。
  1. 设备丢失事件最严重的烟雾，代表 GPU 上下文已经失效。
    设备丢失事件\textstyle \text{设备丢失事件}
  2. 未捕获错误日常编程中漏掉的校验错误，需要监听兜底。
    未捕获错误\textstyle \text{未捕获错误}
  3. GPU 调试面板用来观察帧耗时、调用次数和资源占用。
    GPU 调试面板\textstyle \text{GPU 调试面板}
  4. “或”组合任一信号出现，都能帮助我们定位问题。
    A∨B∨C\textstyle A \lor B \lor C

AI 应用场景

浏览器端人像分割与背景替换

阶段：运行时部署与兼容策略

解决的问题：在线会议、短视频编辑里常用到人像分割，传统纯 WASM/CPU 方案在低端设备上只能跑到十几帧，体验很差。WebGPU 能把分割模型的计算放到 GPU 上并行执行，但部分浏览器不支持，直接使用会让不少用户无法进入会议。

具体案例：某在线会议产品使用 onnxruntime-web 的 WebGPU 执行提供程序跑人像分割模型，初始化前先做特性探测，不支持 WebGPU 时自动切换到 WebGL2/WASM 后端。桌面端开启“高清背景虚化”，移动端只提供“基础抠图”，所有用户都能正常开会。

文生图 WebDemo 的渐进降级

阶段：模型演示与用户体验

解决的问题：很多 AI 公司会做浏览器端的文生图 Demo 来吸引用户，如果只支持 WebGPU，Safari 和低端 Android 用户打开后只能看到加载失败，白白流失潜在客户。

具体案例：一个基于 Transformers.js 的文生图页面，在初始化时先检查 navigator.gpu 和 requestAdapter()，能用 WebGPU 就启用快速采样；否则自动降到 WebGL2，再不行就用 WASM 跑简化模型。页面上始终显示“当前加速模式”，让用户了解体验差异。

Python 演示

python31 行
# WebGPU compatibility planner simulation# It checks browser features and picks the best render backend. REQUIRED = {"webgpu", "webgl2", "float32", "instancing"}  def pick_backend(browser_features, secure_context):    if not secure_context:        return "CPU"    matched = len(REQUIRED & browser_features)    coverage = matched / len(REQUIRED)    if coverage >= 0.9 and "webgpu" in browser_features:        return "WebGPU"    if coverage >= 0.6 and "webgl2" in browser_features:        return "WebGL2"    return "CPU"  def main():    matrix = {        "chrome_win": {"webgpu", "webgl2", "float32", "instancing"},        "firefox_linux": {"webgl2", "float32", "instancing"},        "safari_ios": {"webgl2", "float32"},        "old_mobile": {"canvas"},    }    for browser, features in matrix.items():        print(f"{browser} -> {pick_backend(features, secure_context=True)}")  if __name__ == "__main__":    main()
目的：用一套简化规则模拟“先看支持矩阵、再做特性探测、最后选择后端”的兼容性决策流程，帮助理解跨浏览器选择策略。
  1. REQUIRED = {"webgpu", "webgl2", "float32", "instancing"}定义“配方必需特性”，相当于支持矩阵里的必需项清单。
  2. matched = len(REQUIRED & browser_features)计算当前浏览器命中了多少必需特性，对应“已确认可用特性数”。
  3. coverage = matched / len(REQUIRED)算出可支持度，决定走哪条后端路径。
  4. if coverage >= 0.9 and "webgpu" in browser_features稳定支持 WebGPU 时才走主流程，避免强行上车。
  5. if coverage >= 0.6 and "webgl2" in browser_features覆盖率不足时退回 WebGL2，保住基础功能。

常见误区

误区我看到 `navigator.gpu` 存在，就直接创建设备开始跑 AI 模型，反正浏览器已经支持了。

正解navigator.gpu 只代表浏览器带了这个 API，不代表用户机器真的能请求到 GPU 适配器。远程桌面、虚拟机、屏蔽硬件加速等场景都可能让 requestAdapter() 返回 null。正确做法是先异步请求适配器，再检查所需特性和限制，全部通过后才创建设备。

为何常见：开发者通常只在最新版 Chrome 上验证，自己机器一跑就通，于是把“入口存在”误当成“全功能可用”。

误区反正都调用 GPU，WebGL2 也能做 AI 计算，WebGPU 不支持时用 WebGL2 顶上就行，体验一模一样。

正解WebGL2 的并行计算模型、存储限制和现代 GPU 特性都不如 WebGPU，它更适合做渲染回退，而不是通用计算平替。AI 推理中的大批量矩阵运算在 WebGL2 上会明显变慢，因此回退只是保证“可用”，不等于“同性能”。

为何常见：两者都是浏览器里的图形 API，初学者容易把“都能画图、都能算”等同于“能力等价”。

误区WebGPU 是浏览器 AI 的未来，如果用户浏览器不支持，这个功能干脆就别做了。

正解真实用户环境非常复杂，但渐进增强和降级回退的组合能覆盖绝大多数场景。基础功能用 CPU/WebGL2 跑，WebGPU 只作为增强层，用户依然能使用 AI 能力，只是速度或画质低一些。

为何常见：Demo 里 WebGPU 的加速效果太惊艳，开发者容易忘记还有大量老浏览器和低端移动设备。

误区GPU 设备丢失很罕见，就算发生了，用户刷新一下就好，不用专门处理。

正解移动端浏览器切换后台、GPU 驱动崩溃、系统资源紧张都会触发设备丢失。如果不管，用户会看到画面冻结或直接白屏。正确做法是监听 device.lost，清理旧资源，重新走初始化流程并保留上一次状态，让用户无感恢复。

为何常见：在开发机上连续跑几小时都不触发，导致开发者低估了它在真实碎片化环境里的出现频率。

面试题

Q1. 做 WebGPU 跨浏览器兼容性处理时，第一步应该做什么？

单选题 · easy

  • A.梳理目标浏览器支持矩阵← 正确答案
  • B.立刻编写高性能着色器
  • C.禁止旧浏览器访问页面
  • D.直接调用 requestAdapter

答案：A。兼容性处理必须先搞清楚目标环境中哪些浏览器、哪些操作系统、哪些 GPU 能力可用，也就是先建支持矩阵。跳过规划直接写着色器，或直接调用适配器，都是“不看清厨房就开火”的做法。

Q2. 下列哪个 API 用于请求 GPU 适配器？

单选题 · mid

  • A.navigator.gpu.requestAdapter()← 正确答案
  • B.navigator.webgpu.requestAdapter()
  • C.navigator.gpu.createAdapter()
  • D.window.requestWebGPUAdapter()

答案：A。WebGPU 的标准入口挂在 navigator.gpu 下，请求适配器的方法是 requestAdapter()。createAdapter 和 window.requestWebGPUAdapter 都不是标准 API，navigator.webgpu 也是错误路径。

Q3. 当 WebGPU 不可用时，推荐的降级路径是？

单选题 · mid

  • A.WebGL2 后端，再退到 CPU 兜底← 正确答案
  • B.WebGL1 后端，再退到 GPU 兜底
  • C.WebGPU 后端，再退到 WebGL2
  • D.报错后引导用户升级浏览器

答案：A。降级回退的经典链条是 WebGPU → WebGL2 → CPU。WebGPU 已经不可用，再选 C 没有意义；WebGL1 和 GPU 兜底的说法不是主流方案。正确原则是让功能持续可用，而不是把用户挡在门外。

Q4. 特性探测至少要覆盖哪些层面？

多选题 · mid

  • A.入口 API 是否存在← 正确答案
  • B.GPUAdapter 是否能请求到← 正确答案
  • C.所需 feature 是否被支持← 正确答案
  • D.CSS 动画是否启用

答案：ABC。WebGPU 可用性由入口、适配器、特性三者共同决定。CSS 动画与 GPU 计算无关，不应作为 WebGPU 特性探测的指标。

Q5. requestAdapter() 返回 null，最准确的解释是？

单选题 · hard

  • A.当前环境没有可用 GPU 适配器← 正确答案
  • B.WebGPU API 的入口不存在
  • C.着色器编译失败需要修改
  • D.显卡新到驱动还不支持

答案：A。返回 null 说明入口虽然存在，但系统没有协商出可用的 GPU 适配器，比如远程桌面或硬件加速被关闭。入口不存在会在访问 navigator.gpu 时就报错，而不是拿到 null。

Q6. 渐进增强方案的核心思路是？

单选题 · hard

  • A.从基础可运行版本开始叠加增强← 正确答案
  • B.只支持最新浏览器的全部特性
  • C.用 WebAssembly 屏蔽所有差异
  • D.越早调用 WebGPU 越好

答案：A。渐进增强先保证基础功能在弱环境可用，再给强环境叠加增强能力，与“从高配往下砍”的降级思路相反。WebAssembly 只是其中一种能力，不能代替整体设计。

Q7. 下列哪些做法能提升 WebGPU 兼容性？

多选题 · mid

  • A.设置合理的 limits 回退← 正确答案
  • B.在初始化前做特性探测← 正确答案
  • C.捕获 device.lost 事件← 正确答案
  • D.直接同步创建多个设备

答案：ABC。先探测、再按设备能力设置 limits、并在设备丢失后重建，都能让应用适应不同环境。同步创建多个设备既不是兼容性手段，也可能造成资源浪费。

Q8. 判断浏览器是否有 WebGPU 入口，最稳妥的方式是？

单选题 · easy

  • A.检查 navigator.gpu 是否存在← 正确答案
  • B.检查 window.WebGPURenderer
  • C.检查 WebGLRenderingContext
  • D.检查 chrome://gpu 标志

答案：A。WebGPU 的标准入口是 navigator.gpu。检查 WebGL 上下文只能判断老接口，chrome://gpu 只是浏览器内部工具，不能作为代码中的运行时判断依据。

Q9. device.lost 事件触发后，正确的处理方式是？

单选题 · hard

  • A.重建设备与资源并回到启动流程← 正确答案
  • B.忽略事件继续提交命令
  • C.清空 webgpu 属性后重试
  • D.直接刷新页面不再请求适配器

答案：A。设备丢失说明当前 GPU 设备已失效，继续提交命令只会得到更多错误。正确做法是销毁旧资源、重新请求适配器、重建设备和管线，并恢复到用户可见的可用状态。

Q10. 调试 WebGPU 问题时，推荐的手段包括？

多选题 · mid

  • A.监听 uncapturederror 错误事件← 正确答案
  • B.使用浏览器 GPU 调试面板← 正确答案
  • C.使用 pushErrorScope 收集错误← 正确答案
  • D.用 alert 同步阻塞渲染循环

答案：ABC。uncapturederror、错误作用域和 GPU 调试面板是 WebGPU 调试的三大抓手。用 alert 阻塞渲染循环会破坏帧节奏，而且无法拿到 GPU 底层错误细节，属于错误的调试方式。