cross-compile后binary.Read读错数值，根本原因是字节序必须严格匹配协议而非CPU架构，且Go结构体字段对齐与C端padding不一致、未导出字段被跳过、使用平台相关类型（如int）导致字段错位。
Go 模块本身没有字节序差异——字节序只发生在 binary.Read 和 binary.Write 读写二进制数据时，与模块是否跨平台无关；真正容易出错的是你写的解析逻辑在不同 GOOS/GOARCH 下仍用错 binary.BigEndian 或 binary.LittleEndian。
为什么 cross-compile 后 binary.Read 还读错数值？
交叉编译（如 GOOS=linux GOARCH=arm64 go build）不改变字节序行为。Go 的 binary 包始终要求你显式传入字节序，它不会根据 GOARCH 自动切换。常见误判是：“ARM64 是小端，所以协议也该用小端”——但协议定义才是唯一依据，不是 CPU 架构。
- 网络协议（TCP/IP、HTTP、PNG、ELF）几乎全是大端 → 固定用
binary.BigEndian - Windows API、x86/x64 本地生成的二进制、多数嵌入式传感器帧默认小端 → 用
binary.LittleEndian - 抓包看原始 hex：若前 4 字节是
00 00 00 0A对应值为 10，则是大端；若为0A 00 00 00，则是小端 -
runtime.GOARCH和unsafe.Sizeof都不能替代协议文档或抓包验证
结构体字段在交叉编译后读写错位怎么办？
Go 结构体字段对齐规则由编译器决定，但 binary.Read 完全无视 padding，只按字段声明顺序和类型大小逐字节读取。C 端 struct 若有 #pragma pack(1) 或含填充字段，Go 端必须手动对齐，否则字段偏移全乱。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 所有字段必须首字母大写（导出），否则
binary.Read跳过，值保持零值 - 禁用
int/uint——它们长度平台相关，binary.Read直接报binary: invalid type int；改用int32、uint16等固定宽度类型 - C 端有 2 字节 padding？Go 端写成
_ [2]byte，不能用两个uint8替代 - 用
unsafe.Sizeof(YourStruct{})校验结构体总长是否与协议一致；用unsafe.Offsetof(s.Field)核对关键字段偏移
混用大小端字段时，struct 不能一把梭
binary.Read 不支持为 struct 中不同字段指定不同字节序。如果协议里时间戳用大端、校验和用小端，强行塞进一个 struct 并统一传 binary.BigEndian，后者就错。
立即学习“go语言免费学习笔记（深入）”；
- 必须拆成多步：
binary.Read(r, binary.BigEndian, &header.Timestamp)，再binary.Read(r, binary.LittleEndian, &header.Checksum) - 别试图用反射自动识别字段 tag（如
binary:"big"）——标准库无此支持，得自己遍历字段 + 手动分发binary.Read - 切片（
[]byte）、string、map类型无法直接用binary.Read，变长字段一律先读长度，再手动切片 - 写入前用
io.ReadFull(r, buf[:n])确保读满整包，TCP 粘包必须在binary.Read前解决
最隐蔽的坑不是编译失败，而是读出来值“看起来合理但不对”——比如时间戳差 8 小时、长度字段刚好是 256 倍关系，这往往是字节序或 padding 错了一位。动手前先用 xxd -c 1 file.bin | head -n 8 看原始字节，比猜架构、查文档更快。
