断点续传不必须用randomaccessfile，但它是java标准库中唯一支持随机写入任意偏移位置的io类；其他方式如fileoutputstream默认覆盖或追加，无法精准跳转续写。
断点续传必须用 RandomAccessFile 吗？
不是必须，但它是 Java 标准库中唯一能真正支持「随机写入任意偏移位置」的 IO 类。其他如 FileOutputStream 默认覆盖或追加，无法精准跳转到已下载的字节位置继续写。如果你用 FileChannel 配合 FileOutputStream，底层其实也依赖类似机制，但封装层级高、控制粒度粗，容易在多线程或异常恢复时丢偏移。
常见错误现象：IOException: Stream closed 或写入内容错位——往往是因为没关流却反复 new RandomAccessFile，或者没调用 seek() 就直接 write()。
-
RandomAccessFile必须以"rw"模式打开，"r"或"w"都不行 - 每次写入前务必先调用
seek(long pos)定位到断点位置，否则从头覆盖 - 注意文件长度可能小于预期偏移量（比如服务端文件被删/重置），需提前校验
length()
如何安全保存和读取断点位置？
断点本质是「已成功写入的字节数」，它不能只存在内存里。最简单可靠的方式是把偏移量存进一个同名的 .offset 文件（如 video.mp4.offset），一行纯数字。
使用场景：下载中断后重启，先读这个文件拿到上次写到哪了，再用该值初始化 seek()；下载完成立即删掉它，避免下次误用。
立即学习“Java免费学习笔记（深入）”；
- 读取时用
Long.parseLong(new String(Files.readAllBytes(Paths.get(offsetPath))))，别用Scanner——换行符兼容性差 - 写入时用
Files.write(Paths.get(offsetPath), String.valueOf(pos).getBytes())，原子覆盖，别用RandomAccessFile写 offset 文件 - 注意
.offset文件权限要和目标文件一致，否则某些 Linux 环境下会因用户隔离失败
RandomAccessFile.write(byte[]) 为什么总写不全？
它只保证「至少写一个字节」，不保证写完整个数组。网络传输分片、磁盘缓存、JVM GC 干扰都可能导致 write() 返回值小于 byte[].length。直接忽略返回值 = 默默丢数据。
性能影响：频繁小块 write 效率低，但盲目合并又增加内存压力和断点精度损失。折中方案是单次不超过 64KB，且必须循环写直到写满。
- 正确写法：
int written = 0; while (written - 别用
raf.write(buf)简写，它等价于write(buf, 0, buf.length)，但不检查实际写入量 - 如果写入过程中抛
IOException，当前pos就是新的断点，立刻保存，不要跳过
HTTP 分段下载怎么和 RandomAccessFile 对齐？
服务端必须支持 Range 请求（响应含 Accept-Ranges: bytes），客户端才能发 Range: bytes=1024-。关键在于：HTTP 返回的 Content-Range 头里的起始偏移，必须和你调用 raf.seek() 的位置严格一致。
容易踩的坑是「以为响应体从 0 开始」——实际上，如果请求的是 Range: bytes=1024-2047，响应体第一个字节对应全局偏移 1024，你要先 seek(1024) 再写。
- 解析
Content-Range推荐用正则bytes (\d+)-(\d+)/，别手动 split，有些服务端返回*/12345格式 - 如果服务端不支持 Range（返回 200 而非 206），必须拒绝续传，否则文件错乱
- 注意 HTTP 响应头大小写不敏感，但
Content-Range的连字符是英文短横，不是中文破折号
断点续传真正的复杂点不在写文件，而在于「偏移量一致性」——网络层、HTTP 层、文件系统层、本地存储层，四者偏移必须全程对齐。任何一层偷偷加 BOM、补零、截断，都会让后续所有 seek() 失效。所以第一次实现时，务必用 hexdump 对比服务端原始分片和本地写入结果。
