处理大二进制文件应分块读取，用os.Open和io.ReadFull确保读满固定长度；binary.Read解析结构化数据需注意大小端与字段对齐；bufio.Writer批量写入须Flush；mmap适用于超大文件随机访问，需手动Munmap。
用 os.Open 和 io.ReadFull 安全读取固定长度二进制块
直接用 os.ReadFile 读整个文件在处理大文件（如几百 MB 的图片、音频或自定义格式数据）时容易爆内存。更稳妥的做法是分块读取，尤其当你知道每条记录是固定字节长度（比如 1024 字节一个数据帧）时。io.ReadFull 能确保读满指定长度，避免因底层 Read 返回短字节而漏数据。
常见错误是用 io.Read 循环读但没检查返回长度，导致解析错位。例如解析一个 4 字节整数头后紧接 256 字节 payload，若头只读了 3 字节就继续往下读，整个结构就崩了。
- 打开文件务必用
os.Open（非os.Create），并检查err - 用
make([]byte, N)预分配缓冲区，N 是你要读的精确字节数 - 调用
io.ReadFull(reader, buf)；返回io.ErrUnexpectedEOF表示文件提前结束，不是普通 EOF - 对关键字段（如 magic number、长度字段）做校验，别假设文件一定合法
用 binary.Read 解析结构化二进制协议
当二进制文件有明确字段布局（如 C struct：uint32 len + uint16 type + [64]byte name），手写位移和掩码太易错。binary.Read 可以把字节流直接解包进 Go 结构体，前提是结构体字段加 binary tag 并按顺序排列。
注意大小端必须与文件一致——网络协议常用 binary.BigEndian，Windows PE 文件用 binary.LittleEndian。传错会导致数值全乱（比如 0x01000000 变成 1）。
立即学习“go语言免费学习笔记（深入）”；
- 结构体字段类型需严格匹配：int32 对应 4 字节有符号整数，uint16 对应 2 字节无符号等
- 不支持嵌套结构体或指针字段；数组用
[8]byte，切片不行 - 如果字段间有填充字节（padding），得用占位字段（如
_ [2]byte）对齐 - 示例：
type Header struct { Magic uint32 `binary:"uint32,big"` Length uint32 `binary:"uint32,big"` Flags uint16 `binary:"uint16,big"` }
用 bufio.Writer 批量写入提升二进制写性能
频繁调用 file.Write() 写小块数据（如每次写 8 字节）会触发大量系统调用，性能极差。即使只是拼接几个 []byte 后一次写，也比逐次写快 10 倍以上。
bufio.Writer 提供带缓冲的写入，但要注意：它不保证立即落盘。如果你写完立刻关文件，必须显式调用 Flush()，否则最后几 KB 数据可能丢失。
- 初始化缓冲区大小建议设为 4KB 或 64KB（
bufio.NewWriterSize(file, 64*1024)） - 写结构体时先用
binary.Write(w, order, &v)，再w.Flush() - 不要混用
file.Write()和bufio.Writer写同一个文件句柄，会冲突 - 写入失败时，
bufio.Writer的Err()方法才能拿到真实错误，Write()返回值可能为 nil
处理 mmap 场景：用 golang.org/x/sys/unix.Mmap 零拷贝访问超大文件
当文件远大于可用内存（如 2GB 日志二进制 dump），又需要随机访问某些偏移处的数据（比如跳到第 1.5GB 解析一个 header），mmap 是唯一可行方案。Go 标准库不直接支持，得借助 x/sys/unix 包。
这不是常规操作，容易踩坑：mmap 区域必须按页对齐（通常 4KB），且 Munmap 必须调用，否则资源泄漏；Windows 上要用 syscall.VirtualAlloc 替代，跨平台需条件编译。
- 只对只读场景用
unix.PROT_READ，写入需额外权限且更复杂 - 用
unsafe.Slice(unsafe.Add(unsafe.Pointer(&mmap[0]), offset), size)切出子视图，避免复制 - 务必用
defer unix.Munmap(mmap)确保释放，哪怕 panic 也要执行 - 测试时用
truncate -s 2G big.bin创建大文件，别用真实数据占满磁盘
