WebGL 上下文恢复后还是黑屏，怎样验证纹理和着色器必须重建

WebGL 上下文恢复不代表旧纹理、buffer 与着色器程序仍有效。先停止依赖旧资源的绘制，在 webglcontextrestored 后按资源清单重新创建并画一帧，再以实际像素确认恢复。

先检测能否模拟这条故障

附件检查WEBGL_lose_context扩展；若不存在，执行记录明确unsupported，只能证明完成能力检测。扩展可用时先画一帧红色并读回，再主动loseContext，等待原生丢失事件，最后请求恢复并等待恢复事件。没有人工dispatch这些事件，也不把扩展模拟写成真实GPU驱动崩溃。

允许恢复不等于已经恢复

webglcontextlost处理函数调用preventDefault，给恢复流程保留条件，并记录lost。此时应用应停止正常渲染和资源提交，避免错误刷屏。restoreContext后的完成仍是异步事件，不能紧接着就拿旧program继续绘制。脚本等待restored后检查旧程序对象已不是有效program，明确资源重建的必要性。

按依赖顺序重新建立资源

本例重建着色器、链接program、创建buffer、绑定attribute并恢复viewport，再画固定三角形，读到红像素才宣布本例恢复成功。真实工程还包括纹理、framebuffer、uniform、扩展与渲染状态，应该有可重入的初始化和独立源数据。若图片只存GPU纹理没有CPU侧来源，恢复时就可能无从重建，交付时要先列清资源所有权。

恢复后仍需业务层核对

只出现restored事件却没有画面，不应立即重启整台播放机来掩盖缺失的重建步骤；先看资源清单、编译错误与第一帧像素。相反，小三角形恢复成功也不能证明完整展项、长时运行或真实显卡性能正常。附件限定WebGL1和SwiftShader软件后端，未测实体GPU、硬件故障频率或跨浏览器恢复策略，现场需要独立压力与运维测试。

资源描述与GPU句柄分开保存

恢复流程应以可重建描述为依据，例如着色器源码、顶点数组与图片来源，而不是把旧WebGL对象引用当作唯一资源记录。上下文恢复后对象的JavaScript变量仍存在，不代表内部GPU句柄可继续使用。附件通过isProgram确认旧程序失效，再创建新程序，正是为了区分“变量没有丢”与“资源仍有效”。大项目应逐类建立重建清单，避免只重建一张纹理便宣称全部恢复。

下载并复现

下载原创HTML夹具、独立验证程序、本次执行记录和依赖与运行说明，放在同一目录。安装Playwright 1.58.0及其Chromium后运行 python verify.py；程序使用两个随机本地端口，自动关闭浏览器与服务，不请求外网或业务接口。

本次实际环境为Python 3.12.4、Playwright 1.58.0、Chromium 145.0.7632.6。Canvas2D或WebGL1页面API与像素读取；非指针输入、非实体GPU性能测量。断言已通过；完整事件和数值保留在执行记录，不能把它改名后当目标展项测量。

Canvas题限定2D上下文，WebGL题限定WebGL1；启动使用ANGLE SwiftShader软件后端参数，实际renderer可见对应执行记录。软件后端的像素结果不代表实体显卡性能、驱动稳定性或跨浏览器一致性。

继续核查与一级出处

基础背景见展会软件的可靠性三件套：崩溃自恢复、超时回待机、全屏锁定。上下文资源重建后，还要重新建立正确的光栅视口，可继续用Canvas 拉大后 WebGL 只画左下角，怎样同步 viewport 与 drawingBuffer取证；相关工程入口在专题与产品对接说明。

• WebGL上下文丢失和恢复规则；扩展可用性依实现：2026-10-24已联网读取一级来源；WebGL 1.0.3，2014-10-27；不把latest编辑草案当定稿。