Electron 39 软件离屏渲染第二张 PNG 丢失透明背景

离屏截图窗口设置了 transparent: true，第一张 PNG 透明正常；复用这个窗口再次加载页面，导出的背景却变成黑色或白色。若应用关闭了硬件加速，可以先对照 Electron 39.1.2 的软件离屏渲染路径。

已确认的环境是 Linux x64、webPreferences.offscreen: true，并在启动阶段调用了 app.disableHardwareAcceleration()。同一形态在 38.6.0 正常、39.1.2 异常。这个范围不能直接推广成 Electron 39 的所有截图都会丢 alpha，也不能仅凭页面看起来黑了就认定 PNG 没有透明通道。

先区分页面底色与窗口复用

保留相同页面、窗口尺寸和渲染方式，分别比较新窗口的第一次输出、同一窗口第二次输出，以及另建窗口的第一次输出。页面应有明确应当透明的区域，且 CSS 没有给它铺上不透明底色。

把 PNG 放在深色查看器上，透明区域也可能显示成黑色。应使用现有图像工具读取已知透明位置的 alpha，确认是像素真的变为不透明，还是查看器的背景不同。页面加载完成也不等于字体、图片和最终布局都已稳定；比较时沿用同一套资源就绪条件。

若只有复用窗口的后续输出丢 alpha，而新窗口的首次输出正常，就有理由针对窗口生命周期处理。若第一张也不透明，先查网页背景、输出编码和当前渲染模式，不能直接套用这个办法。

暂时让每个导出任务使用独立窗口

受影响环境可以把原有截图流程包在单次窗口生命周期中。下面只展示生命周期，capture 是应用已有的、会等待页面与资源就绪并返回最终结果的截图函数：

async function withCaptureWindow(capture) {
  const win = new BrowserWindow({
    show: false,
    transparent: true,
    webPreferences: { offscreen: true },
  });

  try {
    return await capture(win);
  } finally {
    if (!win.isDestroyed()) win.destroy();
  }
}

这段位于 Electron 主进程，在 app.whenReady() 之后调用，BrowserWindow 沿用项目现有导入。capture 必须等实际取图结束才 resolve，不能在 loadURL() 尚未完成或仍有异步取图时提前返回，否则 finally 会过早销毁窗口。

destroy() 会强制关闭窗口，不等待页面的 unload 或 beforeunload；它只适合这里由导出任务持有、取图结束即可销毁的窗口，不能直接套在还有用户编辑状态的交互窗口上。保留原窗口需要的安全配置、预加载脚本和尺寸，只调整复用策略。每个任务新建窗口会增加创建和资源管理负担，应限制并发，并在失败时同样释放窗口；不要用无限堆积窗口换取首次截图正常。

软件路径与 GPU 路径分别验收

关闭硬件加速会选择软件输出设备。直接删除 disableHardwareAcceleration() 会改变渲染路径，在没有可用 GPU 的服务器上尤其不能当作无条件修复。若准备改用 GPU，应独立核对部署环境与原截图功能，而不是只看本机能生成一张 PNG。

每任务独立窗口是上述组合的规避，尚不能当作底层缺陷已经修复的保证。评估受支持的新版本时，应带上原来两次加载的输入，连续导出并检查透明像素、正文内容和窗口释放。38.6.0 只是历史对照，不应为了绕过截图问题默认退回旧版运行时。