os.ReadFile读二进制文件最简单但受限于内存，仅适用于小文件；大文件必须改用os.Open+bufio.NewReader或io.CopyBuffer流式分块处理，避免OOM。
用 os.ReadFile 读二进制文件最简单，但要注意内存限制
绝大多数场景下，os.ReadFile 是首选：它直接返回 []byte，不作任何解码或换行处理，天然适合二进制数据。但它会把整个文件一次性加载进内存，所以不适合大文件（比如几百 MB 以上）。
常见错误是误用 ioutil.ReadFile（已弃用）或试图用 bufio.Scanner——后者默认按行切分、有缓冲区长度限制，读二进制会截断或 panic。
- 小文件（os.ReadFile("data.bin")
- 读取失败时检查错误是否为
os.ErrNotExist或权限问题，不是格式错误 - 返回的
[]byte可直接传给binary.Read、encoding/binary解析，或做哈希、加密等操作
大文件必须用 os.Open + io.ReadFull 分块读
当文件远超可用内存，或需流式处理（如解析固定头+变长体的协议包），就得手动控制读取节奏。关键不是“读多少”，而是“怎么保证读够”——io.Read 可能只读部分字节，而 io.ReadFull 会阻塞直到填满目标 slice 或报错。
典型场景：读一个 4 字节魔数 + 8 字节长度字段，再按长度读 payload。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 先
f, err := os.Open("large.bin")，别忘defer f.Close() - 用
io.ReadFull(f, headerBuf)读固定头，避免自己写循环判断n - 后续 payload 按需分配 buffer，仍优先用
io.ReadFull，除非明确接受不完整读取 - 注意
io.ReadFull返回io.ErrUnexpectedEOF表示文件提前结束，不是普通 EOF
binary.Read 解析结构体时字节序和对齐必须显式指定
Go 的 binary.Read 不自动推断平台字节序，也不处理 struct 字段对齐。如果文件是小端序的 uint32，却用 binary.BigEndian 读，结果就是错的；如果 struct 里混了 int 和 byte，还可能因填充字节错位。
最容易被忽略的是：Go 的 int 长度随平台变化（32/64 位），永远不要在二进制协议中用裸 int。
- 一律使用定宽类型：
uint32、int64、float64 - 字节序从协议文档确认，常见如网络协议用大端（
binary.BigEndian），Windows PE 文件用小端（binary.LittleEndian） - struct 字段间不能有空隙，必要时加
// align: packed注释提醒，或用unsafe.Offsetof校验 - 测试时用已知 hex 数据（如
[]byte{0x01, 0x00, 0x00, 0x00}）验证是否正确解析为uint32=1
内存映射（mmap）适合超大只读文件，但跨平台行为不一致
Linux/macOS 上用 golang.org/x/sys/unix.Mmap，Windows 上得走 golang.org/x/sys/windows 的 CreateFileMapping，API 完全不同。标准库不提供抽象，意味着你要自己写构建标签（//go:build !windows）和 fallback 逻辑。
适用场景其实很窄：文件 GB 级、只读、随机访问频繁（比如数据库索引文件）、且能接受 Unix-only 或维护两套实现。
- 不是所有文件系统都支持 mmap（如某些网络文件系统会失败）
- mmap 后的 []byte 不能直接传给
binary.Read（因为底层指针可能未对齐），需用unsafe.Slice或复制到新 buffer - 忘记
unix.Munmap会导致资源泄漏，且 Go 的 GC 不管理 mmap 内存 - 调试时用
cat /proc/[pid]/maps（Linux）可确认 mmap 区域是否成功建立
