分片大小推荐起始值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。 RedClaw 百度推出的手机端万能AI Agent助手