应分步解析大二进制日志：先用os.Open+io.ReadAt按需读取，再用binary.Read解析固定头获取长度，最后按需读取变长载荷；严禁一次性加载或直接解析嵌套结构。
直接读整个文件会 OOM，binary.Read 不能解析嵌套结构或变长字段，必须分步控制解析流程。
用 os.Open + io.ReadAt 随机读取大日志
几百 MB 或 GB 级二进制日志不能用 os.ReadFile，它会一次性把全部内容加载进内存，触发 OOM。正确做法是用 os.Open 打开后，靠 io.ReadAt 按需读指定 offset 和长度的字节块。
-
os.File实现了io.ReaderAt，支持ReadAt([]byte, int64)；别用bufio.NewReader包裹它——那会让随机读失效 - 每次调用
ReadAt前，检查 offset 是否 ≥ 0 且 ≤ 文件大小，避免"invalid argument"panic - Windows NTFS 下大文件
ReadAt性能略差，Linux ext4/XFS 更稳
binary.Read 只能读扁平结构体，别传嵌套或 slice
binary.Read 仅支持无指针、无 interface{}、无 []byte、无 padding 的纯字段序列。一旦结构体含 Data []byte 或嵌套 struct，它不会报错，但字段值会全乱。
- 安全可读的示例：
type Header { Magic uint32; Len uint32; Ts uint64 } - 含变长字段时，先用
binary.Read解 header 拿到Len，再用io.ReadFull单独读 payload - 字段名必须首字母大写（导出），类型大小必须和二进制布局严格一致（如不用
int，而用int32）
复杂元数据需手动分段解析，不是一次 binary.Read 能搞定的
所谓“复杂元数据”，常见于带 TLV、嵌套块、动态 schema 的日志：比如 header 后跟一段 JSON blob，或一个 tag-length-value 序列。这种结构无法靠单个 struct 描述，必须拆解为多步。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 第一步：用
binary.Read解固定头，拿到 type/length/offset 等元信息 - 第二步：根据 type 查表确定子结构格式，再构造对应 struct，用
binary.Read(bytes.NewReader(payload), endian, &sub)解析 - 第三步：若 payload 含字符串，先读 length 字段，再用
buf.Next(int(length))提取原始字节，避免越界 - 每步都要检查
io.ErrUnexpectedEOF—— 它比普通io.EOF更危险，说明数据截断或 offset 错了
位移运算统一用 int64，别用 int 加 uint32
日志 record 是连续拼接的，靠 header 中的 Len 字段跳到下一条起点。但 Len 是 uint32，ReadAt 的 offset 是 int64，中间转换极易溢出。
- 错：
nextOffset = currOffset + int(hdr.Len)→ 若hdr.Len > math.MaxInt32，int 溢出变负数，ReadAtpanic - 对：
nextOffset := currOffset + int64(hdr.Len) - 每次递进前加校验：
if nextOffset > fileSize { break }
最易被忽略的是：binary.Read 不报错 ≠ 解析正确。字段对齐、大小端、padding、未初始化 slice —— 任一不匹配都会导致静默错位，后续所有解析全崩。必须每步验证关键字段（如 magic number、checksum）才敢往下走。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
