孤儿文件怎么清
季度对存储账单，附件表 8 万行，桶里躺着 9.3 万个对象，多出的 1.3 万个没人叫得出名字。客户的报障是反方向来的：附件列表里几条记录点开是 404。一边是桶里有、库里没有，一边是库里有、桶里没有，两边的差都不小。
结论一句话：孤儿文件靠定期对账加宽限期清，删任何东西之前先按成因分类——桶和附件表是两套各记各的账（直传架构里字节不经过应用服务器，这篇系列反复出现这句），没有一方天然是对的。
按成因分三类，对策不一样：
| 成因 | 特征 | 对策 |
|---|---|---|
| 传了没落库 | 对象上传成功但回调丢失、用户传一半放弃 | 宽限 7 天后删对象，库里本来就没有行 |
| 业务删了记录 | 行软删，桶里对象还在等回收 | 软删满 30 天删对象，回填 purged_at |
| 库里有、桶里没有 | 预览 404，多半是桶被手动清过或对象名改过 | 不清，进告警让人判断 |
对账脚本每天跑一次，两个方向分开列。第一类能自动处理的前提是那条判定 SQL 站得住：
-- 软删满 30 天、还没回填 purged_at 的附件，桶里对象等回收
SELECT id, object_key, deleted_at
FROM attachment
WHERE deleted_at IS NOT NULL
AND deleted_at < NOW() - INTERVAL 30 DAY
AND purged_at IS NULL
LIMIT 500;
三条注意，每条带一个不做会怎样的后果。宽限期必须隔开删除动作和业务动作，用户点错删除要能恢复，30 天是这个恢复窗口的下限；桶对象的删除要留下记录，purged_at 就是干这个的，没有它，同一批对象每次扫描都会被判成待删，重跑一脚本就是一次事故；库里有、桶里没有的那一类不进自动清理队列，它自己就是事故现场，自动化的任务是把人带到现场，不是替人打扫。
系列：深文 对象存储：目录、权限、生命周期 ｜ 相关 文件上传：直传、断点续传、秒传各解决什么 ｜ 技术纵深系列索引