因为网络字节序（Network Byte Order）即大端序，TCP/IP、DNS、HTTP/2等协议强制要求使用binary.BigEndian；选错字节序会导致数值解析错误（如0x12345678误读为0x78563412），且BigEndian与本地CPU架构无关，是跨平台安全选择。
为什么用 encoding/binary.BigEndian 而不是小端？
网络字节序（Network Byte Order）就是大端序，TCP/IP 协议栈、DNS、HTTP/2 帧头、自定义二进制协议都强制要求用大端。Go 的 encoding/binary 提供了 BigEndian 和 LittleEndian 两种实现，选错会导致读出的 uint32 值完全错误——比如你写入 0x12345678，用小端读会变成 0x78563412。
常见错误现象：binary.Read 返回无错误但数值明显偏大/偏小，或解析协议时校验失败（如 TCP 校验和、长度字段错乱）。
- 只要协议文档写明“network byte order”或“big-endian”，就必须用
BigEndian - 本地 CPU 是 x86 或 ARM 不影响——
BigEndian是纯字节操作，与运行环境无关 - 别依赖
unsafe或math.Float64bits手动翻字节，易出错且不跨平台
binary.Write 写入结构体字段时要注意什么？
Go 结构体字段默认按内存布局排列，但 binary.Write 不会自动跳过填充字节（padding），也不会处理未导出字段。直接传 struct 可能导致写入内容包含垃圾字节或 panic。
正确做法是只写导出字段，并确保字段顺序、类型和大小严格匹配协议定义：
- 结构体所有字段必须是导出的（首字母大写）
- 避免混用不同大小整数（比如
int和int32），改用明确宽度类型：uint16、int32、uint64 - 字符串不能直接写入——
binary.Write对string类型只写长度（不是内容），需先转[]byte - 示例：写一个 4 字节长度 + 2 字节标志的包头
type Header struct {
Len uint32
Flag uint16
}
hdr := Header{Len: 1024, Flag: 0x0102}
err := binary.Write(w, binary.BigEndian, hdr) // ✅ 正确
binary.Read 读取时遇到 EOF 或部分数据怎么办？
binary.Read 在输入不足时直接返回 io.ErrUnexpectedEOF，而不是填零或截断。这对网络编程很关键——TCP 是流式协议，一次 Read 可能只收到半个包。
典型错误：把 net.Conn.Read 返回的 n 忽略，直接拿整个 buffer 交给 binary.Read，结果因数据不全而失败。
- 必须先确认 buffer 中有足够字节（例如 header 需 6 字节，就得等满 6 字节才开始 decode）
- 推荐用
io.ReadFull替代裸Read：它会阻塞直到填满 buffer 或返回 error - 对变长字段（如 payload），先读固定头，再根据
Len字段分配 buffer，再用io.ReadFull读 payload - 不要用
bytes.Buffer或strings.NewReader模拟测试——它们不会返回 partial read，掩盖真实问题
float32/float64 的网络传输要额外注意什么？
IEEE 754 浮点数在不同架构上位表示一致，但 binary.Read / Write 默认按整数方式处理 float32 和 float64——即把浮点值的内存位模式当 uint32 / uint64 来读写，这本身没问题，但容易误以为需要手动转换。
- 直接传
float32给binary.Write是安全的，Go 会自动调用math.Float32bits等做转换 - 但注意：NaN、Inf 等特殊值在网络上传输后仍保持语义，不过某些旧设备或协议可能不支持，需查规范
- 如果协议要求“用整数字段表示浮点值（如放大 100 倍存为 int32）”，那就不能用 float 类型，得手动缩放
- 示例：写
3.14作为float32
var f float32 = 3.14 err := binary.Write(w, binary.BigEndian, f) // ✅ 写出 4 字节 IEEE 754 表示
真正容易被忽略的是：浮点字段在 struct 中的位置会影响整体对齐，进而影响字节布局。哪怕你只改了一个 float32 字段，也可能让后续字段偏移，导致整个包解析失败。
