# 

一张存储账单引起过注意：某个桶的对象列表加起来是 3.6 TB，账单上写的存储容量是 5.4 TB。

差的这 1.8 TB 在控制台里看不见。文件列表拉到最后一页也只有那么多，按前缀统计、按目录统计都对得上，就是和账单对不上。

答案在控制台左侧一个很少被点开的入口里：未完成上传，也叫文件碎片。

## 分块上传为什么是三步，而不是一步？

对象存储的大文件上传不是「一次传完」，而是分成三步。

第一步，发起上传，服务端返回一个上传 ID。这个 ID 是整条流程的句柄，后面所有分块都挂在它下面。

第二步，按块上传。每一块独立传输、独立成功，服务端把块存起来，但不组装。

第三步，调用完成接口，服务端按块号顺序把块拼成对象。

关键在于：**只有第三步发生，对象才存在**。前两步做得再完美，只要第三步没执行，文件列表里什么都没有。

腾讯云对象存储的文档把这件事写在数据管理的常见问题里：

> 文件碎片是在上传对象过程中，暂停或取消上传时产生的。对象存储 COS 支持将大于5GB的大文件以分块上传的方式进行上传，原理是将大文件进行分块，处理成小的分块进而上传。如果在分块上传的任务中没有调用 Abort Multipart Upload 或 Complete Multipart Upload 接口，已经上传的分块就会存储为文件碎片。文件碎片不支持下载。

这段话里有两个信息点经常被漏掉。

一是「没有调用 Abort 或 Complete 接口」这个条件。注意是两个都算：正确结束（Complete）或者主动放弃（Abort）。两个都不做，碎片就留在那里。

二是「文件碎片不支持下载」。这意味着你没法通过下载去验证它是什么内容，只能看到它的大小和发起时间。

## 看不见的碎片，为什么会出现在账单上？

同一份文档紧接着写：

> 文件碎片和正常的对象一样会占用存储空间，所以会产生存储容量费用。

这句话不需要解释。它占的容量和正常对象一样计费，但你在文件列表里看不见它，所以它对「我存了多少东西」的认知是隐形的。

文档也给了两个出口：

> 您可以在对象存储控制台上直接删除文件碎片，操作方法请参见删除碎片文件，您也可以通过配置生命周期定期清理文件碎片。

还有一个让人安心的说明：

> 清理文件碎片会对未成功上传的文件进行删除，不会影响其他已完整上传的文件。

这条很重要。很多人不敢动碎片，怕把正常文件删了。文档明确说了不会——碎片和已合并的对象是两套东西，Complete 之后块就被组装成对象了，不再是碎片。

## 为什么碎片会越积越多？

按经验，碎片主要来自四个地方，都和「异常中断」有关。

**第一个，客户端超时重试。**

上传一个大文件，客户端等太久超时了，于是重试。重试时通常不会复用原来的上传 ID，而是重新发起一次。原来是三步——发起、传块、完成，现在第一步又走了一遍，得到一个全新的上传 ID。

旧的那条链上的块还在，没有任何人去 Complete 或者 Abort 它。一次超时，可能就留下一个几十 GB 的碎片。

**第二个，进程被杀。**

上传脚本跑在 CI 里，或者跑在一台按量计费的机器上，任务超时被杀、机器被回收、容器被驱逐。这些都不会给程序一个「优雅退出」的机会去调 Abort。

**第三个，网络中断但客户端没有重试。**

传到一半断网，客户端放弃了，服务端不知道你放弃了。它只知道这个上传任务还开着。文档里的说法是「暂停或取消上传时产生」，这里的「取消」指的是客户端主动调 Abort，不是拔网线。

**第四个，代码里没有兜底。**

这是最常见的一个。上传逻辑写成「成功就 Complete，抛异常就往上扔」，没有 finally 里的 Abort。只要中间任何一步出错，碎片就留下了。

四种原因的共同点是：**碎片不会自己消失**。这一点可以对照另一个云厂商的说明，写得更直白。亚马逊 S3 的对象存储文档里说：

> After you initiate a multipart upload, there is no expiry; you must explicitly complete or stop the multipart upload.

发起之后没有过期，必须显式完成或停止。如果什么都不做，分块会一直保留，也一直计费：

> you are billed for all storage, bandwidth, and requests for this multipart upload and its associated parts.

「必须显式」这四个字，是理解碎片问题的关键。它不是「过一阵自动清掉」，是「你不处理它就永远在」。

## 清理碎片有哪三条路，成本怎么排？

**最省事的：配生命周期规则。**

在存储桶的基础配置里，可以给「未完成的分块上传」设一条过期规则：超过 N 天自动中止并删除。配好之后不用管，新产生的碎片会被自动清掉。

天数不要设太长。设 30 天，意味着这 30 天内产生的所有碎片都在完整计费。对高频上传的桶（视频、日志、备份），一个月的碎片积压可能是几百 GB 到几 TB。1 到 7 天是比较常见的取值。

**次省事的：定期巡检加批量中止。**

如果桶的数量多、或者想先摸清现状再配规则，用脚本扫一遍更直接。COS 提供了列出进行中分块上传的接口，返回每条任务的 UploadId 和发起时间；再按 UploadId 中止。

```python
# 巡检思路示意，不是可直接运行的完整脚本
# 1. 列出桶内所有进行中的分块上传
#    client.list_multipart_uploads(Bucket=bucket, Prefix=prefix)
#    返回结果里有 Key、UploadId、Initiated（发起时间）
# 2. 按发起时间过滤，比如超过 3 天的
# 3. 逐条调用 client.abort_multipart_upload(Bucket=..., Key=..., UploadId=...)
# 4. 打印每条的 Key / 大小 / 发起时间，留档做趋势

# 注意两个工程细节：
# - 分页要处理完整，不要只取第一页
# - abort 要单独 try/except，一条失败不能中断整轮
```

第 3 步的 abort 一定要单独容错。真实环境里会出现「任务其实还在传」的情况，这时候中止会打断一个正常的业务上传。所以巡检脚本最好先只做「列出 + 打印」，观察几天确认没有误伤，再开自动中止。

**最根本的：在上传代码里保证收尾。**

不管成功失败，最后都要有一个明确动作：成功就 Complete，失败就 Abort。用 try/finally 包住整个流程，别指望异常处理链的某一层会记得。

```python
# 结构示意：确保每条路径都有收尾
upload_id = client.create_multipart_upload(Bucket=bucket, Key=key)["UploadId"]
finished = False
try:
    for part_num, chunk in enumerate(chunks, start=1):
        resp = client.upload_part(
            Bucket=bucket, Key=key, PartNumber=part_num,
            UploadId=upload_id, Body=chunk,
        )
        parts.append({"PartNumber": part_num, "ETag": resp["ETag"]})
    client.complete_multipart_upload(
        Bucket=bucket, Key=key, UploadId=upload_id,
        MultipartUpload={"Parts": parts},
    )
    finished = True
finally:
    if not finished:
        # 任何一步失败，主动放弃，别把碎片留给账单
        client.abort_multipart_upload(Bucket=bucket, Key=key, UploadId=upload_id)
```

这段代码的价值不在写法，在那句「别把碎片留给账单」。很多团队有完整的重试逻辑，却没有收尾逻辑，重试越多，碎片越多。

## 怎么确认自己的桶里有没有碎片？

三步，从粗到细。

第一，看账单和对象列表的差值。如果「账单容量」明显大于「对象列表容量」，差值就是嫌疑。

第二，进控制台看「未完成上传 / 文件碎片」这个入口。它不在文件列表里，要单独点。有些桶的这个入口是在存储桶详情的左侧菜单里。

第三，如果碎片数量过万，控制台分页加载会很慢，这时候用接口扫，别手动点。

| 判断依据 | 说明 | 处理 |
| --- | --- | --- |
| 账单容量 > 列表容量 | 差值大概率是碎片 | 进碎片入口核实 |
| 碎片发起时间集中在某几天 | 那几天有过批量上传失败 | 查当时的任务日志 |
| 碎片 Key 有规律（如带日期前缀） | 来自定时任务 | 去改那个任务的收尾逻辑 |
| 碎片大小接近单个大文件 | 大概率是超时重试留下的 | 检查重试策略是否复用 UploadId |

第三行和第四行对应的处理方式完全不同。前者要改代码，后者要改重试策略。只看总量是分不出来的，必须看分布。

## 发布前该确认哪三件事？

这几项做过一次，后面基本不会再为碎片付钱：

| 检查项 | 具体动作 |
| --- | --- |
| 生命周期规则 | 是否配了「未完成分块上传」的过期天数，是否在 1 到 7 天之间 |
| 上传代码收尾 | 失败路径是否调了 Abort，是否有 try/finally 兜底 |
| 巡检是否可视化 | 是否能按天看到碎片总量趋势，而不是月底看账单才发现 |

第二项最容易被认为「写了就没事」，实际要验证一次：故意在上传中途 kill 掉进程，然后去碎片列表看有没有一条新记录。有，说明收尾逻辑没兜住。

我把这几类和云上计费相关的隐形项整理成了一份检查清单，包括碎片、快照、闲置 IP、未挂载的云盘。清单是用 AI墨衍 把几次对账的记录归拢出来的，每一项的判据都对着官方文档核过一遍。

顺便问一句：你们上一次看「未完成上传」这个入口，是什么时候？


一张存储账单引起过注意：某个桶的对象列表加起来是 3.6 TB，账单上写的存储容量是 5.4 TB。

分块上传没调完成接口：对象不存在，存储费一直在涨

运维

对象存储账单容量超出文件列表容量，多出的存储费用常源于未完成的分块上传（文件碎片）。碎片在控制台单独入口查看，不显示于文件列表且不支持下载，但按正常容量计费。定期配置生命周期规则或主动中止上传可清理碎片，需排查上传代码收尾逻辑，避免异常中断产生积压。

对象存储

数据管理

代码解释

容器

对象存储COS新用户低至1元！


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

分块上传没调完成接口：对象不存在，存储费一直在涨-腾讯云开发者社区-腾讯云

分块上传没调完成接口：对象不存在，存储费一直在涨

分块上传没调完成接口：对象不存在，存储费一直在涨

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐