基于最后一次修改时间的生命周期规则
更新时间：2025-08-14
基础生命周期管理文件生效策略支持两种方式，分别为基于最后一次修改时间(基于上传时间记录 )与最近一次访问时间(基于访问时间记录)配置，配置基于文件最后一次修改时间（lastModified）的生命周期规则，定期将Object从热存储类型转为冷存储类型，或者删除Object，以降低存储成本，
基于最后一次修改时间适合业务数据冷热周期明确的场景，例如某医疗机构的医疗数据，上传到BOS后半年内少量访问，半年后基本不在访问，将上传将已上传180天的医疗档案转为冷存储。如果您希望BOS自动监测数据的访问模式并识别冷数据，然后将识别出来的冷数据进行存储类型的转换，从而达到数据的冷热分层存储，最终降低存储成本，您需要配置基于最后一次访问时间的生命周期规则。
使用限制
生命周期规则目前仅支持根据前缀和标签进行匹配，前缀与标签不支持通配符匹配
注意事项
- 采用SDK、API 方式设置需要注意PutBucketLifecycle为覆盖语义。例如，某个Bucket已配置了生命周期规则Rule01，您需要在Rule1基础上继续追加生命周期规则Rule2，您需要执行以下操作：
- 调用GetBucketLifecycle接口获取当前生命周期规则配置Rule01。
- 在Rule01基础上叠加Rule02。
- 调用PutBucketLifecycle接口更新生命周期规则为Rule01+Rule02。
更多注意事项参见基础生命周期管理注意事项说明。
费用说明
关于通过生命周期规则转换Object存储类型或者删除Object必会产生转化与删除对应的请求费用，如果规则配置了删除或者转化存储类型且不满足规定的存储最小时长要求，还会产生最小存储周期费用。规则配置时请特别注意删除或者转化文件时需满足对应存储类型的最小存储周期要求，否则会产生未到达最少存储周期费用。
组成元素
指定生效范围：
- 按前缀匹配：按指定前缀匹配Object和碎片。可创建多条规则匹配不同的前缀，前缀不能重复。前缀的命名规范与Object命名规范相同。
- 按标签匹配：按指定标签的Key和Value匹配Object。单条规则可配置多个标签，仅当Object包含所有标签时执行生命周期规则。
基础生命周期规则设置的标签与执行说明： 例如基础生命周期规则设置的标签为a:1,b:2
| Object携带的标签 | 生命周期规则是否作用于该Object |
|---|---|
| a:1 | 否 |
| a:1,b:3 | 否 |
| a:1,b:2 | 是 |
| a;1,b:2,c:3 | 是 |
说明 标签匹配规则不作用于碎片。
- 按前缀+标签匹配：按指定前缀和标签的筛选条件匹配对象。
- 配置到整个Bucket：匹配整个Bucket内的所有Object和碎片。
- NOT元素：如果您希望按照生命周期规则对与前缀和标签匹配的Object进行相应处理的同时，跳过不需要处理的Object，您可以通过NOT元素对不需要处理的Object指定前缀和标签。
Object的过期时间及操作
- 过期天数：指定一个过期天数为N，为相对时间，在Object最后修改时间N天后过期（到期），并执行对应的操作，Object操作可以是转化存储类型或者删除。
- 过期日期：指定一个过期日期，为绝对时间，最后修改时间在该日期之前的Object全部过期（到期），并执行指定的操作，Object操作可以是转化存储类型或者删除。
注意以上说明适用于未开启版本控制的存储桶
碎片（Part）的过期时间及操作
- 过期天数：可指定一个过期天数N，文件碎片会在其最后修改时间的N天后被删除。
操作方式
相关API
以上操作方式底层基于API实现，如果您的程序自定义要求较高，您可以直接发起REST API请求。直接发起REST API请求需要手动编写代码计算签名。更多信息，请参见PutBucketLifecycle。