摘要

  • S3 会保留已经上传的分段并收取存储费用，直到完成或中止上传；应用把任务判为失败，并没有替这些字节退租。
  • 通用存储桶可以配置未完成上传的清理期限。官方例子的七天需要主动设置，目录存储桶又没有同一项生命周期支持。

设想一家制作公司把素材往云端搬，传到一半，客户取消了项目。制片人关掉任务，团队转去赶下一个交付。S3 货架上已经放好的那些分段，却不会因为会议里说了一声“算了”就自己离场。这个假想场景的荒诞之处，在于项目可以没有明天，仓租仍有明天。

Amazon S3 的规则写得很直白。分段上传允许各部分独立传送，失败的部分可以重传，已经成功的部分继续留用。最后完成上传，S3 才把它们组合成对象。已经存下的分段，在完成或中止之前持续计费；上传本身没有一个天然到期日。AWS 分段上传说明

这是一项有用的宽容。大文件传输遇到坏网络，如果每次都从零开始，重试会变成另一份苦差事。保留进度能节省下一次的传输工作。问题出在“下一次”无人认领之后：存储系统还在认真替一项已经失去用途的计划保管行李。

云端半成品，也有老板

财务容易向成品追问成本：哪些文件正在用，哪个客户需要，哪个部门预算买单。未完成上传更尴尬。它尚未成为那份完整对象，却已经占了真实空间。业务系统里的失败状态，是对工作结果的判定；S3 里留下的分段，是对资源现状的记录。把前者当成后者的清算证明，省掉的恰好是该有人负责的一步。

所以这里最值得定价的东西，是继续完成这次上传的机会。项目仍然有效，源端暂时断网，这个机会有价值。客户已改需求、素材已作废、任务重建后不再接续旧上传，机会就可能只剩账单。相同的存储动作，在两种业务状态下有不同意义。

企业若只奖励“任务恢复成功”，便可能让旧尝试长期留在预算的夹层里。新尝试有负责人、有进度条、有交付日期，旧尝试只有一个仍然有效的保留状态。云服务擅长记住字节，人类组织擅长忘记上周为何存下它们。账单把两种特长接了起来。

七天不是自动派来的保洁

AWS 给通用存储桶提供 AbortIncompleteMultipartUpload 生命周期动作：按上传发起后的天数设置期限，到期后进入可中止范围，由 S3 中止上传并删除相关分段。规则覆盖其范围内已有和后来创建的上传；已经完成的对象不受这个动作删除。官方七天示例是配置示例，不能靠看过文档就获得保护。AWS 未完成上传清理规则

期限因此是一项业务判断。压得过短，仍在等待恢复的大型传输会失去已付出的进度；放得过长，已经退出的项目继续占货架。把所有任务塞进同一个天数，只是把讨论藏进了一个整齐的配置值。

可以先问上传在什么情况下值得续命，再决定保留时长。制作任务的交付窗口、源端重新上线的时间、重新取得文件的难度，都比“行业通常设几天”更贴近这笔支出。对于这些未完成分段，AWS 明确没有提前删除费；结束上传后，若形成了完整对象，后续对象存储仍有自己的费用。选择的两端都是具体资源，不能把“完成”当作免费出口。

退出要等正在进门的人

手动中止也有一个容易被界面按钮遮住的细节。AWS 的 API 文档说，正在传送的分段仍可能成功或失败，因此可能需要多次中止才能释放全部分段空间，并建议用 ListParts 确认列表为空。AWS 中止上传 API

这让“谁结束任务”变得比“谁按了按钮”宽一些。一个负责人关闭业务任务，另一个进程还在发送数据，双方各自完成了眼前的指令，资源却需要最后一次核对。管理层如果只接收一个漂亮的完成勾号，便会错过支出真正结束的位置。

另一个分岔来自存储桶种类。目录存储桶同样会为未完成分段计费，却不支持 S3 生命周期配置；删除这种桶之前，还要先完成或中止其中所有进行中的分段上传。AWS 目录存储桶说明 把通用桶的清理承诺复制过去，纸面上安排了保洁，现场却没有那班人。

要算出某家企业到底浪费多少，缺的是其分段清单、保留用途和实际账单；如果旧分段仍对应有价值的待续任务，成本判断就会改变。这个问题值得查清，理由很朴素：一个失败任务可以结束业务故事，只有资源的实际结局才能结束它的仓租。