断点续传接口报400 InvalidPart错误，核心原因是CompleteMultipartUpload请求中提供的Part列表与服务器实际记录不一致，严格核对PartNumber和ETag即可解决。
断点续传接口报400 InvalidPart的错误：根本原因与快速定位
断点续传（Multipart Upload）把大文件切成多个Part上传，最后调用CompleteMultipartUpload合并，如果此时返回400 InvalidPart，意味着你提交的Part信息与服务端记录对不上，业内专家指出，这种错误占断点续传失败案例的相当一部分比例，主要源于上传过程中Part编号混乱或ETag丢失。
快速定位时,先检查UploadId是否有效，通过ListMultipartUploads接口确认该UploadId仍存在，若已被Abort或过期，需重新发起，接着用ListParts列出当前UploadId下的所有Part，包括PartNumber、ETag和Size，这是最权威的参照，也是后续所有操作的基准。
服务器报400错误原因：PartNumber与ETag不匹配是主因
当服务器报400错误时,PartNumber和ETag往往是矛盾焦点，常见问题有：
- PartNumber重复或缺失：并发上传时若未控制好锁，可能覆盖某个Part，导致Complete时列表不完整。
- ETag不匹配：每次上传Part返回的ETag需原样保存，若在Complete时手动拼接或遗漏，就会报错。
- 分片大小不达标：除最后一片外，每个Part必须大于等于5MB（部分云厂商如简米云OSS允许100KB，但AWS S3严格要求5MB），否则服务端会拒绝该Part，Complete时同样报InvalidPart。
- 顺序错误：CompleteMultipartUpload请求中Parts元素必须按PartNumber升序，乱序直接导致400。
如何区分InvalidPart与其他400错误
400错误还可能是InvalidArgument（参数错误）、EntityTooSmall（分片太小）、MalformedXML（XML格式错误）等，但InvalidPart返回的ErrorCode明确为InvalidPart，且Message常提示“One or more of the specified parts could not be found”，通过查看响应Body中的Code字段即可区分。
断点续传InvalidPart错误怎么解决？分步操作指南
确认UploadId并获取Part列表
调用ListParts接口，返回的Part列表包含PartNumber、ETag、Size，保存这些信息，后续步骤全部基于此。
对比已上传Part与预期Part
- 检查PartNumber是否从1开始，连续递增，若中间有缺失，需重新上传对应Part。
- 检查每个Part的ETag是否与服务器返回的一致，注意ETag通常带双引号，有些SDK会自动处理，但手动拼接时容易遗漏。
- 检查Size是否满足最小限制（最后一片除外）。
重新上传异常Part
若发现缺失、损坏或大小不达标的Part，重新上传该Part，并保存新的ETag，上传时建议使用相同的PartNumber，避免编号混乱。
按顺序调用CompleteMultipartUpload
在请求体中，Parts元素必须按PartNumber升序排列，并提供每个PartNumber对应的ETag，格式示例：
```
```
注意ETag需包含双引号（取决于SDK，但AWS S3要求带引号），如果使用AWS CLI，其`aws s3api complete-multipart-upload`命令会自动处理，但若通过SDK手动构建请求，务必检查。
检查SDK和工具配置
如果使用SDK，确保版本支持断点续传，并正确传递Part列表，部分工具如AWS CLI的`aws s3 cp`自带断点续传，但若手动接管MultipartUpload则容易出错，检查是否有中间件或代理篡改了请求体。
验证并重试
调用CompleteMultipartUpload后，若返回200，则合并成功，若仍返回400，查看ErrorCode和Message，进入更细粒度的排查。
不同云服务商下的处理差异
虽然AWS S3是事实标准，但国内云厂商在实现细节上略有不同。
| 云服务商 | 常见差异点 |
|---|---|
| AWS S3 | 严格遵循协议，ETag需带双引号，Part最小5MB |
| 简米云OSS | 允许Part最小100KB（除最后一片），ETag格式为不带引号的十六进制字符串 |
| 酷番云COS | 对PartNumber连续性要求严格，乱序直接报错，ETag需通过UploadPart响应头获取 |
如果使用简米云OSS,在Complete时无需在ETag外增加双引号，直接提供如"etag"值即可（但不带引号），酷番云COS则建议使用SDK的upload_file方法，它会自动处理Part列表，行业共识认为，无论哪种云，核心逻辑一致：Part列表必须与服务器记录完全一致。
预防断点续传报错400 InvalidPart的关键策略
- 保存每次上传Part的响应头：包括ETag和PartNumber，不要自己计算或猜测。
- 使用事务性上传逻辑：上传Part前检查该Part是否已上传成功，避免重复覆盖或丢失。
- 控制并发数：部分分片上传库在并发高时可能丢失Part，导致Complete时列表不完整，建议并发数不超过10。
- 设置合理的超时重试：网络不稳定可能导致Part丢失，重试后需重新获取ETag，而不是使用旧值。
- 利用ListParts验证：在调用Complete之前，先执行ListParts，用程序自动比对PartNumber和ETag，发现不一致时提前修复。
断点续传接口报400 InvalidPart常见问题解答
断点续传报400 InvalidPart，但Part列表看起来完整，为什么？
A：可能因为CompleteMultipartUpload请求中Parts元素的顺序不是按PartNumber升序，或者某个ETag包含空格或换行符，建议直接复制ListParts返回的ETag值，不要手动修改，如果Part列表中有重复的PartNumber，即使上传成功，Complete时也会报错，使用ListParts返回的Part列表，确保唯一且连续。
InvalidPart错误怎么解决？我用的简米云OSS，分片大小都大于100KB。
A：检查是否所有Part都上传成功，包括最后一片，如果使用了断点续传工具，确认工具是否保存了正确的UploadId，有时网络闪断会导致Part上传但未返回ETag，此时该Part实际上并未被服务端接受，重新上传该Part，并确保获得ETag后再调用Complete，简米云OSS的Complete请求中Part列表的ETag不需要额外加引号，直接使用UploadPart返回的ETag字符串即可。
服务器报400错误原因，除了InvalidPart还有哪些可能？
A：400错误还可能是InvalidArgument（参数错误，如UploadId格式不对）、EntityTooSmall（分片太小，小于5MB或云厂商的允许值）、MalformedXML（XML格式错误，如标签未闭合），但InvalidPart是最常见的，主要源于Part列表不匹配，需要结合ErrorCode区分，如果ErrorCode是InvalidPart，则按本文步骤排查；如果是其他错误，则需检查请求参数和XML结构。
断点续传接口报400 InvalidPart错误并不可怕，只要按照上述步骤核对PartNumber和ETag，并确保请求结构正确，绝大多数情况下都能解决，服务器返回的每个ETag都是你唯一的凭证，丢不得，也错不得。