COS 生命周期规则上线前自检：前缀范围、转换顺序与过期删除的坑

背景

生命周期规则是 COS 降低存储成本最直接的手段，但它是“配置后由系统自动执行”的操作，尤其是过期删除，配错范围就是批量删数据。本文整理一份上线前自检流程，基于官方文档《配置生命周期》《生命周期配置元素》中的约束，具体参数以控制台和文档为准。

先确认几个事实

• 每个存储桶最多可添加 1000 条生命周期规则。
• 规则的执行时间以北京时间（GMT+8）为准，不是按你本地时区。
• Transition 用于存储类型转换，Expiration 用于过期删除；Days 是非负整数，最大 3650。
• 如果存储桶开启了版本控制，Transition 只对当前版本生效，历史版本需要单独的非当前版本规则。
• 存储桶如果从未启用过版本控制，Expiration 会永久删除对象，没有回收站。

第一步：把规则范围写窄

最常见事故是规则作用于整个存储桶。建议一条规则只覆盖一个明确前缀，例如在控制台填写：

# 规则名称: logs-archive
# 范围: 按前缀  logs/

先用 COSCLI 或控制台列出该前缀下的对象，确认里面没有不该被处理的内容：

# 按前缀统计对象，确认范围
coscli ls cos://examplebucket-1250000000/logs/ -r | tail -n 20

注意前缀 logs/ 和 logs 不同，后者会匹配 logs-backup/ 之类的对象。目录语义请带上结尾斜杠。

第二步：设计转换与过期的时间线

转换和删除要有先后，且过期时间必须大于转换时间。以日志为例：

<Rule>
  <ID>logs-archive</ID>
  <Filter><Prefix>logs/</Prefix></Filter>
  <Status>Enabled</Status>
  <Transition>
    <Days>30</Days>
    <StorageClass>STANDARD_IA</StorageClass>
  </Transition>
  <Transition>
    <Days>90</Days>
    <StorageClass>ARCHIVE</StorageClass>
  </Transition>
  <Expiration>
    <Days>365</Days>
  </Expiration>
</Rule>

这表示最后修改后 30 天转低频、90 天转归档、365 天删除。上线前核对：

• 低频、归档存储通常有最短存储时间和取回相关的计费与耗时，提前转换或删除可能产生额外费用；具体数值请看购买页和计费文档，不要凭印象设置。
• 归档对象需要先取回才能读取。如果业务偶尔要读 90 天前的日志，要把这个延迟算进去。

第三步：处理未完成的分块上传

大文件分块上传中断后，已上传的分块仍占用存储。生命周期里有清理未完成分块上传的配置项，可以在控制台同一页面添加，也可以单独建一条规则。建议对上传频繁的桶配置，天数保守一些（例如 7 天），避免误清理仍在进行的超长上传。具体字段名称以《生命周期配置元素》文档为准。

第四步：先灰度，再放大

1. 新建一个测试前缀，如 lifecycle-test/，放几个对象。
2. 规则范围只指向该前缀，天数设置为最小值。
3. 次日检查对象存储类型或是否被删除，确认符合预期。
4. 再把规则改成正式前缀和正式天数。

检查对象当前存储类型：

coscli ls cos://examplebucket-1250000000/lifecycle-test/ -r

上线检查清单

• 前缀带结尾斜杠，且已列出对象确认范围。
• 过期天数大于所有转换天数。
• 开启版本控制的桶，已单独考虑非当前版本和删除标记。
• 已确认低频/归档的最短存储时间与取回成本。
• 重要数据的桶已先灰度测试。
• 规则状态与命名可读，便于后续审计。

小结

生命周期规则的风险在于“静默执行”。把范围写窄、时间线排好、先灰度再放量，基本能避开大部分事故。过期删除类规则尤其建议在变更前让第二个人复核前缀与天数。