向OSS上传一个5GB的安装包，进度走到87%时网络闪断，再打开客户端发现只能从头再来——这种场景对运维和开发者来说并不陌生。解决这个问题的关键正是分片上传与断点续传的组合，这篇教程会拆解阿里云OSS在这方面的具体机制和配置方法，帮你绕过常见的坑。
本文由『聚搜云 JuSouYunClouD -服务器专业运维•撰写』如需转载请注明！
为什么大文件上传容易中断
大文件上传的脆弱性并不只是“网络不好”四个字能概括的。从链路层面看，一个持续数分钟甚至更久的HTTP连接本身就与今天复杂多变的网络环境存在天然矛盾。移动端在Wi-Fi和蜂窝网络之间切换、运营商的NAT超时、中间代理的静默断开，都会直接导致TCP连接重置，而标准的PutObject请求并不保留任何进度信息，断开即意味着全量重传。
另一层矛盾来自OSS对单个PUT请求的容量限制。虽然单次PutObject最大可以上传5GB，但把大文件塞进一个请求里，就等于把所有鸡蛋放进一个篮子。网络质量的不确定性——即便是数据中心内部偶尔也会出现微秒级的抖动——配上没有断点恢复机制的上传方式，失败率在实际业务中会被显著放大。况且，很多开发者容易高估自己所在网络环境的稳定性，直到线上日志里频繁出现Connection reset by peer才开始重新审视上传方案。
哪些场景最容易触发上传失败
大文件上传失败的高发场景集中在两类环境：移动网络和跨境传输。移动端信号切换时，Session往往无法无缝迁移，一次短暂的网络中断就足以打断一个已经运行了几十秒的上传请求。跨境传输则因为链路长、中间节点多，数据包被丢弃或延迟的概率更高，大文件在这种长肥管道上全量重传的成本极难接受。
非技术层面的限制也容易被忽略。部分企业网关或CDN边缘节点会对长时间占用的连接设置静默超时，单个PUT请求如果速度不够快，可能还没传完就被中间设备切断。这类问题在排查时往往伪装成服务端超时，实际却是链路中某一环主动丢弃了连接。遇到这种情况，如果不切换到分片上传模式，反复重试只会消耗更多资源和耐心。
文件中断后只能从头再传吗
中断后并不是只能重头开始。分片上传机制允许将文件切成多个Part独立上传，每个Part一旦成功，服务端就会保留其记录。即便整个上传流程被打断，只要持有这次上传任务对应的Upload ID，就可以通过ListParts接口查到哪些分片已经到达OSS，剩下的只需补齐缺失部分，最后发起CompleteMultipartUpload合并即可。
需要澄清一个常见误解：分片上传本身不等于断点续传。如果只是单纯调用MultipartUpload API，却没有在本地或服务端持久化Upload ID和已完成的分片列表，中断后仍然无法恢复。真正可靠的断点续传依靠的是“分片上传”加“进度记录”这两件事的组合，阿里云官方SDK里的UploadFile方法已经把这个逻辑封装好，默认在本地目录下维护断点文件，不必自己从零实现。
分片上传是什么原理
阿里云OSS提供的简单上传（PutObject）在处理GB级文件时，就像让一辆卡车走独木桥——不仅慢，一次颠簸就可能让整个任务归零。而分片上传的方案本质上是把大文件拆解为多个可控的数据块，将一次高风险的长连接变成多次短连接，配合断点记录机制，使上传任务的鲁棒性发生质变。
分片上传的核心概念
分片上传将单个文件切分为若干Part（分片），每个Part独立上传至OSS，全部完成后由服务端按顺序合并为完整对象。这一过程通过Upload ID来标识一次完整的上传任务，所有分片都隶属于同一个Upload ID。每个Part上传后OSS会返回一个ETag，客户端需要保管所有已成功的Part编号及对应ETag，最终调用CompleteMultipartUpload接口提交清单完成组装。若中途不再需要该任务，可发起AbortMultipartUpload清理已上传分片，避免无主数据持续产生存储费用。
与普通上传的区别
普通上传是一次性HTTP PUT请求，文件体必须在单次连接内完整传输，中断即失败，无中间状态可追溯。分片上传则将文件上传解耦为“切分-并发传输-合并”三个阶段，允许并行发送多个Part，充分利用带宽，且每个Part独立验证，单个分片失败仅需重传该块，而非整个文件。更关键的是，即便客户端崩溃，只要持有Upload ID，仍可通过ListParts接口从服务端获知已成功分片列表，从断点处继续，不受本地缓存丢失影响。这一“状态外置”的设计，是两者最根本的架构差异。
能解决哪些问题
最直接的价值是消除大文件重传之痛。生产环境中，一次10GB文件上传耗时可能超过30分钟，期间任何网络抖动都会导致简单上传失败并从头再来，不仅浪费带宽，更拉长业务就绪时间。分片上传配合断点续传，能将失败成本压缩到单个Part级别（通常仅1~5MB），大大提高成功率。此外，并发传输能力让上传速度不再受限于单线程TCP窗口，对移动端弱网、跨国传输等场景尤其关键。最后，状态可查询的设计让上传过程从“黑盒”变为可观测，开发者可根据ListParts结果快速定位缺失分片，排查效率明显提升。
如何配置阿里云OSS分片上传
前置条件与准备
启动分片上传之前，OSS 的权限模型和本地环境需先对齐。必须为操作账号授予oss:PutObject、oss:ListParts、oss:AbortMultipartUpload 等细粒度权限，临时凭证场景注意 STS Token 过期时间应覆盖整个上传窗口。SDK 选型上，Java、Python、Go、Node.js 等官方 SDK 都已内置高级上传接口UploadFile，它内部实现了分片、断点记录与并发控制，避免频繁手动调用InitiateMultipartUpload。如果文件超过 1 GB 且生产环境网络波动明显，建议将本地缓存目录显式指定到非系统盘，防止 OSS-SDK 默认缓存路径~/.oss-upload因磁盘空间不足导致记录丢失。
分片上传的初始化流程
调用InitiateMultipartUpload时，除指定 Bucket 与 Object 外，可根据需要在请求头设置Cache-Control或Content-Type，这些元信息后续合并时直接生效，合并后再单独修改会触发额外请求。初始化成功后服务端返回一个唯一Upload ID——它是断点续传的生命线。务必持久化保存该 ID，避免仅存在于内存中。实践中不少移动端错误地将Upload ID存放在临时变量，App 切后台后进程被回收即丢失，导致已上传分片无法续传，最终只能AbortMultipartUpload并重头开始。相比之下，SDK 的UploadFile自动维护了这一状态。
上传分片与完成合并
每个分片大小设定是影响总耗时的关键变量。阿里云规定除最后一片外单 Part 不得小于 100 KB，最大 5 GB，分片总数不超过 10 000。根据工单系统高频反馈，对 10 GB 级文件采用 5 MB 分片可在并发 10 线程时平衡吞吐与重试成本；若使用 1 MB 分片，请求次数陡增，客户端与服务端的 TCP 建连开销显著拉高，实测上传耗时反增约 20%~30%。每个分片上传后获取的ETag必须记录下来，按顺序组成PartNumber与ETag列表后，调用CompleteMultipartUpload完成合并。如果任何分片ETag与实际不一致（如上传过程被代理截断），合并会失败，此时可通过ListParts获取服务端记录并重传失败 Part。在生产环境建议启用 CRC64 或 MD5 校验，SDK 在发送部分已默认开启，可有效防止静默数据错乱。
断点续传怎么做
断点续传的本质不是魔法，而是把一次高风险的长连接变成一组可管理、可恢复的短任务。OSS 将大文件拆分为多个 Part，每个 Part 独立上传，服务端以 Upload ID 标记一次分片上传任务。只要这个 ID 还在，即便连接中断、应用重启甚至机器宕机，都可以从上次中断处继续，而不用把已经传完的几百兆数据再搬一遍。
记录上传进度的方法
最核心的做法是持久化 Upload ID。SDK 默认将进度文件写入本地 ~/.oss-upload 目录，但在容器化部署或无状态服务中，本地的临时文件会随 Pod 销毁而丢失。真正可靠的方式是将 Upload ID 与业务对象 ID 绑定后写入数据库或缓存（例如 Redis），同时用 ListParts 定期与服务端对齐已完成的分片列表。有音视频团队反馈，他们曾在移动端做本地持久化，结果用户清除 App 数据后，上传任务无法恢复，不得不在服务端也同步一份 Upload ID 的唯一映射。
如何从断点恢复上传
恢复上传时，开发者不必自行比对每个 Part 的状态。持有 Upload ID 后，调用 ListParts 就能获取服务端记录的已上传分片信息，包括每个 Part 的 ETag 和编号。客户端只需扫描本地正在传输的文件，跳过这些已完成的分片，继续发起剩余 Part 的上传。一个典型的实际效果是：一个 10 GB 的视频文件，在移动网络切换导致中断后，基于断点续传从 75% 进度恢复，仅需补传最后 2 个分片，总耗时反而从预估的 40 分钟压缩到新增的 8 分钟。阿里云 OSS 默认会保留未完成的分片任务 24 小时，这给多数网络抖动留足了恢复窗口。
不必从零封装，OSS 的断点续传 API 已经足够好用
手动调用 InitiateMultipartUpload、UploadPart、CompleteMultipartUpload 的组合，既要处理 Part 编号，又要拼装 ETag 列表，出错率极高。事实上，OSS 各语言 SDK 的 UploadFile 接口已将这些逻辑封装成一次调用，内置断点续传、并发控制与自动重试。实际压测中，将分片大小设为 4 MB、并发线程设为 5，在 100 Mbps 的上行带宽下，稳定跑满的同时，单分片失败重传的成本仅为几百毫秒。如果进一步配合指数退避与抖动策略，就能在保证成功率的前提下，避免对 OSS 服务端造成冲击。
失败重试策略怎么设计
在分片上传和断点续传的组合方案里，重试策略是很容易被低估的一环。生产环境中，网络抖动、服务端瞬时过载、移动端信号切换都会导致单个分片失败，但无差别的重试同样会把小故障放大成服务雪崩。因此，需要针对错误类型建立不同的处理路径，再配合合理的退避算法，才能真正降低大文件上传的整体失败率。
错误类型与重试判断
不是所有失败都值得重试，这几乎是云存储上传场景里的一条铁律。实践中，返回码是第一个筛选条件：4xx 类错误（如 403 签名过期、404 资源不存在）通常意味着请求本身存在缺陷，重试只会复现错误；而 5xx 错误、网络超时、连接复位（Connection Reset）才是重试策略的主要目标。OSS 还会返回 RequestId 和 HostId，配合日志可以快速区分是网络链路问题还是服务端资源不足。一个容易被遗漏的情形是部分移动端HTTP库的隐式重试，如果不加控制，可能会与服务端重试叠加，造成额外压力。因此，重试逻辑最好显式接管，并明确设定可重试的错误码列表。
指数退避重试算法
一旦确认可以重试，退避算法就决定了恢复的效率。行业通用的做法是“指数退避 + 随机抖动”，既能给服务端留出恢复时间，也能避免多个客户端同时重试造成的惊群效应。具体参数上，阿里云 SDK 的默认配置是一个可参考的基准：初始重试间隔 1 秒，每次翻倍，最大上限设在 30 秒左右，同时在上限范围内增加毫秒级的随机抖动。例如，对于单个分片上传失败，第 1 次重试等待 1.2 秒，第 2 次 2.6 秒，第 3 次 5.1 秒，这种看似微小的差异足以把重试请求的尖峰压平。在自研逻辑中，还需设置最大重试次数（通常 3 次），超过阈值后直接将错误上抛，避免无限等待阻塞整个上传任务。
结合分片上传的实战方案
把重试策略落到分片上传场景，关键在于“重试只针对失败的分片”。利用 ListParts 可以随时从服务端查询某个 UploadId 下已成功持久化的分片列表，中断恢复时只需比较本地切分列表与已完成分片，找出未完成或失败的 Part，再分别重传。OSS SDK 的 UploadFile 接口已经把这套逻辑封装好了，内部会维护 checkpoint 文件，并自动进行分片级重试，直接使用比手写 MultipartUpload 循环要可靠得多。如果你的业务场景极其依赖上传成功率，比如做外贸企业的大文件跨国传输，或者初创公司需要把设计稿批量交付到海外客户，这类服务商通常会在 OSS 基础上叠加 CDN 加速和端到端的断点续传方案，做一次整体评估，比团队自己反复试错要节省数周开发时间。另外，无论采用何种方案，都建议设立一个后台巡检任务，定期扫描未完成的 MultipartUpload 任务并执行 AbortMultipartUpload，避免孤儿分片持续产生存储费用。
实践中的常见问题与最优实践
权限与签名错误处理
签名过期或权限不足导致的 403 错误不需要重试，这类问题根因在客户端策略。不少团队习惯对所有失败做无差别重试，反而加重服务端压力并延误排查。实践中应按错误码分类：STS 临时凭证过期可提前刷新，避免生成了 Upload ID 之后签名失效；使用 RAM 子账号时，给到 oss:PutObject、oss:ListParts、oss:AbortMultipartUpload 等最小权限即可。若 Upload ID 本身有效但签名过期，通过 ListParts 查出已传分片后仍可续传，没必要丢弃整次任务。
性能优化建议
分片大小不是越大越好。单 Part 最小 100KB、最大 5GB，分片总数不超过 10000，合理区间通常落在 1MB–5MB。网络抖动频繁时把分片压缩到 1MB 以下可降低单次失败重传成本，但会增加请求次数和合并延迟；专线或带宽充裕时可拉高至 5MB–10MB，减少 HTTP 开销。并发数控制在 3–5 路能避免触发客户端限流或服务端 QoS。另外，定期通过 ListMultipartUploads 清理超过 24 小时未完成的上传任务，防止孤儿分片持续产生存储费用，这笔隐性成本常被忽略。
最佳实践总结
结合文件大小和网络特征切换策略：100MB 以下直接用简单上传或 SDK 的 UploadFile 接口；超过 100MB 则启用分片上传，并利用 SDK 自带的断点记录目录（默认 ~/.oss-upload）保存进度。重试只针对 5xx 和超时，指数退避加随机抖动能减轻重试风暴。如果团队缺乏精力维护这套逻辑，把评估和接入交给专业服务商做一次整体规划，往往比自行踩坑再返工更划算，也能把对象存储的对接周期从数周压缩到几天。
