十月补记：本文于 2026 年 10 月 25 日整理并首次发布，页面日期用于归档对应时期的实践；后续修整一并写入。产品开放范围以文中链接的公开说明为准。
一个很容易让人想买新硬盘的提示，是“大文件都删了，怎么还说额度不够”。
整理个人项目的软件包存储时，我发现“存储额度”并不总是在说同一个东西。文件占多少字节、系统里保留多少条记录、内容留多久，以及磁盘实际还剩多少空间，可能分别受限。
如果没有先分清是哪一种，扩容也许只解决了旁边的问题。这篇用陪练和轻联交付工作的通用经验说明区别，不公开生产存储参数。
文件不在了，记录为什么还在#
一份软件包除了文件本身，还可能对应一条说明：它来自哪次构建、内容摘要是什么、当时交给了谁、后续是否被替换。
文件过期后，可以按规则清理大块内容；说明记录却可能需要继续保留，方便排查过去的安装问题。于是“少了很多字节”和“少了很多记录”不一定一起发生。
这就像把一批货交付完，仓库空出了位置，账本上仍然要保留这笔交付。账本有自己的管理上限，不能只盯着货架还有多大。
我现在先看拒绝属于哪一类#
| 限制 | 常见表现 | 要核对的事 |
|---|---|---|
| 内容大小 | 新的大文件放不进去 | 实际字节、保留策略、现有占用 |
| 记录数量 | 很小的新对象也无法登记 | 统计口径、长期记录预算 |
| 保留期限 | 文件按期变成不可读取 | 谁负责清理、哪些证据仍保留 |
| 物理资源 | 整个磁盘或底层资源不足 | 真实空闲量与运行状态 |
错误提示最好能回到这几种具体原因。用户不需要看到内部配置，但维护者需要知道该调整哪一项，避免一次失败就在所有方向同时加预算。
不为了腾额度，把回执也一起抹掉#
过去的文件和过去发生的事实，有不同生命周期。只要记录仍承担审计或恢复作用，就不能因为它们占数量而无差别删除。
我更倾向先核对增长来源：是否重复登记、是否有不需要的临时记录、保留规则是否符合实际使用，再评估合理的预算。需要调整配置时只改受影响的项，并确认原有数据和拒绝规则仍然有效。
这一步也有成本。长期保留的记录需要维护；放宽数量以后，要能观察后续增长，不能把上限调大就当作以后不会再遇到问题。
给小项目准备一张增长表#
不必一开始就做复杂预测。先记录每天产生几份包、平均多大、保留多久、会留下几条长期记录，再观察几周实际变化。
如果内容每天产生、长期记录却永不减少，就应该分别计算未来的增长。一个平均体积数字，回答不了另一个维度何时受限。
这类排查先省的是错误行动：少一次无效重跑，少一次没有依据的扩容决定。是否真的避免了一笔费用，还需要当时的方案比较和账单，不能因为后来没买硬盘就随口记成已经省钱。