应使用 os.Open 配合 io.ReadAt 实现大日志文件的随机读取，避免 os.ReadFile 导致 OOM；通过 binary.Read 解析固定 header 结构，确保大小端正确并校验错误；位移计算统一用 int64 防溢出，且每次 ReadAt 前检查 offset 合法性。
用 os.Open + io.ReadAt 避免全量加载
读大型二进制日志（比如几百 MB 或上 GB）时，os.ReadFile 会直接 OOM。必须跳过「读到内存再解析」这步，改用随机读取位移（offset）的方式按需解析。
核心是：打开文件后不读全部，只在需要某段数据时，用 io.ReadAt 精确读取指定 offset 和长度的字节块。
-
os.Open返回*os.File，它实现了io.ReaderAt接口，支持ReadAt([]byte, int64) (int, error) - 不要用
bufio.NewReader包裹它——那会破坏随机读能力，变成顺序流 - 注意：Windows 下 NTFS 对大文件
ReadAt性能略差，Linux ext4/XFS 更稳
file, _ := os.Open("log.bin")
buf := make([]byte, 16)
n, _ := file.ReadAt(buf, 1024) // 从第 1024 字节开始读 16 字节
解析固定头结构时，用 binary.Read 而非手动位移计算
很多二进制日志在每条记录开头有固定长度 header（比如 8 字节 magic + 4 字节 len + 4 字节 timestamp），手动 buf[0]、buf[4] 拆解易出错且难维护。
binary.Read 能把一段字节直接映射成 Go struct，自动处理大小端和字段对齐，比手算 offset 安全得多。
立即学习“go语言免费学习笔记（深入）”；
- struct 字段必须是导出的（首字母大写），且类型要和二进制布局严格对应
- 用
binary.BigEndian还是binary.LittleEndian取决于日志生成方，错一个字节就全乱 - 别忘了检查
binary.Read返回的error——常见错误是io.ErrUnexpectedEOF，说明 buf 不够长或 offset 越界
type LogHeader struct {
Magic uint64
Len uint32
Ts uint32
}
var hdr LogHeader
err := binary.Read(bytes.NewReader(buf), binary.LittleEndian, &hdr)
按 record 边界递进位移时，小心 int 溢出和负 offset
日志通常是 record 连续拼接（无分隔符），靠 header 中的 Len 字段跳到下一条起点。但 Len 是 uint32，而 ReadAt 的 offset 是 int64，中间转换容易掉坑。
- 别写
nextOffset = currOffset + int(hdr.Len)——如果hdr.Len > math.MaxInt（虽然少见），会溢出变负数，ReadAt直接 panic “invalid argument” - 统一用
int64做位移运算：nextOffset := currOffset + int64(hdr.Len) - 每次调用
ReadAt前，先检查nextOffset是否>= 0且，否则提前退出 - 文件 size 用
file.Stat().Size()获取，别信 header 里的“总长度”字段——它可能被截断或写错
并发读同一文件时，ReadAt 安全但 Seek+Read 不安全
想加速解析？可能会想到起 goroutine 并发读不同段。这时必须用 ReadAt，绝不能共用一个 *os.File 然后各自 Seek 再 Read。
-
ReadAt是纯函数式：offset 传进去，buf 传进去，不改变文件内部 offset，天然并发安全 -
Seek修改的是文件对象的共享游标，多个 goroutineSeek+Read会相互覆盖，读到错乱数据 - 即使加 mutex 锁住
Seek+Read组合，性能也远不如直接ReadAt，因为锁粒度太粗 - 额外提醒：
*os.File本身是线程安全的，但它的状态（如 offset）不是 goroutine 安全的
真正复杂的地方在于：header 解析逻辑是否可重入、timestamp 是否单调、以及日志是否允许部分 record 损坏——这些没法靠 I/O 层解决，得在业务层加校验和 fallback。
