十月补记：本文于 2026 年 10 月 25 日整理并首次发布，页面日期用于归档对应时期的实践；后续修整一并写入。产品开放范围以文中链接的公开说明为准。
最让人困惑的一类失败，是软件已经做出来了，发布流程最后还是显示红色。
整理陪练的 Mac 交付流程时，我就碰到了这样的区别：编译和签名可以成功，负责保存安装包的环节却可能因为存储额度而失败。此时继续改代码，或者再完整打一次包，并没有回答真正的问题。
陪练目前仍是签名自用包，公开下载和正式在线更新尚未启用。这篇讲的是交付链路里的成本与保存问题，不把流程建设写成已经开放给所有人下载。
自己的电脑在跑，不等于所有环节都归自己#
自动打包通常有几种不同资源：执行构建的电脑、保存结果的产物空间、下次加速用的缓存，还有把结果交给下一环节的传输。
把构建搬到自己的电脑，只改变了第一部分。后续如果仍把软件包上传到平台保存，保存时间、占用量和账号额度仍要单独看。GitHub 的计费说明也把运行与存储分别列出。
遇到失败，我先看它发生在哪里：还没编完、签名失败、上传被拒，还是上传后读不到文件。相同的“流水线失败”，可能需要完全不同的处理。
| 要查的资源 | 先回答的问题 |
|---|---|
| 执行电脑 | 是在排队，还是实际编译太久？ |
| 产物存储 | 空间、保留期或其他配额是否触顶？ |
| 缓存 | 是否能重建，是否真的带来复用？ |
| 传输 | 是暂时网络失败，还是文件本身被拒绝？ |
可以自己保存，但别只算磁盘价格#
自有存储能让我更明确地控制保存什么、留多久、谁能读。它也会把一些责任交回来：磁盘满了谁处理，网络断了怎样恢复，旧版本留几份，文件是不是完整，账号撤销后入口还能不能继续用。
如果为了省一笔平台存储费用，增加了很多人工维护，又没有恢复路径，最终未必便宜。我会把每月费用和维护时间分开记，避免拿“没新增扣款”当成全部成本。
我把“保存成功”拆成几个可核对的结果#
第一是文件确实写完，而不是只建了一个名字。第二是读取到的字节与预期一致，可以用摘要核对。第三是来源能追溯到对应代码和构建。最后才是下一环节真的取得了这份结果。
这些信息可以留在内部回执里，对外文章不需要给出存储地址、部署账号或读取凭据。读者需要复用的是核对方法，不是我的运行参数。
安装包也应和缓存分开。缓存通常能重新生成；一份已经交付给用户的签名包，关系到回溯、支持和恢复，不适合因为文件大就随手删掉唯一副本。
扩容之前，我会先算这张账#
一份包多大、一天产生几份、保留几天、会被读几次、失败后是否重复传输，先把这几项列出来。还要看平台剩余额度，以及现有存储是否已经有可靠的维护和备份。
如果只是临时积压，调整合理的保留期也许足够；如果是每天都会持续产生的大文件，再讨论长期方案。既没有实际规模，也没有账单比较时，先定位受限项比先购买资源更有帮助。
这次我沉淀下来的是一张成本地图：电脑负责跑，存储负责留，网络负责送，每一项都要能说明成功和失败。方案有没有省到钱，最后仍要回到同一口径的真实账单。