randomaccessfile 通过 setlength() 预设文件逻辑大小制造空洞实现高效预分配，配合 range 请求和 seek/write 精准写入已下载片段，空洞不占物理空间但需独立校验保障完整性。
RandomAccessFile 本身不直接创建或管理“稀疏文件”（Sparse File），它只是提供随机读写能力；操作系统是否实际分配磁盘空间，取决于写入行为和底层文件系统支持。所谓“利用空洞实现预分配”，本质是：先将文件逻辑长度设为最终大小（如通过 setLength()），再按需写入数据块——未写入区域在多数现代文件系统（如 ext4、NTFS、XFS）中不会占用物理磁盘空间，即形成“空洞”。这正是断点续传中高效预分配的关键。
用 setLength() 预伸展文件，制造逻辑空洞
下载开始前，若已知目标文件总大小（例如从 HTTP Content-Length 或服务端元数据获取），可立即调用 setLength(totalSize)。这会将文件逻辑长度设为指定值，但不写入任何字节——文件系统仅更新 inode 中的大小字段，不分配数据块。
- 即使 totalSize 是 100GB，
setLength(100L * 1024 * 1024 * 1024)几乎瞬时完成，且不占磁盘空间 - 后续对任意偏移位置（如 50GB 处）写入数据时，文件系统才按需分配该区域的物理块
- 注意：必须确保文件已存在且可写；若文件不存在，需先创建空文件再调用 setLength
配合 Range 请求，精准写入已下载片段
HTTP 断点续传依赖 Range 请求头（如 Range: bytes=1024-2047）。客户端记录每个成功写入的字节范围（offset + length），每次恢复下载时，跳过已写区域，只请求剩余区间。
Accessibility Review
下载
对设计或页面进行 WCAG 2.1 AA 无障碍审计。触发关键词：“audit accessibility”、 “check a11y”、 “is this accessible?” 或在审查设计时使用。
- 用
raf.seek(offset)定位到目标起始位置，再调用raf.write(buffer, 0, len)写入数据 - 无需清空或覆盖已有内容——空洞区域天然“空白”，已写区域保持不变
- 建议每次写入后调用
raf.getChannel().force(false)确保数据落盘（尤其重要段落）
校验与完整性保障不能依赖空洞
空洞只是节省空间的机制，不提供数据一致性保护。断点续传必须独立维护校验逻辑：
- 保存已下载的 offset-length 映射（如 JSON 文件或数据库），而非依赖文件内容判断“哪里写了”
- 下载完成前，对每个写入块做 MD5/SHA256 校验（服务端应提供分块哈希或整体哈希）
- 重启时，先读取本地记录的已下载范围，再向服务端发起 HEAD 或自定义校验接口确认有效性
跨平台与文件系统注意事项
稀疏特性由 OS 和文件系统共同决定，Java 层无感知：
- Linux（ext4/xfs）和 Windows（NTFS）原生支持稀疏文件，
setLength()行为符合预期 - macOS APFS 对稀疏支持有限，
setLength()可能触发实际零填充（导致磁盘爆满），建议下载前检查df -h并预留足够空间 - 容器或网络存储（如 NFS、某些云盘）可能禁用稀疏特性，此时
setLength()会强制分配全量空间——务必测试实际磁盘占用
