必须用*os.File直接调用ReadAt，禁用bufio.NewReader包装；binary.Read解析header需字段全导出、字节序严格匹配协议、类型全为定长；所有offset运算统一用int64并校验不越界。
直接用 io.ReadAt 读指定偏移，别碰 bufio.NewReader；binary.Read 解 header 前必须确保字段导出、字节序一致、类型定宽；所有 offset 运算一律用 int64，每次调用前校验是否越界。
为什么不能用 bufio.NewReader 包裹 *os.File
*os.File 原生支持 io.ReaderAt，但套上 bufio.NewReader 后，ReadAt 就失效——它退化成顺序流，后续所有偏移跳转都会错乱。常见错误现象是 ReadAt 返回 0, nil 或随机截断，实际 offset 没生效。
- 错误写法：
reader := bufio.NewReader(file); reader.ReadAt(buf, offset)→ 总是失败或行为不可预测 - 正确做法：直接对
*os.File调用file.ReadAt(buf, offset)，中间不加任何包装 - Windows NTFS 下
ReadAt性能略低，Linux ext4/XFS 更稳；高频随机读建议预估 offset 分布做局部缓存
binary.Read 解析 header 时字段全为零或数值错乱
这不是 bug，是三个硬性条件没对齐：binary.Read 不报错，只静默跳过或错读。最常见原因是字节序、字段导出、结构体类型三者之一不匹配。
- 字节序必须和生成方严格一致：抓包看原始 hex，
00 00 00 01→ 大端 → 传binary.BigEndian；01 00 00 00→ 小端 → 传binary.LittleEndian - struct 字段名必须首字母大写（导出），小写字段如
magic uint32会被完全忽略，值永远是零值 - 禁用
int/uint等平台相关类型，改用int32、uint16等定长类型；string和[]byte会直接 panic，得用[32]byte替代
按 record 边界递进 offset 时 panic “invalid argument”
header 中的 Len 通常是 uint32，但 ReadAt 的 offset 参数是 int64；直接 int(hdr.Len) 可能溢出为负数，触发 panic。
立即学习“go语言免费学习笔记（深入）”；
- 错误写法：
nextOffset = currOffset + int(hdr.Len)→ 若hdr.Len > math.MaxInt，结果为负 - 正确写法：
nextOffset := currOffset + int64(hdr.Len)→ 统一用int64做运算 - 每次调用
ReadAt前必须检查：if nextOffset = fileSize，否则提前退出 - 用
file.Seek(0, io.SeekCurrent)获取当前绝对偏移，别靠累加Read返回字节数推算
如何安全提取第 n 位（bit）而不是第 n 字节
Go 没有“二进制位文件”类型，文件读写本质是字节流；所谓位操作，必须手动在字节层面解析——先读进内存，再拆解比特。
- 要访问第
n位（从 0 开始），先算字节索引：byteIdx := n / 8，再算位偏移：bitOffset := n % 8（注意协议是否要求 LSB-first，此时用7 - (n % 8)） - 判断该位是否为 1：
data[byteIdx] & (1 - 置 1：
data[byteIdx] |= 1 ；清 0：<code>data[byteIdx] &^= 1 （<code>&^是 Go 特有 AND-NOT，比& (^ (1 更安全） - 务必确认
data长度足够，否则越界 panic
最易被忽略的是 offset 合法性检查和 int64 强制转换——它们不出现在 happy path 里，只在文件末尾、header 损坏或 Len 字段异常时爆发，且错误信息极不直观。
