应使用os.open配合io.readat实现大文件随机读取，避免全量加载；优先用binary.read解析固定header；offset递进时须用int64防止溢出。
用 os.Open + io.ReadAt 实现精确 offset 读取
大型二进制文件（如日志、数据库快照、自定义索引文件）不能全量加载，必须跳过 os.ReadFile，改用支持随机访问的 io.ReaderAt 接口。核心是：打开后不读全部，只在需要时按 offset 和长度取字节块。
-
os.Open返回的*os.File原生支持ReadAt([]byte, int64) (int, error)，无需额外包装 - 绝对不要用
bufio.NewReader包裹它——会破坏随机性，变成顺序流 - Windows NTFS 下大文件
ReadAt性能略弱，Linux ext4/XFS 更稳；若跨平台，建议压测验证 - 示例：
file.ReadAt(buf, 1024)从第 1024 字节开始读len(buf)字节，返回实际读取数
解析固定 header 时 binary.Read 比手算位移更安全
很多二进制格式在 record 开头有固定结构（如 8 字节 magic + 4 字节 length），手动写 buf[0:4]、binary.LittleEndian.Uint32(buf[4:8]) 易错且难维护。直接用 binary.Read 解包到 struct 更可靠。
- struct 字段必须导出（首字母大写），类型严格匹配二进制布局（
uint32对应 4 字节，[4]byte对应 4 字节 raw data） - 大小端必须与生成方一致：
binary.BigEndian用于网络协议，binary.LittleEndian常见于 Windows PE 或某些日志 - 务必检查
binary.Read返回的 error，常见io.ErrUnexpectedEOF表示 buf 不够长或 offset 越界 - 示例：
err := binary.Read(bytes.NewReader(buf), binary.LittleEndian, &hdr)
按 record 边界递进 offset 时小心 int 溢出
日志类文件常靠 header 中的 Len 字段跳到下一条起点，但 Len 是 uint32，而 ReadAt 的 offset 是 int64，中间转换极易踩坑。
- 禁止写
nextOffset = currOffset + int(hdr.Len)—— 若hdr.Len > math.MaxInt32，int()会溢出为负数，ReadAtpanic “invalid argument” - 统一用
int64运算：nextOffset := currOffset + int64(hdr.Len) - 每次调用
ReadAt前，检查nextOffset >= 0且nextOffset ，否则提前退出 - 获取文件大小用
file.Stat().Size()，返回int64，避免隐式转换
mmap 适合只读超大文件，但生命周期管理容易被忽略
当文件超过几 GB 且需高频随机访问（如内存数据库快照、索引映射），mmap 比反复 ReadAt 更高效——内核按需加载页，不占 Go 堆内存。
- Go 标准库无直接支持，Linux/macOS 用
golang.org/x/sys/unix.Mmap，Windows 用syscall.Mmap - 映射后得到的
[]byte是虚拟地址视图，不可长期持有unsafe.String—— 文件被truncate或显式Munmap后指针失效 - 必须封装成 struct 并实现
Close()方法，在 defer 或资源池中显式调用unix.Munmap，否则泄漏虚拟内存 - 写入场景慎用：
mmap写后需msync刷盘，且并发写需额外同步，多数情况不如os.WriteAt
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
