把 Electron 的 Sparkle 更新器抽成库：bug 都住在边界上
内容提要
本文介绍作者将自用的 Electron 应用更新方案抽成开源库 electron-sparkle-updater 的过程。作者选择 Sparkle 而非 Squirrel，因其支持 ad-hoc 签名、原生体验和增量更新。文章重点分享开发中遇到的坑：npm 隐式构建、npx 依赖解析、rpath 路径错误、universal 构建缺陷及 CI 密钥清理问题，强调测试需覆盖真实环境，失败路径设计至关重要。
延伸解读
边界上的 bug：测试覆盖不到的盲区
作者强调，119 个测试用例全部通过，但真正的 bug 都出现在测试射程之外，比如 npm 的隐式构建、npx 的依赖解析、rpath 路径变化、universal 构建的中间产物被清理等。这些问题的共同点是它们依赖于外部环境或工具链的默认行为，而单测往往用 stub 模拟，无法覆盖真实场景。这提醒开发者，测试不仅要验证逻辑正确，还要尽可能模拟真实环境，尤其是涉及构建、打包和依赖解析的环节。
npm 隐式构建的陷阱与对策
npm 在安装包含 binding.gyp 的包时会自动执行 node-gyp rebuild，即使没有声明 install 脚本。这对 Electron 原生模块是灾难，因为自动构建使用宿主 Node 的 ABI，与 Electron 不兼容。作者通过添加一个 no-op 的 install 脚本来覆盖隐式构建，并将真正的构建命令显式化。这个看似无用的脚本实际上是为了防止 npm 的默认行为，README 中必须解释清楚，否则容易被好心人“修复”。
路径与依赖：环境变化带来的隐性风险
两个关键问题都源于对环境的隐性依赖：一是 npx 在消费者环境中可能找不到本地依赖，转而从 registry 拉取未固定版本；二是 rpath 的相对路径在库被安装到更深目录后失效，但被 Electron 自身的 rpath 兜底，导致问题不易察觉。作者强调，所有工具和路径都应从自身依赖图解析，并显式验证真实产物，而不是依赖环境提供的便利。
CI 安全：失败路径与密钥清理
发版流水线中，私钥处理虽谨慎，但 set -euo pipefail 导致 generate_appcast 失败时清理代码不会执行，私钥残留。作者改用 trap 确保清理始终运行，并修复了输入注入问题。这提醒开发者，CI 脚本不仅要考虑成功路径，更要设计失败时的安全退出，确保敏感信息不泄露。
Q&A
为什么作者选择 Sparkle 而不是 Squirrel 作为 Electron 应用的更新方案？
作者选择 Sparkle 是因为它支持 ad-hoc 签名，不需要付费的 Developer ID，同时提供原生体验和增量更新。
electron-sparkle-updater 是什么？
electron-sparkle-updater 是作者从自己的交易终端中抽出的开源库，用于在 Electron 应用中集成 Sparkle 更新器，支持增量更新和原生体验。
npm 隐式构建问题是什么？如何解决？
npm 在安装包时，如果存在 binding.gyp，会自动执行 node-gyp rebuild，但使用的是宿主 Node 的 ABI，与 Electron 不兼容。解决方法是添加一个 no-op 的 install 脚本，阻止隐式构建，并将真正的构建命令显式提供给用户。
为什么 npx node-gyp 在消费者环境中会失败？如何修复？
因为 node-gyp 放在 devDependencies 中，消费者安装时不会安装 devDependencies，导致 npx 找不到本地 node-gyp，只能从 registry 拉取，可能版本不受控或离线失败。修复方法是将 node-gyp 移到 dependencies，并通过 createRequire 从自己的依赖图中解析入口脚本，避免依赖 PATH。
rpath 路径错误是如何产生的？为什么打包后应用仍能正常运行？
rpath 路径错误是因为从原 app 复制 binding.gyp 时，路径深度未调整，导致 addon 无法找到 Frameworks。但应用仍能运行是因为 Electron 主执行档自带的 @executable_path/../Frameworks 兜底了。修复方法是更新 rpath 路径并验证。
universal 构建功能为什么是坏的？如何修复？
universal 构建功能坏在中间产物存放在 build/ 目录下，而 node-gyp rebuild 会先 clean（删除 build/），导致 lipo 找不到第一个输入。修复方法是将中间产物移到 build/ 外，并添加断言防止回归。
CI 中私钥清理失败的风险是什么？如何改进？
私钥清理失败的风险是私钥残留在 runner 上。改进方法是使用 trap 确保清理逻辑在脚本退出时执行，并避免在清理代码中使用 set -e 导致清理中断。
为什么测试用例全绿但功能仍然损坏？
因为测试用例使用了注入的 spawn stub，只记录参数而不真正执行，导致无法发现 node-gyp 的 clean 行为。真实环境中的问题需要集成测试或真实构建来验证。
