Go 二进制协议怎么读写大端和小端整数

Go 读写二进制协议时，先把协议规定的字节序映射成 binary.BigEndian 或 binary.LittleEndian，再用对应的 Uint16/32/64 与 PutUint16/32/64 处理固定宽度字段。不要使用机器的本地字节序去猜协议，也不要把变长整数和大小端整数混为一谈。

先把字节序当成协议边界

假设协议把端口写成两字节整数 0x1234。大端字节是 12 34，小端字节是 34 12。两种排列都合法，但只能有一种符合协议。encoding/binary 中的 BigEndian 和 LittleEndian 是明确的实现，不应该用 NativeEndian 代替协议约定，因为同一份数据换到另一种架构后可能得到不同解释。

用 ByteOrder 读写固定宽度整数

直接操作切片时，最重要的是把字段宽度写清楚。下面的例子在同一块缓冲区中放入一个大端版本号和一个小端长度，读取时仍按各自字段的约定解码。

package main

import (
    "encoding/binary"
    "fmt"
)

func main() {
    buf := make([]byte, 6)

    // 版本字段占 2 字节，协议约定高位字节在前。
    binary.BigEndian.PutUint16(buf[0:2], 0x0102)
    // 长度字段占 4 字节，协议约定低位字节在前。
    binary.LittleEndian.PutUint32(buf[2:6], 1500)

    version := binary.BigEndian.Uint16(buf[0:2])
    length := binary.LittleEndian.Uint32(buf[2:6])
    fmt.Printf("bytes=% x version=%d length=%d\n", buf, version, length)
}

这里的切片范围不是装饰：Uint16 需要至少 2 个字节，Uint32 需要至少 4 个字节。解析外部输入时，先检查 len(buf)，再切片，避免短报文触发越界。

结构体和流式读写要匹配协议布局

当协议是固定布局时，可以把字段组织成只包含固定大小成员的结构体，让 binary.Read 从 io.Reader 读取。结构体中的非空白字段应为导出字段；需要占位的填充字节可以使用匿名的下划线字段。读取短报文时，完整读取失败会区分没有读到数据的 io.EOF 和读到一部分后的 io.ErrUnexpectedEOF。

type Header struct {
    Magic   uint16
    Flags   uint8
    _       uint8 // 保留一个协议填充字节，不映射到业务字段。
    Payload uint32
}

func readHeader(r io.Reader) (Header, error) {
    var h Header
    // 顺序和字节序必须与协议头定义一致。
    if err := binary.Read(r, binary.BigEndian, &h); err != nil {
        return Header{}, fmt.Errorf("读取协议头失败: %w", err)
    }
    return h, nil
}

示例中的结构体尺寸和字段顺序就是协议的一部分。若协议存在显式填充、可选字段或不同字段使用不同字节序，就不要为了省代码强行套一个结构体；可以先读取固定字段，再按字段选择对应的 ByteOrder。

变长整数不能和大小端混用

如果协议选择让较小的无符号整数占用更少字节，应使用 binary.PutUvarint、Uvarint 或流式的 ReadUvarint。这套编码不是“把 BigEndian 换成 LittleEndian”，而是另一种变长表示。

func decodeCount(buf []byte) (uint64, error) {
    value, n := binary.Uvarint(buf)
    if n == 0 {
        return 0, io.ErrUnexpectedEOF // 缓冲区还不完整，等待更多字节。
    }
    if n 

Uvarint 返回的 n 大于 0 表示成功消费的字节数，等于 0 表示输入不足，小于 0 表示溢出。需要编码负数时对应使用 Varint。不要拿 Uint32 的四字节结果去和对端的 Uvarint 逐字节比较。

发布前用字段清单复核边界

实现完成后，按字段逐项复核：字段类型和宽度是否一致，字节序是否与协议文档一致，切片范围是否覆盖且不重叠，短输入是否返回错误，变长整数是否检查了 n，结构体字段是否都是固定大小。如果协议来自外部系统，再准备一组双方都认可的十六进制样例，先比较字节，再比较解码后的数值。

真正稳定的做法不是记住“网络数据都用大端”，而是让每个字段的字节序和边界在代码中可见。这样换协议版本、增加保留字段或接入小端设备时，差异会落在明确的字段定义上。

相关问题

Go 的 binary.Read 能直接读取 string 吗？

不适合把变长字符串直接当固定大小值读取。通常先按协议读取长度，再读取指定数量的字节并转换为字符串，同时限制长度上限。

什么时候用 binary.Write，什么时候手动 PutUint32？

固定布局且字段共用同一字节序时，binary.Write 更简洁；字段字节序不同、需要精确控制偏移或希望少一次中间组织时，手动调用 PutUint32 等方法更直观。