服务端支持断点续传需响应含 Accept-Ranges: bytes 或返回 206；实操须先 HEAD 校验，再设 Range 请求头，写入前用独立 RandomAccessFile.seek() 定位，状态持久化至元数据文件，并禁用连接复用、手动处理重定向。
Range 请求头怎么设才有效
服务端是否支持断点续传，不取决于你写了 Range，而取决于响应里有没有 Accept-Ranges: bytes 或至少返回了 206 Partial Content。很多 CDN、Nginx 默认关掉 Accept-Ranges，或者对动态资源（如 PHP/Java Servlet 生成的文件）直接忽略 Range —— 这时候你发了 Range: bytes=1000-，服务器仍可能返回 200 OK 全量内容，但你按偏移写入就会覆盖错位置。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 发起请求前先 HEAD 一次，检查响应头是否含
Accept-Ranges: bytes；若无，别硬上断点，老老实实全量下载 - 用
HttpURLConnection时，必须调用setRequestProperty("Range", "bytes=" + start + "-" + end)，注意end可省略（表示“到结尾”），但不能写成start-end中间带空格或乱加单位 - 收到响应后立刻校验
getResponseCode()：必须是206，否则说明服务端没按预期处理，此时应清空已写文件并降级为全量下载
RandomAccessFile 写入时如何避免文件错位
RandomAccessFile 不是线程安全的，多个线程共用一个实例写同一文件，极易出现字节覆盖、跳写、甚至 IOException: Invalid argument。更隐蔽的问题是：你用 seek(offset) 定位后，如果另一个线程也刚调用过 seek()，当前线程的写入位置就不可靠了。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 每个下载线程必须持有独立的
RandomAccessFile实例，打开模式用"rw"，且不要复用或共享 - 写入前务必调用
raf.seek(offset)，且该offset必须与本次Range请求的起始字节完全一致——不能依赖上次写完的位置 - 写入完成后，**不要**调用
raf.close()，保持句柄打开直到整个下载完成；否则下次续传时文件可能被系统回收或重命名，导致FileNotFoundException
多线程协作时如何同步断点状态
断点信息不能只存在内存里。JVM 崩溃、进程被 kill、机器断电，都会让内存中记录的已下载区间丢失。如果只靠文件长度判断“续传起点”，在多线程场景下会出错：因为各线程写入非原子，文件长度可能卡在中间状态（比如 A 线程刚写完 512B，B 线程还没开始，此时文件长度是 512，但实际有效数据只有 0–511，而你误以为 0–511 已完成，就从 512 开始分配新 Range，结果重复下载）。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 用单独的临时文件（如
file.downloading.meta）持久化每一段的下载状态：start,end,status，status 可为done/failed/pending - 每次线程完成一段写入后，先
raf.getChannel().force(true)刷盘，再更新元数据文件，并用FileChannel.lock()保证元数据写入原子性 - 启动续传时，不是读文件长度，而是解析元数据文件，合并所有
done区间，再计算剩余缺口
HttpURLConnection 的连接复用与超时陷阱
HttpURLConnection 默认启用 Keep-Alive，但断点续传中频繁新建连接（尤其是分块多线程）容易触发连接池耗尽或服务端主动断连。更麻烦的是：它对 Range 请求的缓存行为不透明，某些 JDK 版本会在重定向后丢弃 Range 头，导致后续请求变成全量。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 显式关闭连接复用：
conn.setRequestProperty("Connection", "close")，避免长连接状态干扰 - 设置合理超时：
setConnectTimeout(10_000)和setReadTimeout(30_000)，尤其readTimeout要大于单次最大分块传输时间，否则可能中断在半途，又没触发异常捕获逻辑 - 遇到
HTTP 302重定向时，HttpURLConnection默认自动跳转，但不会携带原请求的Range头——必须手动拦截getHeaderFields()，提取Location，再新建连接并重新设置Range
最易被忽略的一点：RandomAccessFile 的 seek() 是逻辑偏移，不校验物理文件大小；如果元数据记录错误或服务端返回内容少于预期（比如网络截断），写入时会静默填充 \0 到目标位置，导致文件损坏且难以排查。
