工业工控机场景下的 Electron Win7 兼容与原生安装器实践

在很多人的印象里，Windows 7 已经是一个退出历史舞台的旧操作系统。但在工业制造、陶瓷加工和特种设备控制的工控机现场，成千上万台设备由于硬件板卡驱动限制或严格的封闭隔离要求，仍然长期停留在无网络补丁、无系统更新的纯净 Windows 7 SP1 甚至是各种深度精简的 Ghost 系统上。

当现代桌面客户端必须走进这些工业现场时，技术团队面临的往往是极其残酷的兼容深水区：

现代 Chromium 与 Electron 早已在主干中彻底放弃了 Windows 7，直接运行只会遇到“不是有效的 Win32 应用程序”或双击无响应；
早期试图通过 VxKex 等第三方开源兼容补丁强行支撑 Electron 39，但在真实工控现场频繁遭遇显卡驱动崩溃、输入法死锁以及不可预期的静默崩溃；
采用 NSIS 打包的传统安装程序在面对提权补丁安装、离线环境依赖修复时表现脆弱，进度条长时间卡死，一旦遇到错误便直接退出。

为了彻底摆脱第三方兼容层的不确定性，我们在产品线治理上做出了关键决断：将 Win7/8/8.1 彻底拆解为独立的 legacy 双轨产品线，同时自研一套纯原生、具备深水修复能力的 C++ 安装器体系。

双轨分流：同一份源码下的双版本运行时

在架构层面，与其靠 Hack 兼容层去在 Win7 上苟延残喘运行高版本 Chromium，不如正视运行时的生命周期。

我们对桌面端的分发路线进行了双轨切分：

Modern 产品线：面向 Windows 10 及以上系统，基于现代标准的 Electron 39 构建，充分利用前沿图形加速与最新 V8 特性；
Legacy 产品线：面向 Windows 7 / 8 / 8.1 工业设备，钉死在官方支持 Win7 的最后一个稳定大版本——Electron 22.3.27（对应 Node 16.20 与 Chromium 108）。

两条产品线共用一套上层业务源码。为了保证 Legacy 线在低版本 Node 与 Chromium 环境下稳定构建，我们在工程层收敛了一套编译转换方案：

主进程与 Preload 脚本输出由现代 ESM 降级编译为 CJS；
构建目标（target）显式对齐 node16 与 chrome108；
将依赖 Node 高版本内置的 node:sqlite 抽象平替为跨平台的 better-sqlite3；
针对 Electron 22 缺失的 protocol.handle 与 net.fetch API，封装统一的适配网关，自动降级至稳定可靠的 registerBufferProtocol。

经过实机测算，React 19、PixiJS 8、Babylon 8、WASM SIMD 以及多线程 Worker 在 Chromium 108 上均可稳定运行。双轨策略不仅保住了工控机的绝对稳定性，更彻底避免了对不可控第三方注入工具的依赖。

安装程序重构：为什么彻底抛弃 NSIS 转向自研原生实现

在早期方案中，我们基于 NSIS 实现了安装包。但在实际分发和自动化补丁安装场景下，NSIS 迅速暴露出三处无法逾越的技术瓶颈：

双进程向导割裂与界面假死：NSIS 脚本无法原生嵌入复杂的 C++ 检测引擎。为了安装系统补丁，必须通过 ExecWait 启动另一个无界面的隐藏提权进程。在漫长的补丁解压和写入过程中，主向导窗口完全失去响应，进度条长时间定格，用户极易误判为程序卡死而强制关机。
逻辑重复与版本判定漂移：NSIS 拥有自己独立的脚本语法，版本比较和目录扫描不得不重写一份。结果 NSIS 脚本只比较了主版本号，无法正确处理 beta.1 与 beta.2 这类复杂的 SemVer 预发布标签，导致用户覆盖安装时旧预览版目录未被正确替换。
完成页时序竞态：NSIS 的 .onInstSuccess 回调在完成页面绘制后才触发，而用户如果手速极快点击了“立即启动”，启动器拉起与后台提权助手写入会撞车，产生严重的并发读写冲突。

为此，我们彻底舍弃了 NSIS，采用 C++ (MSVC) + 静态链接 CRT (/MT) 自研了专用的单可执行文件安装器 CeraForgeSetup.exe。

下图展示了自研安装器采用的单窗口两阶段提权架构：

安装器两阶段提权架构.chart

整个安装器具备极其清晰的执行边界：

单窗口不闪烁：非提权的父进程始终唯一持有整个向导窗口，负责全部 UI 渲染与用户交互；
自包含重入与管道回传：当进入系统级组件和补丁安装阶段时，安装器通过 ShellExecuteEx (runas) 以 /elevated-phase 参数拉起自身副本。提权子进程完全没有窗口，它通过一条本地命名管道（Named Pipe）以精简的行协议向父进程实时同步每一个子步骤百分比与当前动作文案：
```
P\t68\t正在配置 Windows 7 安全更新 (KB4474419)...
```
单进度条平滑过度：两条阶段的数据在同一个向导界面中平滑汇聚，彻底消除了闪烁与假死；只有两阶段完全执行闭环后，完成页面才会浮现。

在打包形态上，安装器采用 Stub + Overlay 尾部追加架构：编译产物本身仅为一个约 200KB 的原生引导 Stub；发布流水线将应用压缩包（与无感更新包完全复用同一份字节）、Win7 前置补丁载荷直接流式追加到 Stub 的文件末尾，最后在文件最尾部写入自研的条目索引表。安装器启动后直接读取自身的 PE 头部定位安全目录，以内存流的方式解析尾部载荷，内嵌手写实现的 RFC 1951 Raw DEFLATE 解码器，整个过程零外部依赖、零临时垃圾文件。

实机攻坚：工控机深度兼容踩坑矩阵

在完全未联网、甚至多年未打过任何补丁的 Windows 7 SP1 工控机上，真正让程序瘫痪的往往不是应用本身的代码，而是千奇百怪的底层系统故障。

下图直观汇总了我们在现场遇到并逐一攻克的深水兼容矩阵：

Win7兼容攻坚矩阵.chart

1. 补丁安装失败与退避三层降级（0x80240037）

运行现代 Web 技术栈必须依赖微软的 SHA-2 代码签名补丁（KB4474419）以及服务堆栈更新（KB4490628）。需要特别注意的是：KB4490628 必须严格先于 KB4474419 安装，一旦顺序颠倒，系统安装器会发生静默死锁。

在部分 Ghost 镜像和工业主机上，微软官方的 wusa.exe 会频繁抛出 0x80240037 错误（提示补丁不适用于当前计算机）。经过逆向分析，这往往是由于 Windows Update 服务缓存混乱导致的假性拒绝。

针对该问题，原生引擎实现了一套三层退避安装管线：

首先尝试通过标准 wusa.exe /quiet /norestart 静默安装；
若检测到适用性错误，引擎自动调用 expand.exe 将 MSU 拆解为 CAB 载荷包，随后直接调用底层的硬件服务引擎：
```
dism.exe /online /add-package /packagepath:<CAB路径> /quiet /norestart
```
若 DISM 依然不可用，继续降级调用老旧系统的包管理器 pkgmgr.exe 进行暴力注入。

同时，针对许多工控精简系统将系统服务全部禁用的情况，引擎在执行补丁前会临时将被禁用的 wuauserv（Windows Update）、TrustedInstaller（Windows Modules Installer）以及 CryptSvc（加密服务）提权切换为“手动启动”，待补丁部署完毕后再精确复原原始状态。

2. 时钟倒流引发的 HTTPS 鸡生蛋死锁

现场遇到的另一个离奇问题是：补丁和根证书全部提示安装成功，但应用尝试连接服务端时依然顽固报错 ERR_CERT_DATE_INVALID。

经过诊断，现场大部分老旧工控机主板上的 CMOS 纽扣电池早已电量耗尽，设备一旦断电重启，BIOS 系统时间就会瞬间倒流到 2009 年。而现代服务端的 SSL 证书均签署于近年来，Windows 证书体系直接将这些证书判定为“尚未生效”，彻底阻断 HTTPS 连接。

这是一个典型的“鸡生蛋”悖论：因为时间不对，所以无法发起 HTTPS 通信；而因为无法建立安全连接，应用又无法通过常规网络接口获取标准时间。

解法：启动器在冷启动阶段，直接向多个高可用公用 Web 节点发起极其轻量的明文 HTTP HEAD 请求，解析 HTTP 响应头中的 Date 字段：

启动器收集多路返回时间，采用中位数算法进行多方投票仲裁，彻底防范单点故障或局部 DNS 劫持；
若本地系统时间与网络仲裁时间的偏差超过 10 分钟，启动器立即唤起提权助手执行系统时间同步（SetSystemTime），随后安全拉起主应用。

3. 根证书链缺失与 Node.js 独立证书库

工业主机长期断网，系统的根证书存储区缺少 ISRG Root X1 与 ISRG Root X2 现代根证书。

引擎在提权阶段通过 CryptoAPI 的 CertAddCertificateContextToStore 将根证书注入系统 ROOT 存储区，并以 certutil 和组策略存储作为两级兜底。

更隐蔽的坑在于：Electron 22 底层的 node:https 默认并不主动读取 Windows 操作系统的本地根证书存储。即便系统层面已经信任，Node 侧的网络请求依然会抛出 UNABLE_TO_VERIFY_LEAF_SIGNATURE。

我们在客户端网络层中做了显式对齐：在主进程启动前，将内嵌的 ISRG 根证书动态追加到运行时信任列表中：

import https from 'node:https';
import { ISRG_ROOT_X1, ISRG_ROOT_X2 } from './certs';

https.globalAgent.options.ca = [
  ...tls.rootCertificates,
  ISRG_ROOT_X1,
  ISRG_ROOT_X2,
];

只追加、不缩小，彻底打通全链路加密通道。

卸载与清理：系统级组件的优雅退场

一个优秀的安装器不仅要能进，还要能干干净净地退。

由于我们的架构将客户端分为了“用户可写安装根”和“系统级 Program Files 目录”，在卸载时必须面对跨权限的边界处理：

系统组件默认保留：系统级目录下的缩略图 DLL 和提权助手属于整机资产（可能有同一设备上的其他用户共用），因此卸载向导默认仅删除当前用户的安装根，保留系统组件；用户亦可主动勾选“同时移除系统组件（需要管理员权限）”；
资源管理器占用解耦：缩略图 Shell 扩展 DLL 经常被 Windows 资源管理器 explorer.exe 长期占用加锁。如果直接调用 MoveFileEx 的 MOVEFILE_DELAY_UNTIL_REBOOT，当用户在重启电脑前重新安装软件时，新装的文件会在重启后被系统静默误删。正确的做法是：先将其重命名让出原文件名（如 CfrThumb.dll.pending-delete），再对这个废弃文件登记重启后删除。如此一来，即使用户立即重新安装，也不会与系统待删除队列发生路径碰撞。