WebGL 渲染器缺失：隐私设置还是上下文状态？

WebGL 渲染器值缺失不等于已经有了诊断结论。它可能对应可选扩展不可用、上下文从未创建成功、创建后发生上下文丢失，或者应用根本没有请求这个字段。把结果归因于隐私保护或图形问题之前，每种情况都需要不同的证据。

BotBrowser 文档说明了基于配置文件的 WebGL 控制，包括扩展可用性和报告的图形信息。但 BotBrowser 不能仅凭一个缺失值确定哪项具体设置已经生效。授权应用仍需区分自己的采集尝试、上下文生命周期，以及实际收到的可选信息。

摘要

• WEBGL_debug_renderer_info 提供可选诊断信息。拿不到扩展对象，本身并不能说明信息为何缺失。
• 分开保留 not_requested、context_unavailable、context_lost、extension_unavailable 和 reported。这是建议的支持记录状态，不是实测结果。
• getContext() 和 getExtension() 对应不同边界。把两种结果都压成空的渲染器字符串，会丢失区别。
• 隐私策略解释需要独立的策略证据；图形故障解释需要应用或上下文生命周期证据。
• 不能仅因可选渲染器元数据缺失，就拒绝一个仍能工作的可视化功能。用户任务的可见结果应单独记录。

目录

• 渲染器缺失有多种含义
• 五种状态保留诊断边界
• 隐私设置与应用故障需要不同证据
• 比较需要上下文和采集阶段
• 支持记录不必收集硬件身份
• BotBrowser 范围与验收问题
• 实践结论

上下文状态和可选元数据可用性属于不同字段。任何一个字段都不能单独确定渲染器值缺失的原因。

渲染器缺失有多种含义

扩展不是绘图上下文

Khronos 扩展规范 把普通渲染器和厂商参数与额外的未掩码诊断信息分开。应用可以拥有 WebGL 上下文，却没有拿到这个可选扩展对象。因此，绘图流程是否可用，以及能否取得更详细的图形元数据，是两个不同的问题。

这个区别会改变支持决策。一个已经显示数值的图表，与一个从未取得绘图上下文的图表，遇到的并不是同一种问题。仅因缺少渲染器标签就要求前者更换一个正常工作的浏览器，是把诊断便利性与用户真正需要的功能混在一起。WEBGL_debug_renderer_info 缺失不足以支持这种决定。

更广泛的 WebGL 指纹分析 讨论渲染器信息与其他图形表面结合后可能暴露什么。缺失值诊断的范围更窄：有没有尝试观察、观察发生在哪个阶段，以及该阶段能够确认什么。它不要求收集渲染输出，也不要求拼接设备签名。WEBGL_debug_renderer_info 隐私边界分析 单独说明从扩展查询到参数读取的分支。如需解读 CreepJS 报告中的 WebGL 上下文与能力信号，请参阅 CreepJS WebGL 报告分析。

null 结果属于一次调用

MDN 对 getExtension() 的说明 是：返回扩展对象，或者在请求名称不匹配可用扩展时返回 null。这个返回值只属于当前上下文中所请求的扩展。它不携带浏览器策略解释、物理 GPU 清单或认证结果。

getContext() 的范围不同。canvas 参考文档 说明：上下文标识不受支持，或 canvas 已设置为其他上下文模式时，会返回 null。如果采集代码把这个结果与扩展不可用都记录成同一种空值，就丢失了“当时哪一步操作可能执行”的信息。

异常又是第三种区别。如果应用代码在记录扩展结果之前就失败，采集代码并没有确认 extension_unavailable。异常可能来自应用自己的假设、过期状态或另一项操作。应把它保存为应用侧采集失败，放在渲染器值字段之外，而不是把每种失败都变成浏览器隐私结论。

五种状态保留诊断边界

下面的五状态词汇是自有应用支持记录的一种建议设计。它不是 BotBrowser 的输出转录，不是实测分布，也不是所有浏览器都会产生的结果清单。每一行都说明：应用分配该状态之前，至少需要具备什么观察。

记录状态	最低观察要求	仍未解决的问题	应用动作
not_requested	应用没有尝试采集渲染器信息	上下文或扩展原本是否可用	让诊断字段保持缺失，继续用户任务
context_unavailable	未取得所请求的绘图上下文	上下文创建失败的原因	检查创建证据与用户可见的替代视图
context_lost	已知现有上下文在观察阶段处于丢失状态	丢失原因与恢复结果	进入应用自己的恢复流程
extension_unavailable	有存活的上下文，但请求的可选扩展不可用	是实现支持还是策略导致缺失	不依赖可选渲染器标签继续工作
reported	已取得请求的诊断信息	物理设备身份、用户身份与未来可用性	只使用支持问题确实需要的信息

未请求不等于不可用

not_requested 可以避免一种常见分析错误：把每个空字段都当作请求失败。应用可能按设计不采集可选图形诊断，等到用户请求支持时再采集，或在用户撤回同意后停止采集。这些路径都不能证明浏览器没有提供某个值。

记录应该描述应用实际做了什么。如果某个版本移除了渲染器采集，再把空字符串总数与旧版比较，就可能把主动减少采集误认为浏览器回归。在授权支持记录确实需要这种区别时，应包含采集策略版本；不能默默按旧采集代码的行为解释新记录里的缺失字段。

五种状态并不覆盖所有应用错误。支持导出被拒绝、用户取消操作，或检查上下文之前出现异常，都应该属于另一个结果字段。分配 context_lost 需要生命周期证据，分配 reported 需要一次完成的信息请求。若默认分支把所有未知路径都标成 extension_unavailable，就会重新制造原来的歧义。

缺失不等于已报告的空字符串

扩展结果、渲染器值与序列化后的支持记录是不同对象。如果序列化器删除属性，或把一个值替换成空字符串，导出的文档就可能不再保留采集结果。对 WEBGL_debug_renderer_info 下结论之前，应先排查这次转换。

reported 应与值的格式校验分开。记录结构可以拒绝格式不正确的支持数据，但这不意味着浏览器拒绝了访问。同样，界面为了节省空间而不显示渲染器标签，也不该把底层观察改写为扩展不可用。这些是应用转换，不是对浏览器另一层的测量。

隐私设置与应用故障需要不同证据

有文档的隐私示例不是通用解释

MDN 的扩展参考文档 说明可用性受浏览器隐私设置影响，并明确指出 Firefox 开启 privacy.resistFingerprinting 时会禁用这个扩展。这是一个有文档支持的策略影响信息暴露的例子，不代表任何渲染器缺失值都能证明该设置或某种等效设置已经开启。

反向推论也不成立。能够取得渲染器值，并不能证明浏览器的所有隐私控制都处于关闭状态。这个观察只涉及某个上下文中的一个信息表面。隐私保护还包括其他数据、采集目的与保留期限的决策，成功调用 getExtension() 并不能回答这些问题。

在受控自有浏览器的支持会话中，可以结合相关配置、浏览器文档和采集阶段保持不变的对比，佐证策略解释。普通网站往往拿不到这些证据。这时准确的描述就是 extension_unavailable，原因仍未确定。仅为填满一个可选诊断字段而要求用户关闭隐私保护，并不是应用功能本身的要求。

创建失败需要创建证据

webglcontextcreationerror 参考文档 描述了上下文创建尝试不成功时的事件。它的 statusMessage 可能含有与平台有关的信息。这个证据针对创建过程，不能与已存在上下文上的可选扩展不可用互换。

不能假设每次创建失败都有同样的消息，也不能假设消息适合集中遥测。平台相关字符串可能缺失，也可能含有支持任务不需要的细节。只有用户选择相应支持路径时，才保留范围受限的本地诊断。常规产品记录可以只保存 context_unavailable 和用户可见替代视图的结果。

应用还需要确认自己如何使用 canvas。若代码已经在这个 canvas 上请求过另一个绘图模式，getContext() 文档中的“其他上下文模式”条件就很重要。把这种结果叫作隐私限制，是把应用前置条件错误归因于浏览器策略。更改用户浏览器配置之前，应先检查 canvas 的归属和初始化顺序。

比较需要上下文和采集阶段

丢失发生在上下文存在之后

webglcontextlost 事件 针对浏览器报告为丢失的绘图缓冲区。isContextLost() 提供上下文状态检查。它们描述生命周期状态，不是事件原因的可靠解释，也不是用户设备的永久属性。

丢失前记录的值，与应用正在处理丢失时记录的缺失值，不是可直接比较的观察。浏览器、设备和应用版本可能都没变，变化的是采集阶段。如果支持判断需要这种区别，就应明确记录阶段。否则，分析面板可能把一次中断误判为图形信息暴露的稳定变化。

恢复又引入一道边界。MDN 文档 说明，丢失之前创建的资源在恢复后不再有效，需要重新创建。成功恢复绘图，不能为应用旧代码保存的扩展对象或缓存诊断结果背书。比较新旧观察之前，应先协调应用状态。

软件渲染与隐私指南 更详细地讨论了绘图替代方案与资源恢复。渲染器字段缺失并不能决定“正在软件渲染”这一诊断。字段可以在绘图成功时缺失，也可以在后续失败之前存在；应记录任务结果，而不是从元数据推断任务结果。

自有应用的对比场景

以下场景描述的是建议的验收计划，不是已经执行的结果。应保持应用测试页面和用户可见任务不变，只改变该行指明的条件；如果现有证据不能区分不同解释，就保留原因未确定的状态。

受控场景	记录必须保留的区别	验收问题
不请求采集渲染器	not_requested 不是扩展失败	不采集标签时，可视化是否仍然可用？
未取得请求的上下文	context_unavailable 不是扩展结果	替代视图是否保留了用户任务？
存活上下文上的可选信息不可用	元数据暴露与绘图就绪是两件事	采集是否正常结束，而没有把用户设备判为故障？
执行任务时发生上下文丢失	采集阶段不同于初始就绪阶段	支持记录是否保存了丢失状态，而不是复用旧标签？
应用在恢复后继续运行	新资源与旧观察具有不同生命周期	后续记录是否描述当前阶段和任务结果？

这些比较不能证明设备的唯一性，也不能证明第三方检测系统的判断。它们检查的是应用能否准确记录自己的控制流程。因此，即使渲染器标签仍然缺失，只要缺失分类准确、产品声明的替代方案可用，支持测试也可以通过验收。

支持记录不必收集硬件身份

先保存区别，再考虑字符串

例如，“这个应用版本上线后，可选元数据是否消失？”这种支持问题通常首先需要采集状态和应用版本标识，并不自动需要所有访问者的原始 UNMASKED_RENDERER_WEBGL 值。只有字段能够回答事件中明确提出的问题时才添加它；与问题无关时，就不要放进常规分析数据。

下面的字段属于记录设计建议。它们不是 WebGL 的标准返回值，也不意味着 BotBrowser 会自动输出这套结构。应用自己定义的标签，应与浏览器返回的数据分开，避免后来的阅读者把采集代码枚举误认为浏览器 API 结果。

支持字段	用途	采集边界
应用版本	确定执行的是哪个版本的采集代码和可视化代码	使用应用版本标签，而不是个人标识
采集阶段	区分初始化、正常使用与恢复	只记录事件判断所需的阶段
渲染器信息状态	保留五种观察状态中的一种	不推断未观察到的原因
任务结果	区分可用可视化、替代视图与任务中断	不与渲染器元数据合并
诊断同意	说明用户是否选择额外的支持导出	不把未导出改写成浏览器拒绝

not_requested 记录比例变化，可能由采集策略解释；context_unavailable 增加，则需要调查创建路径。这些都只是需要结合应用版本和支持证据验证的假设，任何一种类别都不提供对访问者进行分类的规则。

详细诊断与常规事件分开

当某个具体图形事件确实需要渲染器字符串时，应明确采集目的和导出边界。用户可以选择提供范围受限的支持附件，而不等于同意永久的硬件关联遥测。除非支持请求确实需要关联，否则不要把这个附件与账户标识合并。

保留和访问规则同样重要。短期事件记录与持久浏览器指纹的目的不同。不要把原始渲染器字段复用为稳定账户键，不要声称它认证了物理机器，也不要把它消失理解为用户已经换了设备。观察本身的范围，小于这些结论。

记录结构变更也需要同样的约束。如果旧采集代码使用空字符串，新采集代码使用 not_requested，历史记录不会因此补上原本不存在的区别。迁移时应把历史状态标为未确定，而不是事后为其分配原因。分析面板可以保留“历史原因未知”类别，不必编造旧代码从未保存的观察。

BotBrowser 范围与验收问题

BotBrowser WebGL 文档 说明了配置文件驱动的图形输出和扩展可用性，产品能力应归因于这份文档。Khronos 扩展规范与 MDN 页面解释的是 WebGL 接口，并不描述 BotBrowser 配置文件行为。在技术说明和本地化支持材料中，应把这些来源分开。

授权 BotBrowser 对比应说明所声明的配置，以及正在比较的应用阶段。渲染器标签缺失本身，不能确认目标配置文件已加载、某个图形模式已选中，或宿主发生了变化。对验收场景分配结果之前，需要来自自有应用环境的实际观察。

验收边界是产品在可选信息缺失时的行为。能够完成任务的可视化应该继续工作；创建失败应该进入替代视图；上下文丢失流程应该保留任务状态，并区分后续观察与旧观察。这些要求都不需要承诺跨宿主图形输出完全一致，也不需要承诺某个私有检测器的结论。

常见问题

渲染器缺失是否意味着 WebGL 已禁用？

不是。拿不到 WEBGL_debug_renderer_info 对象，与拿不到绘图上下文，是不同观察。应先确认尝试过哪一次调用，以及应用当时是否有存活的上下文。若这些事实没有记录，旧的空字段不能事后证明任何一种状态。

空字段能否识别某个具体隐私设置？

不能单凭它识别。浏览器文档可以指出哪些策略影响扩展暴露，但缺失字段并不能说明实际使用了哪一种策略。应在授权环境中佐证解释，或保留不带因果标签的 extension_unavailable。不可用字段并不能确定一个人的意图。

诊断空白图表是否必须收集渲染器字符串？

它不应该是第一步。空白图表可能涉及上下文创建、应用资源、生命周期处理或数据。应先检查任务结果和相关上下文状态。原始 UNMASKED_RENDERER_WEBGL 字符串只是额外的诊断输入，不能代替任务失败本身的证据。

来源

• Khronos：WEBGL_debug_renderer_info 规范
• MDN：WEBGL_debug_renderer_info
• MDN：WebGLRenderingContext.getExtension()
• MDN：HTMLCanvasElement.getContext()
• MDN：WebGLRenderingContext.isContextLost()
• MDN：webglcontextcreationerror 事件
• MDN：webglcontextlost 事件
• MDN：webglcontextrestored 事件
• BotBrowser：WebGL 文档

实践结论

保留 not_requested、context_unavailable、context_lost、extension_unavailable 和 reported 之间的区别。解释渲染器字段为何缺失之前，先确认应用的请求尝试与采集阶段。不要把任务成功与可选诊断元数据混为一谈；只有明确的支持问题确实需要时，才采集详细图形信息。