Go 的 binary.Write 必须显式指定字节序（如 binary.LittleEndian），结构体字段需导出，切片元素类型须固定大小，变长数据需手动处理长度前缀与字节写入。
binary.Write 写二进制时字节序必须显式指定
Go 的 encoding/binary 不自动猜字节序，写入前必须明确选 binary.LittleEndian 或 binary.BigEndian。漏掉这个参数会直接 panic：panic: binary.Write: invalid type int——因为 binary.Write 要求第二个参数是 io.Writer，第三个必须是可编码的值，但更常见的是传错第一个参数（即 endian）。
常见错误场景：想把一个 int32 写进文件，却写了 binary.Write(file, 123)，实际应为：
err := binary.Write(file, binary.LittleEndian, int32(123))
- 结构体字段必须是导出字段（首字母大写），否则
binary.Write会忽略它且不报错 - 写入切片时，
binary.Write只处理元素类型为固定大小的（如[]int32），不支持[]string或[]interface{} - 如果目标是网络传输或跨平台读取，优先用
binary.BigEndian（即网络字节序），避免接收端解析错位
binary.Read 读不到预期值？检查缓冲区长度和对齐
binary.Read 不会自动跳过填充字节或处理结构体内存对齐。它严格按类型大小逐字节读，如果文件里多写了、少写了、或结构体字段顺序/大小和写入时不一致，结果就是值错乱甚至 io.ErrUnexpectedEOF。
例如写入时用了 struct{ A int32; B byte }（共 5 字节），但读取时定义成 struct{ A int32; B uint16 }（期望 6 字节），就会卡在第 5 字节后报 EOF。
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 读之前务必确认文件当前 offset 正确，可用
file.Seek(0, io.SeekStart)重置 - 读取结构体前，建议先用
binary.Size(&v)算出预期字节数，再用file.Stat()检查文件长度是否足够 - 避免直接读
*int这类指针变量；binary.Read需要地址，但传&someInt即可，别传&&someInt
处理变长数据（比如字符串）得自己拆解
encoding/binary 原生不支持字符串、slice 头部带长度的变长格式。它只认固定大小类型：基本数值、数组、导出结构体（且所有字段固定大小）。想存一个带长度前缀的字符串，得手动写长度再写字节：
binary.Write(w, binary.LittleEndian, uint32(len(s))) w.Write([]byte(s))
读的时候也得反着来：
var length uint32 binary.Read(r, binary.LittleEndian, &length) buf := make([]byte, length) r.Read(buf) s := string(buf)
- 字符串编码需提前约定（通常是 UTF-8），不处理编码转换
- 长度字段类型（
uint16/uint32）必须和写入时一致，否则后续全部偏移 - 如果协议里字符串可能为空，
length == 0时仍要调用r.Read(buf)（此时buf是空切片，安全）
性能敏感场景别反复打开/关闭文件
每次调用 os.OpenFile + binary.Write + Close 会有明显 syscall 开销。高频写二进制日志或序列化数据时，保持文件句柄复用更稳。
- 用
os.O_CREATE | os.O_WRONLY | os.O_APPEND打开一次，后续所有binary.Write都追加到底部 - 注意：
binary.Write不自带缓冲，大量小写入建议包一层bufio.NewWriter，但得记得Flush() - 并发写同一文件？别直接共享
*os.File，加锁或改用 channel + 单 goroutine 序列化写入
字节序、结构体定义、变长逻辑这三处一旦不匹配，读出来就是完全不可预测的数字——不是程序崩，而是静默错，查起来最花时间。
