这次排查的起点，是一个版本回归：见字工作台 Windows 端 1.0.1 能正常安装、启动；升级到 1.0.2 后，安装器先后出现旧程序无法关闭、无法覆盖卸载程序、运行数据目录无法创建等提示。即使安装完成，双击应用仍报主进程错误。这些现象跨了安装和启动环节，一开始很难判断是不是同一个故障，也容易先怀疑 Electron 或最近的包版本升级。
我花了一整天追下来，真正有用的不是再猜一个版本，而是把安装、权限、启动和 CI 验证拆成几段，逐段找证据。
这次排查里，文件安全属性出现了 CodexSandboxUsers 这一组。移除后重新打包，安装和启动都恢复正常。这是我们在这台机器、这批构建产物上观察到的强线索，不是 Windows 的通用结论。另一个结果是：原来 CI 只证明"能构建"，现在我已经把真实安装和启动检查接进 Windows 流程，安装器 smoke 与 verify 均通过。
第一次转向：报错不同，先别认定是同一个问题
屏幕先后出现过"见字无法关闭""不能覆盖卸载程序"和"运行数据目录无法创建"。它们看起来都像安装器坏了，但实际落在不同阶段：一个发生在旧程序文件替换时，一个发生在目录选择和创建时。重启电脑、换空目录、改安装路径都没有消掉提示。
我们因此先把故障拆开记录：卸载程序是否还被占用？目录到底有没有创建出来？安装程序是否能在目标位置写入？这些问题不能用同一条"权限不足"概括。
第二次转向：写入失败，也可能是探针写错了路径
PowerShell 的第一次写入测试报"找不到路径的一部分"。当时很容易把它理解成没有权限，回头看才发现：探针写入的目录本身并不存在。路径不存在和目录拒绝写入，是不同的失败原因。
补测父目录和新建临时目录后，Programs 基目录可以写入；再对比文件属性，才看到临时产物和项目目录中的 exe 安全组不同，其中包含 CodexSandboxUsers。移除这项后重新构建，安装包能装、程序也能打开。这个结果把排查方向从"是不是 Electron 一升级就坏了"，拉回到具体的构建产物和文件 ACL；但它仍只说明这台机器上的对照结果，不能单独解释此前每个症状。
第三次转向：CI 也可能在测错东西
我们给 GitHub Actions 增加了 Windows 安装 smoke：用 NSIS 静默安装，再启动已安装的程序，检查本地服务健康接口和 renderer-ready 状态。
第一轮 CI 在 120 秒超时处失败。后来从日志确认，安装本身约用了 244 秒；测试的时间上限太短，不等于安装器失败。把上限调到 300 秒后，下一轮又卡在服务探测：脚本假设能从固定日志路径读到随机端口。修正端口发现后，API 检查通过，renderer 日志位置和冷启动等待又暴露出测试脚本的假设。调整后，Windows 安装器 smoke 和 verify 最终通过。
下次打包，至少检查这五步
- 安装包生成：确认 CI 产出了目标 Windows 安装器。
- 静默安装完成：给安装留足真实时间，并检查安装器退出码。
- 已安装文件存在：检查主程序和卸载程序都落在预期目录。
- 本地服务健康：启动安装后的应用，确认健康接口返回成功。
- 界面握手完成：等待 renderer-ready 信号，而不只看进程还活着。
构建成功，只说明编译和打包命令结束；真实安装、服务启动、界面就绪，是另外几件事。每一关都应该有对应证据，失败时保留日志和进程信息。否则一个超时可能只是测试脚本没跟上真实环境，却被误判成产品故障。
这次最实用的收获，不是"Windows 权限总会出问题"，而是排障时要问清楚：我现在测的是哪一步，证据能证明什么，不能证明什么。
你们的 Windows 桌面 CI，目前检查到安装器退出，还是也会启动已安装程序并验证界面？