对象存储生命周期降本：四步检查清单

对象存储按容量和请求计费，日志、备份、安装包如果一直停在标准存储，账单会随着时间线性上涨。生命周期规则的作用，是按前缀和天数把对象自动转到更便宜的存储类别，或在确认无用后删除。下面是一份上线前可以逐项核对的检查清单，不依赖某一家控制台的按钮位置。

第一步，先按前缀把桶里的数据分成三类。第一类是正在被业务读取的热数据，例如最近 7 天的应用日志、正在分发的安装包，应留在标准存储。第二类是只为审计或回溯保留的温数据，例如 30 天以前的访问日志、构建产物，可以转到低频或归档。第三类是明确过期的临时文件，例如超过保留期的调试包、失败任务留下的中间对象，应设置到期删除。规则按前缀匹配，所以桶内目录要先约定清楚，不要把热数据和归档数据混在同一个前缀下。

第二步，给每一条规则写清“转换天数”和“删除天数”，并且让删除天数大于转换天数。常见写法是：前缀 logs/ 在第 30 天转到低频，第 180 天删除；前缀 backup/ 在第 7 天转到归档，不自动删除。天数从对象最后修改时间起算，覆盖写会重置计时，这一点在滚动日志场景里要特别注意。

第三步，核对版本控制和未完成的分段上传。如果桶开了多版本，只给当前版本配规则，历史版本仍会继续计费，需要单独给非当前版本配置转换或过期。分段上传中断后留下的碎片不会出现在普通对象列表里，但会计入容量，建议增加一条清理未完成分段上传的规则，例如 7 天后中止。

第四步，上线后用一次小样本验证，而不是直接套到整桶。先建一个测试前缀，放入三个不同日期的小对象，把规则天数临时改短，等到转换或删除发生后再改回正式天数。同时看一次存储容量和请求次数：转换本身会产生读取和写入请求，极小文件如果频繁转换，节省的容量费可能抵不过请求费。大于数兆字节、且长期不被读取的对象，才是生命周期最划算的对象。

最后把规则、前缀、天数和负责人记在变更单里。存储降本不是一次配置就结束，新增业务前缀时要同步补规则，否则新目录会重新堆积在标准存储上。