ReadAt/WriteAt 不依赖文件当前偏移量，以参数 offset 为起点操作，支持无锁并发（非重叠区域），且不改变文件指针；WriteAt 超出文件末尾时不自动填充空洞或扩展长度，需显式 Truncate；ReadAt 在 offset 等于文件长度时返回 0, io.EOF，大于长度时返回 0, nil。
ReadAt 和 WriteAt 的底层行为与普通 Read/Write 有什么区别
它们不依赖文件当前偏移量，而是以传入的 offset 为起点读写，相当于「跳到指定位置操作」。这意味着多个 goroutine 可以并发调用 ReadAt 或 WriteAt 而无需加锁（前提是不写重叠区域），但 Read/Write 会修改并依赖 os.File 内部的 offset 字段，天然带状态。
注意：ReadAt 不会改变文件指针，WriteAt 也一样——哪怕你写到末尾之后，文件长度也不会自动扩展；必须显式 f.Truncate() 或先写满中间空洞。
为什么 WriteAt 写不到文件末尾之后的位置
Linux/macOS 下，WriteAt 对 offset 超出当前文件大小的位置执行写入时，**不会自动填充中间的 \0 字节**，而是直接返回 0, nil（即成功但写入 0 字节），除非该 offset 已落在已分配的块内或系统支持稀疏文件且底层 fs 允许。实际行为取决于文件系统和 OS。
常见误判：以为 f.WriteAt([]byte("x"), 1000) 就能让文件变长到 1001 字节——它不会。你需要：
- 先
f.Truncate(offset + len(b))确保空间存在 - 或用
os.O_CREATE | os.O_RDWR打开，并配合f.Seek()+f.Write()填充空洞（更可控） - 或者接受稀疏文件语义（某些场景下可行，但 Go 标准库不保证跨平台一致）
ReadAt 返回 io.EOF 但 offset 并未越界？
ReadAt 在 offset 刚好等于文件当前长度时，会返回 0, io.EOF；如果 offset 大于长度，则返回 0, nil（不是错误）。这和 Read 的 EOF 行为不同——Read 遇到 EOF 是因为读完了，而 ReadAt 的 EOF 只表示「从这个 offset 开始没数据可读」。
典型陷阱代码：
f, _ := os.OpenFile("data.bin", os.O_RDWR, 0)
n, err := f.ReadAt(buf, 100) // 文件只有 50 字节
// 此时 n == 0, err == io.EOF —— 不是 panic，但容易被当成异常处理
正确判断方式是检查 n == 0 && err == io.EOF 是否意味着「位置合法但无数据」，而不是一律报错。
并发使用 ReadAt/WriteAt 时要注意什么
虽然函数本身是线程安全的（不改 file state），但若多个 goroutine 向同一段 offset 写入，结果不可预测；读写同一区域也可能读到部分更新的数据（无原子性保证）。实际使用中建议：
- 用
sync.RWMutex控制逻辑上的区域互斥（比如按 record ID 分段加锁） - 避免在循环里反复
WriteAt同一块内存——小 buffer + 高频调用会放大 syscall 开销 - Windows 上
WriteAt可能比 Linux 慢，因 NTFS 对随机写优化较弱；若性能敏感，考虑 mmap + unsafe pointer（需自行管理生命周期）
真正需要随机读写的场景（如数据库页缓存、日志分片索引）往往绕不开自己维护 offset 映射和缓冲策略，ReadAt/WriteAt 只是基础原语，别指望靠它自动解决一致性或扩容问题。
