分片大小推荐起始值8MB，需据网络环境动态调整；断点续传状态须落盘存储；服务端须正确响应206并透传Range头；并发线程数应匹配连接池与端口资源；需实现服务端分片状态幂等清理。

分片大小设多少才不拖慢又不爆内存

分片不是越小越好，也不是越大越稳——它直接卡在「网络重试成本」和「jvm堆压力」之间。java里用fileinputstream读取1gb文件时，若单片设为1mb，会生成1024个byte[]缓冲区；而设为100mb，虽减少对象数，但一次上传失败就得重传100mb，网络抖动时反而更耗时。

• 推荐起始值：--part-size 8m（8MB），适用于千兆局域网或稳定云专线；公网上传可降至2m或4m
• 避免设为512k以下：HTTP连接建立开销会明显吃掉吞吐，实测在4G网络下，512KB分片比4MB慢3.2倍
• 切忌硬编码固定值：应根据Runtime.getRuntime().maxMemory()动态调整单片缓冲上限，防止OOM

断点状态存在哪？别只靠内存存offset

很多团队把已上传分片ID、当前offset存在ConcurrentHashMap里，重启就丢——这根本不是断点续传，是“伪续传”。真正可靠的存储必须落盘+带事务语义。

• 轻量级场景：用LocalFileStorage写入.dcp文件（如ossutil所用），路径必须绝对且有写权限，别用System.getProperty("user.dir")这种相对路径
• 生产环境：存到数据库的upload_task_progress表，字段至少含file_id、part_no、status、md5、last_updated；更新用UPDATE ... WHERE file_id = ? AND part_no = ? AND status = 'pending'防并发覆盖
• 别把MD5校验值存在客户端本地：攻击者可篡改，服务端必须对每个UploadPart响应后主动计算并比对

为什么用了Range头还是无法续传？服务端常漏这三步

客户端发Range: bytes=123456-，结果服务端返回200全量内容，或干脆404——问题不在前端，而在服务端没正确响应206 Partial Content，也没声明Accept-Ranges: bytes。

• Spring Boot中需显式配置静态资源支持断点：spring.resources.cache.cachecontrol.no-cache=true还不够，得加WebMvcConfigurer拦截器检查Range头并设置HttpServletResponse.setStatus(206)
• Nginx转发时默认不透传Range，需在location块加proxy_set_header Range $http_range;和proxy_pass_request_headers on;
• 对象存储如OSS/MinIO，要确认Bucket开启Versioning且CORS允许Range请求头，否则预检请求直接被拦

并发上传线程数调太高反而变慢？看CPU和连接池是否扛得住

设10个线程上传，结果平均耗时比单线程还长——大概率是线程争抢HttpClient连接池，或触发了Linux临时端口耗尽（net.ipv4.ip_local_port_range默认32768–65535）。

• 先查瓶颈：netstat -an | grep :443 | wc -l超过6万就说明端口不够；jstack看线程是否大量阻塞在PoolingHttpClientConnectionManager
• HttpClient连接池建议：setMaxTotal(20)、setDefaultMaxPerRoute(5)，对应5–8个上传线程较稳妥
• 别盲目开CPU密集型任务：SHA-256校验放上传前做，别在IO线程里同步算，否则线程卡死，可用ForkJoinPool.commonPool()异步预计算

实际落地时，最常被跳过的一步是服务端分片状态的幂等清理——比如AbortMultipartUpload没调或超时未触发，OSS上残留几百个uploadId碎片，下次同名文件上传就会撞冲突。这个逻辑不写进主流程，光靠运维定时脚本清，迟早出事。