Anelo 的 Windows 安装包为什么不放在自己的官网上

Anelo 的 macOS 版是一个 1.3MB 的磁盘映像。它就放在官网上，和 HTML 挨着，谁下载都行，没人需要为它操心。

Windows 版不是这样。自包含包每个约 190MB，同时提供 x64 和 ARM64，意味着每次发布是 380MB 的安装包。

而官网当时在 Firebase Hosting 的免费档上，每天允许 360MB 的数据传输。

算术上就不成立，而且失败是无声的

一个人下载一次 Windows 安装包，就能把当天的额度全部用光。第二个来的人什么也拿不到。

比单纯宕机更麻烦的，是它发生时网站看起来的样子。HTML 照常加载——它本来就在缓存里。页面渲染完全正常。下载按钮就在那儿，样式对，位置对。它只是不工作。没有错误提示，没有状态页，收件箱里也不会多出一封告警。从外面看，这就是一个运行良好、只是恰好没人下载的网站。

这种问题你往往几周后才知道，从某个以为是自己网络有毛病、然后就走开了的人那里。

每个文件该待在哪儿

所以两个平台的托管方式是刻意不同的：

• macOS 的 DMG → 放官网。 1.3MB 几乎不占成本，放在这里也让发布脚本能一步完成"部署应用 + 更新下载链接"。
• Windows 的安装包 → 放 GitHub Releases。 大体积二进制正是发布托管被设计出来要处理的东西，而且没有每日上限可撞。

真正有用的结论不是"静态托管不适合放下载"。而是：托管应该按文件选，而不是按项目选。 一个 1.3MB 的文件和一个 190MB 的文件，除了都躺在下载按钮后面之外几乎没有共同点，给它们选同一个托管，必然有一个待错了地方。

发布这些包的流水线

Windows 的发布由推送 win-vX.Y.Z 标签触发，而且单独用一个工作流文件，不和普通的 push 流水线共用。

这个拆分是刻意的。常规流水线按改动路径过滤，而标签推送根本没有"改了哪些文件"这回事——两者组合起来的行为很难预测，也很容易出错。发布是低频、高后果的操作，不该和每次提交都跑的东西共用触发条件。

流水线也拒绝发布"半个版本"。每个架构各产出一份只含自己那个包的 SHA256SUMS.txt，发布前合并。如果资产数量不是正好两个，宁可让发布失败，也不发一个架构、把另一个架构留在缺失状态。

关于未签名这件事

两个 Windows 版本目前都没有签名，发布说明里也直接写了。由此带来两件事：

SmartScreen 会全屏拦截。部分杀毒软件会报警——而这在任何有意义的层面上都不算误报。Anelo 安装了全局键盘钩子，并向其他应用合成按键。从结构上看，这就是键盘记录器在做的事。区别在于意图和数据的去向，而这两点，启发式扫描器都看不见。

在有签名之前，每次发布附带的 SHA256 校验和是你唯一能确认"拿到的就是构建出来的那个文件"的方式。这件事值得明说，而不是指望没人注意到那个警告。