十月补记：本文于 2026 年 10 月 25 日整理并首次发布，页面日期用于归档对应时期的实践；后续修整一并写入。产品开放范围以文中链接的公开说明为准。
给 Mac 软件准备更新时，我发现“文件都在一起”很方便，也很容易带来重复传输。
一份完整交付材料里，可能同时有首次安装用的安装盘镜像，也有在线更新需要的压缩包，再加上说明和验证信息。完整保存有意义，但下一环节未必每次都需要把所有内容重新搬一遍。
这次经验来自陪练的 Mac 交付准备。它目前仍没有开放正式在线更新；这里介绍的是整理运输内容的工程做法，不是公开更新服务的使用承诺。
先问“谁要用”，再问“还能压多小”#
DMG 可以理解成 Mac 常见的安装盘镜像，适合让人下载、打开，再安装应用。ZIP 等压缩包则可能供更新程序消费。二者有时包含大部分相同的软件内容，但使用者和读取方式并不一样。
我先列了一张表：哪些是完整构建的原始结果，哪些只是给某个发布步骤的运输材料，哪些最终会开放下载。这样才知道能省掉的是哪一段搬运。
| 文件用途 | 应该保留什么判断 |
|---|---|
| 完整构建留档 | 能追溯到原始交付结果 |
| 首次安装 | 用户取得的是对应安装渠道的包 |
| 在线更新 | 更新程序取得其所需的完整内容 |
| 验证信息 | 内容和来源仍然可以核对 |
如果消费者只需要更新包，就不必让这一段运输顺便再携带一份完整安装镜像。关键是减少“这一段不需要的文件”，而不是把所有文件都删到最少。
精简以后，完整性要比以前更清楚#
这类改动最怕发生一件事：体积变小了，但谁也说不清少了什么。
我更愿意从原始结果生成一份明确的运输清单，只挑出当前消费者需要的成员。挑选规则要能检查，不能靠人工临时拖几个文件；也不让文件在生成以后被悄悄替换。
相关摘要和签名信息仍然需要按各自对象核验。原始包的摘要与精简后运输文件的摘要可能不同，不能把一个数字贴到另一份文件上就当作验证完成。
失败时，别顺便改变当前可用版本#
传输只是发布的一段。文件还没收齐、校验没通过，或者消费者没确认接收，就不应该提前把它宣布成“最新可用版本”。
我希望失败后留下的是清楚的位置：完整原始包还在，已经验证到哪一步能回查，旧的可用入口没有因为这次失败而失效。重试也应从合适的阶段接着做，而不是先删旧版再期待新版顺利。
这些原则可以用合成文件和故意中断的网络测试验证，不需要把真实用户的安装过程当成实验。
省下了什么，应该怎样记#
最直接的比较，是同一构建在这段链路上原本传多少字节、现在传多少、一天传几次。还要看原始留档是否仍占同样空间，以及接收端有没有新增处理成本。
没有这些数字，我可以说减少了重复搬运，不能顺口写成流量账单已经降低了多少。存储保留、网络传输和用户下载，是三笔可能不同的账。
下次看到一份大归档时，我会先问里面每样东西给谁用。很多时候，值得优化的是文件的去向，而不是再找一个压缩参数。