用 5MB 分片上传 230MB 视频,8 个分片全部返回 200,合并接口也返回 completed,下载回来算 MD5 和源文件差三位,播放到 2 分 10 秒直接卡住。
原因不止一个,得分开看。最后一片大小按整片计算导致被截断;并发上传后按完成顺序合并而不是按分片号;分片号从 0 与从 1 混用丢了一片;重试覆盖了同名分片造成内容错位。
第一件事是列出服务端已收到的分片号
curl -s 'https://api.example.com/upload/up_123/parts' -H "Authorization: Bearer $TOKEN" | jq -r '.parts[] | [.part_number,.size] | @tsv' | sort -n
再往下核对分片总数与单片大小
python -c "size=230*1024*1024;n=5*1024*1024;print((size+n-1)//n, size-(size//n)*n)"
接着按分片号升序重新合并
curl -X POST https://api.example.com/upload/up_123/complete -H "Authorization: Bearer $TOKEN" -d '{"parts":[1,2,3,4,5,6,7,8],"order":"asc"}'
剩下的就是合并后比对服务端返回的摘要
curl -s 'https://api.example.com/files/f_123' -H "Authorization: Bearer $TOKEN" | jq -r '.sha256'
报错是间歇性的,我蹲守了半小时才抓到一次完整现场。
白天有业务在跑,能验证的部分都压到了晚上做。
别只看报错消失,验证要多做一步。服务端返回的 sha256 与本地一致,下载回放能到结尾,分片列表数量等于预期值。
合并接口返回 completed 只说明流程走完,不代表字节对,上传完成一定要有一次摘要比对。拖得越久,排查成本越高,因为现场状态会被后续操作覆盖。
