WebGL 能力与隐私：实用的应用指南

WebGL 为网页应用提供由浏览器管理的图形表面，可显示交互式二维和三维内容。它适用于需要频繁绘制、空间交互，或普通页面元素难以清楚表达的图形任务。重视隐私的 WebGL 使用方式，先问一个比“设备能透露什么”更窄的问题：用户要求什么图形结果，该结果需要哪一级支持，以及首选路径不可用时还有什么可用替代方案。

支持情况并非简单的是或否。某个环境中的浏览器可能支持 WebGL 1、WebGL 2、两者或都不支持。浏览器策略、图形软件、操作系统选择或资源限制，都会使某设备可用的功能在另一设备上不可用。应用应把差异作为兼容性输入，而不是收集详细设备档案的理由。

这个区分能把正常的能力处理与跟踪分开。图形应用可能需要知道能否显示用户要求的场景，却很少需要保留作出决定所依据的设备信息清单。如需了解相关跟踪方式及隐私影响，请阅读 WebGL 指纹概览。如需了解较新的图形 API 及其独立支持模型，请参阅 WebGPU 隐私指南。

为明确的图形任务选择 WebGL

先确定用户应该看到或控制什么。WebGL 常用于交互地图、产品视图、科学可视化、游戏、模拟和图像效果。这些任务可能包含许多对象、频繁更新，或适合由专用图形管线处理的变化。只有当技术选择使用户任务成为可能或显著改善任务时，才有理由采用它。

并非所有视觉内容都需要 WebGL。静态插图可能更适合作为图像。简单图表使用语义化页面元素或无障碍图表组件，可能更易阅读、打印和导航。基本界面控件应使用 HTML，因为其标签、焦点行为、文字选择、翻译和辅助技术支持已有成熟做法。选择简单的表面能减少开发工作，也减少应用需要管理的兼容性决定。

这个区别也影响隐私。若页面只为明确的视觉结果使用 WebGL，检查范围可以紧贴该结果。若页面没有可见目的却初始化图形并收集广泛环境信息，用户与应用之间的关系便不同。技术 API 可能相同，但数据用途、保留方式和用户预期并不相同。

在开始实现前写明最低体验要求。指出场景、关键交互、可接受的视觉质量，以及何时简单表示已经足够。产品查看器可能需要旋转和缩放，却不需要电影级效果。数据可视化可能需要清晰的选择和标签，却不需要持续动画。这些决定有助于应用只询问实际使用所需的图形支持。

尽可能把核心产品操作放在绘图表面之外。导航、购买控件、账户操作、同意选项和帮助链接应保留为普通页面控件。WebGL 场景可以支持任务，但不应成为用户唯一的操作途径。如果图形上下文在页面载入后不可用，这也能让恢复更容易。

动画和视觉密度需要单独设限。动画场景可以表达空间变化，但持续移动可能分散注意力或使人不适。尊重减少动态效果的偏好，在非必要移动时提供暂停控件，也不要让操作说明依赖短暂动画。场景静止时，用户仍应理解当前状态。

资源使用也是产品选择。复杂场景可能消耗内存、电量和处理时间。应用应依据任务实际表现和明确的质量选择调整自身内容，而不是试图推断详细设备身份。若低细节模式对用户有意义，就让其选择，并在移除可选效果后保留核心任务。

明确的用途也有利于维护。当浏览器更新改变图形行为时，团队可以把受影响的用户结果与既定要求比较。没有这些要求，兼容性工作容易变成对环境差异的无边界搜索。明确任务归属可让 WebGL 成为范围有限的应用组件，而不是通用能力探测。

将 WebGL 支持视为兼容性合同

Khronos WebGL 规范定义 WebGL 和 WebGL 2 的平台合同。MDN 从应用角度记录 API，并说明两个版本之间的关系。WebGL 2 增加了超出 WebGL 1 的平台能力，但不能仅因浏览器较新就假定它可用。实际环境包括浏览器、操作系统、图形栈、管理策略和当前资源状态。

因此，应用需要明确的最低支持要求。决定 WebGL 1 是否足够、是否必须使用 WebGL 2，或体验是否提供不同质量级别，并把决定与可见功能关联。如果某项功能确实依赖较新的合同，就说明较低级路径为何无法呈现相同结果。如果差别仅在视觉润饰，就应让主要交互在覆盖面更广的路径上可用。

能力检查应回答具体的应用问题。例如，所需图形上下文能否创建，场景能否在应用支持的质量级别内绘制，以及必要的媒体输入能否使用。应用一旦获得足以选择受支持路径的信息，就应停止。决定使用标准场景、简化场景或非 WebGL 替代方案，不需要完整环境清单。

即使之前访问成功，上下文创建仍可能失败。用户可能更改浏览器设置，系统更新可能改变图形支持，管理员可能应用策略，浏览器也可能因当前条件拒绝请求。应把失败作为正常产品分支处理，不要留下空白画布、无限加载提示或没有说明的禁用控件。

页面打开期间支持情况也可能变化。资源回收或图形环境变化可能导致浏览器丢失图形上下文。保留周围界面，用通俗语言说明情况，并提供范围明确的恢复操作。如果恢复场景会丢失未保存工作，应在重试前解释；条件允许时，把应用状态保存在图形表面之外。

不要把每种环境差异都变成一个产品变体。少量基于结果的级别，比许多按设备区分的分支更易测试和说明。例如，标准模式、简化效果模式和静态替代方案，都是团队可以明确负责的体验，也限制了应用需要处理的能力信息。

应明确版本支持的责任归属。记录产品当前支持的浏览器系列和版本范围、每种体验所需的 WebGL 版本，以及超出范围时采用的回退。这份记录属于产品兼容性政策，不应变成对所有图形驱动或设备都会绘制相同像素的保证。

兼容性说明应描述结果，而非内部细节。“可以交互旋转”对读者有帮助；一长串底层图形细节则不易理解，也可能透露超出决定需要的信息。当浏览器改变实现但保留相同用户可见行为时，结果表述也更稳定。

当产品新增视觉技术、提高场景复杂度、更换媒体输入，或要求使用 WebGL 2 时，应重新检查合同。浏览器发布新版本本身不要求改写政策；只有用户需求或已验证的支持证据改变时才调整合同。

构建渐进增强和实用回退

渐进增强让页面在确认首选图形路径之前仍然可用。先用普通 HTML 呈现周围内容、控件、标签和状态，再在浏览器支持所需任务时加入 WebGL 体验。即使脚本载入较慢、图形初始化失败或策略不允许创建上下文，用户仍能看到可理解的内容。

回退应保留任务目的，而不是模仿每个视觉细节。三维产品查看器可以回退到精选图片集。交互地图可以提供可搜索列表、路线摘要或适合任务的静态地图。科学可视化可以同时提供数据表、关键发现和可下载格式。若游戏没有等价交互，可以明确说明不受支持，但账户和购买控件仍应可用。

回退应与相同的数据状态保持一致。如果筛选条件会改变 WebGL 可视化，表格或摘要也应反映相同筛选。如果用户选项改变了渲染的产品模型，图片集和说明文字也应同步改变。两个表示不一致既是无障碍问题，也是产品正确性问题。

如果降低视觉质量仍能完成任务，就不要把它称为错误。简化效果场景可以是受支持的模式，而不是首选模式的损坏版本。说明会影响交互或含义的差别，但不要让用户承担实现细节。简单的质量控件可以让人作出可预期的选择，而不必理解图形环境。

加载行为也需要明确回退。即使 WebGL 可用，大型场景和纹理仍可能需要时间载入。显示与实际应用工作对应的进度，保留取消操作，并避免用户进入功能前就启动大型下载。可选资源载入失败时，应保留仍能完成任务的场景部分，而不是丢弃整个体验。

网络状况可能独立于图形支持影响 WebGL 体验。浏览器可能成功创建上下文，但模型、图像或数据文件仍不可用。应分别报告这两种情况。若实际问题是资源缺失，却告知用户 WebGL 不受支持，会导致错误的支持判断和不必要的能力信息收集。

在状态切换时保留用户输入。如果用户在图形初始化失败前配置产品、选择位置或更改数据范围，应将这些选择带入回退。不要因为展示层变化就让用户重复操作。把应用状态保存在场景之外更容易维持连续性。

有界恢复尝试耗尽后，应停止重试，并显示包含相同任务数据和核心控件的等价 HTML 回退。保留已经存放在画布之外的应用状态；不要声称能够恢复只存在于已丢失图形上下文中的状态。这是产品流程边界：当前 fixture 只观察到恢复成功，未验证恢复失败分支。

有目的地测试回退。分别检查 WebGL 不可用、WebGL 2 不可用、可选资源被阻止、资源载入缓慢，以及交互中丢失上下文等情形。这些测试覆盖产品分支，而不是识别设备。预期结果应是可用状态和清晰操作，而不是列出特定环境为何不同。

将支持指引与用户可观察到的症状关联。指引可以说明如何重试、切换到简化视图、保留工作，或使用普通错误编号联系支持。默认不要要求用户提交广泛图形报告。若支持个案需要诊断信息，应说明用途，只请求最少相关信息，并限制保留期限。

让画布之外的体验保持无障碍

WebGL 画布呈现像素。画布中的对象不会自动成为辅助技术可理解的标题、按钮、表单字段或有意义的阅读顺序。因此，无障碍取决于画布周围的界面，以及页面提供的等价信息。

为视觉内容提供简洁的无障碍名称和描述，说明它的用途。“交互式产品视图”比“WebGL 画布”更有帮助。如果场景表达数据，应通过文字或结构化内容提供关键数值、关系或结论。如果场景支持操作，应提供无需依赖像素内指针位置也能触达和理解的控件。

键盘操作需要真实的交互模型。用户应能到达功能、了解可用操作、按可预测顺序移动焦点，并离开功能而不被困住。用于缩放、重置、暂停、切换视图等关键操作的普通按钮，比绘图中的不可见区域更容易命名和操作。焦点提示在页面和场景上都应清晰可见。

不要只用颜色、深度、运动或精细视觉细节表达含义。图表需要标签和可区分的图样；地图需要地点文字信息；状态变化需要在视觉效果之外提供消息。只短暂闪现红色的警告很容易错过，也不一定能被每位用户按预期感知。

图形场景中的文字有实际限制。它可能无法像 HTML 文字一样响应浏览器字号、翻译、选择、对比度偏好或阅读工具。说明、标签、法律通知、价格等需要准确阅读的信息，应使用页面文字。只有当绘制文字确实属于视觉内容时才保留，并在其他位置提供相同含义。

开始动画前尊重用户对动态效果的偏好。用户要求减少动态效果时，应减少或去除非必要的摄像机移动、粒子效果和自动过渡。暂停控件应停止有意义的持续运动，而不只是隐藏一个效果、让场景继续变化。静态状态仍须呈现任务和当前结果。

触控、指针和键盘操作应能达成相同的重要结果。手势可以让场景更易使用，但不应成为选择产品、查看数据点或继续工作流的唯一方式。为受支持的输入方式提供控件和说明，不要根据屏幕尺寸推断用户会如何操作。

无障碍测试应覆盖与视觉测试相同的产品状态。作为验收建议，检查首选 WebGL 路径、简化路径、回退、加载状态、失败消息和上下文恢复。应使用适合用户群体的工具核对名称、焦点顺序、键盘操作、屏幕阅读器提示、缩放、对比度和减少动态效果。当前 runtime fixture 只检查了画布名称和可见回退文字，未验证这些无障碍行为，因此这里是建议而非 fixture 结果。仅通过视觉审查的场景并不完整。

如果无法提供完全等价的非视觉交互，就诚实说明限制，并提供最接近任务目标的实用途径，例如结构化数据视图、支持协助流程或替代表单。该限制应是有责任人的产品决定，而不是假设每位用户都能操作像素画布。

将隐私数据限制在产品决定所需范围

WEBGL_debug_renderer_info 扩展会公开图形驱动的厂商和渲染器字符串。MDN 指出，这些信息通常只应在少数特殊情况下用于优化 WebGL 内容或调试 GPU 问题；浏览器的隐私设置也可能限制该扩展。普通兼容性检查只需确定所需路径能否运行。

只使用足以选择受支持路径的最小决定。如果应用只需知道标准场景能否启动，就不要收集详细环境报告。若需在两个质量级别间选择，保存最终选定的级别即可，不必保存每个输入。数据最小化便于说明、测试和最终移除相关行为。

若不需要长期保存，就把兼容性信息留在当前会话。页面可以为本次访问选择图形路径，而不把该选择变为持久标识。记住用户选择的质量偏好确有帮助时，应把它作为用户理解且可以更改的选择保存。不要把推断出的技术档案说成用户主动选择的结果。

除非产品有清楚且已说明的需要，否则不要把图形信息与账户、网络或无关浏览器数据结合。组合信号会改变隐私影响，即使每个单独值看起来普通。跨表面浏览器隐私指南 说明了为何多个表面合在一起会比单独观察更易揭示信息。

诊断信息需要与运行时兼容性分开处理。运维日志应记录产品结果，例如场景初始化失败或资源载入失败，而不是默认记录广泛图形清单。若支持调查需要更多细节，应在个案背景下提出请求，说明收集内容、限制访问，并依照明确的保留期限删除。

不要依据能力差异对用户作出敏感推断。图形支持不能可靠地说明身份、收入、残障、地点或意图。产品决定应只围绕用户要求的视觉能否运行。广泛推断会增加隐私风险，却不能改善图形任务。

第三方图形库和分析工具可能扩大数据流。检查库会收集什么、哪些端点会接收数据、收集是否为绘制所必需，以及信息会保留多久。为了视觉便利载入组件，不会免除应用对组件发送数据的责任。

若独立的数据用途是可选的，同意说明应写清真实用途。当详细诊断将被保留或共享时，笼统地说是为了提升性能并不充分。可选用途应提供有意义的选择，并在可行时让侵入性最低的受支持路径仍可使用核心体验。

隐私审查也应覆盖失败路径。回退页可能意外载入不同的分析脚本、请求更广泛的诊断报告，或暴露内部错误细节。首选、简化和失败状态都应遵守相同的数据最小化与保留规则。图形未能启动，并不构成在没有明确目的时收集更多信息的理由。

在该审查中，建议围绕正常启动、WebGL 2 不可用、上下文丢失和 HTML 回退路径捕获网络请求及支持/运维日志。核对默认不会发送渲染器或驱动清单，支持字段仅用于限定目的，并定义保留与删除日期。这些是建议的可观测性检查，不是运行时结论：当前 fixture 未检查网络流量、分析载荷、日志字段、访问控制或保留行为。

为每项保留的兼容性字段指定责任人。记录谁会使用、它支持哪个决定、何时过期，以及图形功能移除后如何处理。没有当前决定责任人的字段应删除。这样，隐私维护就成为日常产品工作，而不是偶尔检查一组无人解释的数据。

将来源、主张与可验证的兼容性证据对应起来

使用公开规范和 API 文档，把每项兼容性主张与应用可观察的结果对应起来：

• WebGL 与 WebGL 2 的可用性： Khronos WebGL 1.0 规范和 WebGL 2.0 规范，以及 MDN 的 WebGL API 参考，说明两代上下文及其能力。应用结果可验证：请求功能所需的上下文，在请求不可用时选择标准场景、简化场景或非 WebGL 回退。这项检查不需要建立设备档案。
• 上下文丢失与恢复： MDN 记录了 webglcontextlost 事件和 webglcontextrestored 事件。应用结果可验证：把状态保存在画布之外，提示发生丢失，执行次数有限的恢复尝试，恢复失败时提供回退。
• WEBGL_debug_renderer_info 的隐私边界： MDN 的扩展参考说明厂商和渲染器字符串是可选的，可能受隐私设置限制，主要用于特殊的内容优化或 GPU 调试。应用结果可验证：普通兼容性选择无需该扩展；如支持调查确实需要诊断信息，应有明确用途和有限保留期限，而不是形成持久设备档案。

这些链接支撑的是平台行为主张；产品测试仍应验证上述用户可见结果，不应进行像素比较、设备画像或浏览器识别。

能力、回退与上下文丢失的验收矩阵

使用以下简短矩阵作为应用验收建议。每一行都包含公开来源、可测试的应用结果和隐私限制；它不是跨浏览器或生产支持保证：

情形	来源支持的条件	可观察的应用结果	隐私边界
能力检查	根据 WebGL 1.0 与 WebGL 2.0 创建上下文。	请求功能所需的上下文；启动标准或简化场景，或选择可用的非 WebGL 表示。	结果只用于本次会话的路径决定。不要仅为选择路径收集渲染器、驱动或浏览器版本细节。
回退	相同的 API 来源定义所请求上下文不可用的情况；MDN WebGL API 参考说明应用表面。	回退保留相同数据状态、核心控件和任务结果，并显示清晰状态消息，而不是留下空白画布。	只记录结果（例如 context-unavailable）；不要把回退分支变成更广泛的诊断请求。
上下文丢失与恢复	MDN 记录 webglcontextlost 和 webglcontextrestored 事件。	周围界面和状态保持可用，执行次数有限的恢复尝试，恢复失败时用户可以选择回退。	默认不保留图形清单。支持诊断应独立处理，有明确用途并限制保留期限。

验收意味着每一行的可见结果都通过；不意味着应用能够识别设备或复现完全相同的像素。

可复现的应用验收检查

使用同一份应用测试夹具和相同的任务数据执行以下检查。记录浏览器版本、应用修订版本，以及展示给用户的路径。测试针对产品负责的结果，不是收集设备描述。

检查项	可复现设置	可观察结果	隐私非目标
画布与上下文创建	载入测试夹具，创建画布，并依据 Khronos WebGL 规范请求功能所需的上下文。	画布报告可用上下文，标准场景进入就绪状态；若创建返回 null，页面显示保留相同任务数据的非 WebGL 替代方案。	不要读取渲染器、驱动或浏览器版本细节来解释成功或失败。
所需特性不可用	保持上下文创建可用，再让所需的 WebGL 2 特性或扩展不可用；以 MDN 的 getExtension() 为 API 依据。	应用发现所需条件缺失，选择既定的简化路径或回退，保留控件和状态，并显示有限的状态消息。	不要枚举所有支持的扩展，也不要根据缺失特性推断设备类别。
上下文丢失	在场景就绪时触发有文档记录的丢失路径，并观察 webglcontextlost。	画布外控件仍可用，页面提示丢失，应用不会进入无限重新初始化循环。	不要把丢失事件变成图形清单或持久标识符。
上下文恢复或恢复失败	等待 webglcontextrestored，或让有界的恢复尝试失败。	场景在保留任务数据的情况下回到就绪状态，或用户可以通过清晰的恢复消息选择回退。	不要比较像素，也不要在获批准且限时的支持个案之外保留诊断字段。

验收标准是每一行的可见状态和已完成任务。设备识别、渲染器分类、像素匹配，以及声称 WebGL 支持能够证明身份，均不属于本测试。

如何解读一次 fixture 结果

runtime-20261005 记录是一次成功恢复的应用样例。配套的 webgl-api-capabilities-and-recovery-failure-runtime-20261001 记录是确定性的界面状态模型：它验证一次有界恢复尝试、保留用户选择、转移焦点、显示等价的 HTML 回退，并确认该 fixture 没有发出诊断请求。这个模型没有创建 WebGL 上下文，也不能证明真实的 webglcontextlost 事件会到达生产渲染器。两份记录都只是本机 Chromium 观察，不是浏览器兼容性或生产保证；应在产品明确负责的每个环境中重复真实的上下文和应用检查。

在不建立设备档案的情况下验证兼容性

兼容性测试应从用户可见结果开始。确认场景已载入、控件响应、必要内容清楚可读、用户能够完成任务，且回退路径会保留状态。这些判据描述应用承诺的体验，在浏览器和图形更新后仍然有用。

使用有文档记录的受支持环境集合，而不是试图代表所有可能设备。包括产品关注的浏览器系列、操作系统和版本范围，并覆盖首选路径、较低支持级别和非 WebGL 替代方案。目标是对团队负责的体验有信心，而不是建立环境差异数据库。

测试场景应对应具体产品功能。地图测试应覆盖实际使用的图层、标签、选择和导航。产品查看器测试应覆盖载入、旋转、缩放、选项更改和恢复。通用图形演示可以说明 WebGL 能运行，却不能证明产品自身资源、交互和回退可用。

确认所需对象、状态、标签或数据关系已经呈现且可以使用。按该产品结果记录失败。测试应判断体验是否可用，而不是描述设备特征。

将浏览器变化与资源、应用变化分开。需要可重复时固定测试输入，记录应用版本和测试使用的浏览器版本。场景改变时，这些信息有助于区分新资源、代码更改、依赖更新或浏览器行为变化。相关证据支持维护工作，同时不必从终端用户收集持久档案。

把上下文丢失和恢复作为产品行为测试。保留外部控件、应用状态和清晰状态消息。确认恢复尝试次数有限，用户也可以选择回退。持续重新初始化大型图形、却无法恢复任务的循环会降低可用性并消耗资源。

测试时也要检查隐私行为。确认正常启动不会发送不必要的图形清单，回退不会触发更广泛的诊断，并且记住的质量设置反映用户选择，而不是不透明推断。还应确认支持日志只含团队批准的有限结果字段。

发布审查应聚焦影响合同的变化。新浏览器版本可能改变可用性、性能、资源处理或视觉行为。应用发布可能新增图形技术或提高资源要求。重新运行受影响的产品路径，只有证据改变了用户可见要求时才更新支持指引。

浏览器版本验证流程 提供更广泛的受控更新框架。对 WebGL 而言，回归样例集应足够小，让每个场景都有明确用途。有归属的精简场景集合，比许多与产品行为无关的样例更有价值。

WebGL 最适合作为范围明确的展示层，具有清晰任务、书面的最低支持要求、实用替代方案和基于结果的测试。只询问选择团队负责体验所需的能力信息。让核心操作和含义在画布之外仍然可用，减少保留的诊断信息，并依照用户可见合同审查变化。这些做法能支持丰富的浏览器图形功能，而不把兼容性工作变成设备分析。

公开来源

• Khronos WebGL 规范
• MDN：WebGL API
• MDN：WEBGL_debug_renderer_info