应使用os.open配合io.readat实现大日志文件随机读取，避免os.readfile导致oom；用binary.read解析header确保大小端正确并校验错误；位移计算统一用int64防溢出，且每次readat前检查offset合法性。
用 os.Open + io.ReadAt 实现精确位移读取
处理大型二进制日志或索引文件时，不能靠 os.ReadFile 加载全量数据——几百 MB 就可能触发 OOM。核心解法是跳过「读进内存再解析」这步，直接按需定位读取。
os.File 本身实现了 io.ReaderAt 接口，支持 ReadAt([]byte, int64)，能从任意 offset 开始读指定长度字节块。这个调用不依赖内部缓冲，也不破坏随机性。
- 别用
bufio.NewReader包裹*os.File——它会把随机读变成顺序流，后续ReadAt失效 - Windows NTFS 下大文件
ReadAt性能略弱，Linux ext4/XFS 更稳；若跨平台部署，建议压测验证 - 示例：
file.ReadAt(buf, 1024)表示从第 1024 字节（0-based）开始读len(buf)字节，返回实际读取数和 error
binary.Read 解析 header 时必须校验大小端与字段对齐
很多二进制格式在 record 开头放固定 header（如 8 字节 magic + 4 字节 length），手动拆解 buf[0]、buf[4] 易出错且难维护。用 binary.Read 直接映射到 struct 最安全，但前提是字段布局和字节序完全匹配。
- struct 字段必须导出（首字母大写），类型严格对应：比如文件里是 uint32，Go 里就得用
uint32，不能用int32 - 大小端选错会导致数值全乱：
0x01000000在binary.LittleEndian下解析成 1，而BigEndian下才是 16777216 - 字段间若有 padding（比如 C struct 对齐填充），需用占位字段，例如
_ [2]byte，否则解析偏移错位 - 务必检查
binary.Read返回的 error：io.ErrUnexpectedEOF常见于 buf 长度不够或 offset 越界
递进 offset 时用 int64 运算防溢出
日志类二进制文件常靠 header 中的 Len 字段跳转下一条记录起点。但 Len 通常是 uint32，而 ReadAt 的 offset 是 int64，中间转换极易踩坑。
- 错误写法：
nextOffset = currOffset + int(hdr.Len)—— 若hdr.Len > math.MaxInt32，int()强转会溢出为负数，ReadAt直接 panic “invalid argument” - 正确做法：统一用
int64运算，nextOffset := currOffset + int64(hdr.Len) - 每次调用
ReadAt前必须校验：if nextOffset = fileSize，避免越界 panic
大文件写入用 bufio.Writer 但别忘了 Flush
批量写二进制数据（比如拼接多个 record 后落盘）时，频繁调用 file.Write 会引发大量系统调用，性能极差。用 bufio.Writer 缓冲后一次刷盘，快 10 倍以上。
- 初始化建议设缓冲区大小：
bufio.NewWriterSize(file, 64*1024)（64KB），比默认 4KB 更适配二进制块写入 -
bufio.Writer不保证立即落盘——写完立刻file.Close()而不Flush()，最后几 KB 数据会丢失 - 如果写入过程有异常中断，
Flush()可能失败，需单独处理其返回 error，不能只依赖 defer
随机访问的核心不是“怎么读”，而是“读哪里”和“读完怎么跳”。offset 计算、大小端、padding、buffer 管理这四点漏掉任何一个，解析就会错位，且问题往往延迟暴露——等你发现时，可能已经处理了几万条 record。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
