因为WriteAt设计为不自动填充空洞或扩展文件长度，超出当前大小时仅返回0, nil；必须显式Truncate或Seek+Write才能生效，这是POSIX规范下的明确行为而非bug。
为什么 os.File.ReadAt/WriteAt 不会自动扩展文件长度
直接调用 f.WriteAt([]byte{1,2,3}, 1000) 后，os.Stat() 显示文件大小仍是原值——这不是 bug，是设计行为。Linux/macOS 下，WriteAt 对超出当前长度的 offset 执行写入时，**不会填充中间空洞（hole）**，而是返回 n == 0, err == nil（即“成功写了 0 字节”）。Windows 表现略有差异，但同样不保证扩展。
真正生效的前提是：目标 offset + len(b) 已落在已分配的文件块内，或底层文件系统支持稀疏文件且内核允许映射。否则必须显式扩展：
-
f.Truncate(offset + int64(len(b)))—— 最直接，但会清零中间区域（如果 offset > 当前长度） -
f.Seek(offset, io.SeekStart); f.Write(b)—— 更可控，适合需要填充特定字节（如\x00）的场景 - 接受稀疏语义（如日志索引跳转），但注意 Go 标准库不承诺跨平台一致性
ReadAt 返回 io.EOF 却没报错？这是正常行为
ReadAt 在 offset == 文件当前长度 时返回 n == 0, err == io.EOF；若 offset > 长度，则返回 n == 0, err == nil。这和 Read 的 EOF 含义不同：ReadAt 的 io.EOF 仅表示「从该位置开始无数据可读」，而非「读取过程出错」。
典型误判代码：
立即学习“go语言免费学习笔记（深入）”；
f, _ := os.OpenFile("data.bin", os.O_RDWR, 0)
n, err := f.ReadAt(buf, 100) // 文件只有 50 字节
if err != nil {
log.Fatal(err) // 这里会 panic！但其实只是位置合法、无数据
}
正确判断逻辑应为：
-
n == 0 && errors.Is(err, io.EOF)→ 位置等于文件末尾，可继续写或视为边界 -
n == 0 && err == nil→ offset 超出文件长度，需先Truncate或跳过 - 忽略
err直接用n判断是否读到数据（更安全）
并发随机读写要不要加锁？看场景
ReadAt 和 WriteAt 本身不修改 os.File 内部偏移量，因此多个 goroutine 调用它们**对非重叠区域是天然并发安全的**。但以下情况仍需同步：
- 多个 goroutine 向同一段
offset写入 → 结果不可预测（竞态） - 一边
WriteAt修改某区域，另一边ReadAt读同一区域 → 可能读到部分更新的数据（无原子性） - 逻辑上需保证「写完立刻可读」→ 即使物理不重叠，也建议用
sync.RWMutex控制区域粒度（例如按 4KB 块划分）
不要依赖「函数签名无锁」就认为业务逻辑线程安全——文件系统层不提供事务或原子段写入语义。
比 ReadAt/WriteAt 更快的大文件随机访问：mmap
当文件远大于可用内存（如 100GB 日志在 16GB 机器上），ReadAt 每次都触发系统调用+内核拷贝，而 mmap 让内核按需加载页，访问即触发缺页中断，延迟更低。
Go 标准库不提供 mmap，推荐用 github.com/edsrzf/mmap-go：
-
mm, err := mmap.Open("bigfile.dat", mmap.RDWR)—— 自动处理页对齐与平台差异 -
mm.ReadAt(buf, offset)和mm.WriteAt(buf, offset)接口一致，但底层走内存访问 -
必须手动
mm.Flush()才能确保修改落盘；不调用则可能丢失（尤其断电） - Windows 需注意 64KB 对齐限制；超大映射（>100GB）可能触发
vm.max_map_count限制
关键点：mmap 不是银弹。顺序扫描全文件时，bufio.Scanner + io.Copy 更省内存；只有频繁跳转、固定偏移访问（如数据库 WAL 查找）才值得引入。
