Go中打开二进制文件需用os.Open（只读）或os.Create（写入），避免bufio.Scanner等文本解析工具，直接使用file.Read/io.Copy等原始字节操作，并注意路径跨平台、错误判别（如io.ErrUnexpectedEOF）、及时关闭文件及必要时调用Truncate扩容。
用 os.Open 和 os.Create 打开二进制文件时要注意什么
Go 默认不区分文本和二进制，但读写二进制文件时必须跳过任何编码/换行转换——这点和 Python 的 "rb"/"wb" 模式类似，只是 Go 不需要显式声明模式。关键在于：别用 bufio.Scanner 或 fmt.Fscanf，它们会按行或按格式解析，破坏原始字节。
-
os.Open返回的*os.File是原始字节流，直接配合io.ReadFull、io.Copy或file.Read使用最安全 - 写入时优先用
os.Create（而非os.OpenFile带os.O_CREATE|os.O_TRUNC），避免权限或标志误配导致覆盖失败或静默截断 - Windows 下路径含反斜杠时，用
filepath.Join构造路径，别硬拼"\ "，否则在跨平台编译时可能 panic
读取固定长度结构体（如 ELF 头）该用 binary.Read 还是手动 copy
如果二进制格式有明确字段偏移和大小（比如前 4 字节是魔数、接着 2 字节是架构标识），binary.Read 更简洁；但如果要跳过中间字段、或字段长度动态（如字符串长度存前 1 字节），手动 copy + 切片更可控。
-
binary.Read要求结构体字段带binarytag（如Arch uint16 `binary:"uint16"`），且必须严格对齐字节序（binary.LittleEndian或binary.BigEndian） - 手动读取示例：
buf := make([]byte, 8); n, _ := file.Read(buf); magic := binary.LittleEndian.Uint32(buf[:4]) - 注意
binary.Read在读到 EOF 时返回io.ErrUnexpectedEOF，不是io.EOF，别用errors.Is(err, io.EOF)判断是否读完
io.Copy 直接复制大文件时为什么偶尔出错
io.Copy 本身可靠，但常见问题来自上下文：源文件被其他进程锁定（Windows）、目标磁盘满、或未关闭文件句柄导致后续操作失败。
- 复制后务必检查
io.Copy返回的n, err：若err == nil但n小于预期大小，说明读取提前终止（比如源文件被截断） - 不要省略
defer src.Close()和defer dst.Close()，尤其在循环处理多个文件时，不关闭会导致too many open files - 若需校验完整性，复制后立即用
sha256.Sum256计算源和目标的哈希，别依赖n值判断成功
处理 mmap 场景下的内存映射文件（如日志分析）该选 golang.org/x/exp/mmap 还是系统调用
标准库不提供 mmap，官方 x/exp/mmap 是实验性包，已多年未更新，生产环境建议用 github.com/edsrzf/mmap-go（维护活跃、支持 Windows/Linux/macOS）。
立即学习“go语言免费学习笔记（深入）”；
- 用 mmap 读大文件比
os.ReadFile内存占用低，但写入需设mmap.RDWR标志，且修改后要调用Unmap才能确保落盘 - 映射区域超出文件当前大小时，Linux 允许写入但会触发
SIGBUS，需先用ftruncate扩容（Go 中通过file.Truncate实现） - Windows 下
mmap映射失败时错误信息是"The operation completed successfully."（没错，这是 Windows API 的经典 bug），实际应检查err != nil后再看uintptr(0)是否为返回地址
io.ErrUnexpectedEOF 当成普通错误吞掉，结果解析一半的结构体就继续往下跑；还有 mmap 场景下忘记 Truncate 导致写入越界崩溃。这些都不是语法问题，而是和操作系统交互时的隐性契约。 
