Cloudflare R2 未完成分片上传 (Ongoing Multipart Upload) 无法删除怎么办？

在 Cloudflare R2 控制台遇到删不掉的灰色 "Ongoing Multipart Upload" 幽灵文件？本文记录了从 rclone 尝试删除失败，到通过配置 Object Lifecycle Rules 强制清理的完整实战过程。

一、问题现象：网页出现“幽灵文件”

在使用 Cloudflare R2 作为对象存储，并搭配 rclone 进行大文件上传时，我遇到了一件让强迫症极其难受的事情：

在 Web 控制台的 kubernetes 目录下，出现了一个灰色的文件（例如 -offline-full.tar.gz）。

它的状态极其诡异：

• 类型：显示为 Ongoing Multipart Upload。
• 悬停提示：鼠标悬停时，会弹出警告提示："This is a multipart upload that has not yet been completed or aborted"。
• 无操作菜单：它的右侧没有常规文件拥有的 ... 操作菜单，无法直接点击删除。

奇怪的是，我的本地 R2 用量统计算下来，这个文件并没有真正占据我已统计到的空间，但它却像“幽灵”一样卡在网页列表里。

二、常规手段遇阻：rclone 的无效尝试

作为习惯使用命令行的用户，我第一时间尝试通过 rclone 解决问题，但全部失败。

1. rclone ls 找不到实体

执行 rclone ls 查看该目录，列表里完全找不到这个文件。

rclone ls cloudflare-r2:fishfinal-dl/kubernetes/

结果：输出里只有正常的 calico 和 k8s 离线包，-offline-full.tar.gz 根本不在列表中。

原因分析：它本质上不是一个“完整对象(Object)”，而是一组分片(Parts)，所以常规的对象列表命令无法捕获它。

2. 调用 API 查不到 UploadId

接下来，我尝试使用 rclone 的 S3 底层 API 查找未完成上传的标识（UploadId）：

rclone backend list-multipart-uploads cloudflare-r2:fishfinal-dl/kubernetes/

结果：返回了空列表 []。在加上子目录路径查询时，R2 的 API 未能识别到这个游离状态的残留。

3. rclone delete 执行“空转”

最后，我抱着试一试的心态，直接用路径去执行 delete：

rclone delete cloudflare-r2:fishfinal-dl/kubernetes/-offline-full.tar.gz

结果：命令执行后终端没有报错，提示正常完成。但当我刷新 Web 页面时，那个灰色的幽灵文件纹丝不动。

这个时候我意识到，这根本不是普通意义上的“删除对象”，而是需要触发中断上传。

三、关键突破口：R2 的生命周期规则 (Lifecycle Rules)

在经历了命令行工具的无效尝试后，我将目光转向了 Cloudflare R2 自身的控制台 Bucket 设置。在 Settings -> Object Lifecycle Rules 中，我找到了破局的关键配置：

Default Multipart Abort Rule (默认分片中止规则)

Cloudflare R2 为了容错和容灾，引入了自动清理机制。默认情况下，如果一个分片上传任务在 7 天内没有完成或中止，R2 的后台服务器会进行自动 Abort（中止），并释放被占用的存储空间。

我的解决办法：

既然默认时间是 7 天，而我这个卡死的分片已经存在了快 5 天，我决定直接“下达强制回收指令”。

我点击编辑（Edit），将生命周期规则的自动中止时间，从 7 day(s) 临时修改为 1 day(s)。

四、一击必中！文件消失

当新的规则保存生效后，奇迹发生了。

由于那个分片的存在时间早就超过了 1 天，R2 的后台检测到规则变更，立即对这个未完成的任务执行了强制的中止操作。

我再次返回 Objects 页面，点击右上角的刷新按钮，那个灰色的、存在了多天的 -offline-full.tar.gz 瞬间消失得无影无踪，整个目录变得无比干净！

五、总结：给遇到同样问题的人的建议

如果你也在 R2 遇到了删不掉的灰色 Ongoing Multipart Upload 残留文件，可以参考以下三个解决方案：

1. 佛系等待（最省心）：因为 R2 默认有 7天 的强制清理规则。只要过了 7 天，后台会自动完成清理，你可以选择不理会它。

2. 手动强制清理（解决强迫症）：像我一样，在 Object Lifecycle Rules 里把自动中止时间临时改为 1 day。这会让 R2 系统立即对超时的分片执行 Abort 操作。

3. 🌟 经验之谈：请务必记得改回来！ 清理完成后，建议将规则立刻改回默认的 7 day(s)。

   为什么？ 如果你平时需要传输几百兆甚至几 GB 的大型离线包，假如网络中途中止，设置成 1 day 意味着第二天你想续传时，前面的分片全没了，需要重新从头开始上传，非常浪费时间、网络和资源。

作为 R2 的日常使用者，合理配置生命周期的 Multipart Abort Rule 不仅是为了解决偶然的 UI Bug，更是极客运维中的一道安全防线。希望这篇踩坑记录能帮你节省排查时间！