做对象存储最爽的一点是，不用再操心磁盘什么时候写满；最可怕的一点也是同一个：桶里的东西什么时候没了，很多时候不是你决定的，是一条生命周期规则替你决定的。我们公司的产品图原本放在 OSS 上，运营同事的图存了三个月，突然有一天后台只剩一堆 404，翻回控制台一看，那条三个月前随手加的“冷数据转储”规则，把已经转过档的旧对象直接标成了删除状态。当时我才明白，OSS 的生命周期规则不是“省钱开关”，它是一把默认架在脖子上的刀。
如果你也在做对象存储、想自己搭一套图床或者备份归档，把数据放到一台配置合适的大硬盘机器上跑起来更省事，可以先看看这两家的方案：terabix（服务器与主机，RAID-10 NVMe Gen4 存储）、itldc（全球云服务器，NVMe VDS / HD VDS 存储）
OSS 的生命周期规则由几个动作组成：转储到归档/冷存储、删除过期对象、删除未完成的分片上传、终止未完成的分片上传、按天数删除某一类前缀的对象。规则本身在控制台看起来很朴素，就是几行表单。但它的杀伤力在于：动作一旦命中对象，控制台里那条规则的“已生效天数”会静静往前爬，桶里的对象数量以肉眼可见的速度往下掉，而你不会有任何弹窗提示。
更要命的是删除的顺序问题。默认配置下，存储类型已经转成归档之后，对象已经不在标准存储层了，你再去捞它，需要先把它从归档层取回来，标准取回需要几分钟到几小时不等，深度取回更久。这个“先删后取回”的动作，如果发生在合规或者审计上要求的场景里，等于把证据链直接烧断了。
我最初的规则写得很天真：图片文件，30 天后转储到归档存储。心里想的是“又便宜又不丢，挺好”。结果第一次转储跑完，两周后有个运营同事来要三月份的活动原图，我在归档层里找到了那个对象，点了取回，提示 404原来规则里我勾的其实是“对符合生命周期的对象执行删除”，转储只是第一步，删是第二步。我自己写的规则，把自己的文件删了。
这里的关键认知是：转储和删除是两个独立动作，你可以在同一条规则里都勾上，也可以只勾一个。很多人默认勾了转储就完事了，实际上如果下面的“删除”那一栏也打了勾，且天数填得一样，对象在转储的下一个生命周期周期就被清理掉了。要留档，删除动作就别勾。
阿里云 OSS 的版本控制是一个开关，打开之后每次覆盖上传都会保留旧版本，删除操作会打上一个删除标记（Delete Marker），对象看起来像没了，其实还能通过版本号取回来。没开版本控制的话，删除动作是立即且不可逆的没有后悔药，没有“回收站”，也没有 7 天之类的缓冲期。
我的教训是：任何要往桶里跑的自动化脚本、任何交给运营同事直接操作的目录，都应该先把版本控制打开。存储成本贵一点，换来的是“任何一次误删都能回到上一版”。如果你的桶里还有合规要求的文件，更稳妥的做法是额外加上 WORM 保留策略保留策略一旦开启，在保留期内连桶的持有者自己都删不掉对象，等于给数据上了一道物理锁。
生命周期规则可以按前缀筛对象。我最早那条规则的前缀写的是 images/，后来为了图省事，改成了 （空），也就是匹配桶里所有对象。改完的第二天早上，桶里的量直接掉了一大截不只是图片，还有用户上传的原始文件和自动生成的缩略图全被清掉了。空前缀是个非常危险的东西，它意味着这条规则对桶里每一个对象都生效，包括你三个月后才会用上的那些。
我的做法是：给不同业务线用不同的桶，规则只写在最细的路径前缀上，永远不要留空。如果非要一条规则管全桶，那就给规则加“当前版本号 + 最后修改时间”的条件，而不是无条件匹配。
按量付费最反直觉的一点在这里：对象删掉之后，如果被标记了“保留中”或者处于合规锁状态，存储费用还在继续算，而且有的计费项是只算不消的。更坑的是，删除操作本身在部分配置下会产生请求费用，短时间大量删除会产生大量请求，请求费用在小账期里看不出来，月底账单出来能让人愣一下。
另外还有一类容易被忽略的成本：归档存储的取回是收费的，而且分“标准取回”和“深度取回”两档，深度取回便宜但要等 12 小时左右。所以“把冷数据转成归档”这件事的前提是，你短期内真的不会再碰它。判断标准很简单：一年之内访问不到两次的数据，才适合转归档。
总结一下我现在的一套做法。第一，所有桶默认开版本控制，删除打标记而不是真删，定期（我设的是 30 天）用生命周期规则清理历史版本，这条清理规则是我唯一允许带删除动作的规则。第二，需要长期留存的文件单独放一个桶，挂 WORM 保留策略，保留期按业务要求写死，不给任何人手动删的余地。第三，转储归档规则只针对明确的前缀，且只勾转储不勾删除，天数设在 180 天以上，留足回溯窗口。
第四，上线前用一个跟生产同构的测试桶，把规则原样跑一遍，观察对象数量曲线，确认删掉的是你以为该删的那批，而不是别的桶的挂载路径写错。这种测试花不了一个小时，但能把一次事故换掉。
第五，桶的访问权限用 RAM 最小权限收敛，删除类操作单独授权。生命周期规则是后台任务，就算没有人手动点，权限也该按“删除是不可逆操作”来给。
对象存储的默认值，站在安全的角度看几乎都是“省钱优先”的：它默认你希望旧数据尽快消失，因为对你没用了。但对存储桶来说，真正麻烦的不是数据多，而是数据什么时候不该消失你说了不算。生命周期规则是一份长期有效的授权，你今天点的那个“30 天后转归档”，是在给三个月后的自己留一个坑。所以我现在每加一条规则，都会先问自己两个问题：这条规则命中了哪些对象我心里有没有数？如果它明天命中错了，我能不能救回来？答不上第一个就别加，答不上第二个就先去开版本控制。
数据便宜，误删贵。这行当久了，这句话应该刻在墙上。
