Go binary 为什么读出的整数大小端反了

Go binary 读出的整数像是大小端反了，首先应核对协议规定的字节序，而不是按本机 CPU 选择 NativeEndian。BigEndian 与 LittleEndian 会把同一串字节解释成不同数值；如果字段偏移、宽度或读取长度已经错了，换端序也只能偶然得到一个“看起来合理”的结果。

binary 官方文档：https://pkg.go.dev/encoding/binary

完整读取官方文档：https://pkg.go.dev/io#ReadFull

先保留原始字节，不急着反转

排查的第一份材料应是协议说明与字段对应的原始字节，而不是已经转成十进制的异常数字。四个互不相同的字节比全零、全 FF 或对称值更适合作为样本：后一类数据可能掩盖错误。

// 独立片段：需要 encoding/binary 和 fmt，在函数中使用。
// 保留同一份四字节样本，对照两种解释，不对原数据做反转。
raw := []byte{0x12, 0x34, 0xAB, 0xCD}
be := binary.BigEndian.Uint32(raw)
le := binary.LittleEndian.Uint32(raw)
fmt.Printf("原始=% X 大端=%08X 小端=%08X\n", raw, be, le)

按位权计算，这个样本的大端结果应为 1234ABCD，小端结果应为 CDAB3412。这是示例预期值，不是本机运行记录。若实际读取的字节根本不是这四个，先回到数据边界，不要通过反转整个报文来“修复”一个字段。

按协议确定字节序和字段宽度

端序描述多字节值中高低位与字节位置的对应，字段宽度则决定消耗几个字节；有符号解释又是另一层。拿 uint16 读四字节字段、拿 uint32 读取偏移后不足四字节的切片、把有符号数当无符号数展示，表现并不相同。

将原始字节、ByteOrder、Uint32、字段宽度、字段偏移与协议说明分别记录，才能确定一条解码规则。ByteOrder 决定解释方式，字段宽度约束 Uint32 所需字节数，字段偏移决定传入的切片位置；协议说明负责约束这些选择。计算机的原生端序不应替代外部文件或网络协议的约定。

固定宽度整数也不能与变长整数混用。若协议使用 Uvarint、Varint 或 ASCII 数字文本，就应采用对应编码规则，不能任取四个字节交给 Uint32。协议中每个字段也未必共用相同端序，必须以它自己的定义为准。

把解码入口固定到一份头部定义

下面人为定义一个简单示例头部：偏移 0 的两字节是大端标记 6C 39，偏移 2 的两字节是长度，偏移 4 的四字节是序号，全部为无符号大端整数。它不是某个现成设备的真实协议；字段定义先明确，代码才有可对照的依据。

package main

import (
    "bytes"
    "encoding/binary"
    "fmt"
    "io"
    "os"
)

type Header struct {
    Length   uint16
    Sequence uint32
}

func readHeader(r io.Reader) (Header, error) {
    var raw [8]byte
    // 固定八字节头部必须读齐，失败时不解释半份头部。
    if _, err := io.ReadFull(r, raw[:]); err != nil {
        return Header{}, fmt.Errorf("读取头部: %w", err)
    }
    if binary.BigEndian.Uint16(raw[0:2]) != 0x6C39 {
        return Header{}, fmt.Errorf("头部标记不匹配")
    }
    h := Header{
        Length:   binary.BigEndian.Uint16(raw[2:4]),
        Sequence: binary.BigEndian.Uint32(raw[4:8]),
    }
    // 示例自行约定上限，避免把异常长度直接用于大块分配。
    if h.Length > 4096 {
        return Header{}, fmt.Errorf("长度超出示例上限: %d", h.Length)
    }
    return h, nil
}

func main() {
    // 人工字节样本与上述字段定义独立对照，不依赖本机端序。
    sample := []byte{0x6C, 0x39, 0x00, 0x05, 0x12, 0x34, 0xAB, 0xCD}
    h, err := readHeader(bytes.NewReader(sample))
    if err != nil {
        fmt.Fprintln(os.Stderr, err)
        os.Exit(1)
    }
    fmt.Printf("长度=%d 序号=%08X\n", h.Length, h.Sequence)
}

按定义，长度应为 5，序号应为 1234ABCD。函数只读取头部，不读取五字节负载，因此这个样本不是“完整报文已接收”的证据。后续读取负载时仍须在资源约束下读齐并处理错误；真实协议还可能有校验、版本和连接超时要求。

短读与偏移错误怎样区分

普通 Reader 的一次 Read 不保证填满缓冲区。若忽略返回的 n 和 err，就可能把未填入的数据也交给解码器。ReadFull 用于固定长度块：没有读到数据时可能是 EOF，已经读到部分又结束时是 UnexpectedEOF。这些应作为读取失败返回，不能算作合法零值字段。

Uint32 等便捷方法要求切片有足够字节；应先保证长度再调用，不能把潜在越界交给上层业务碰运气。binary.Read 则需要固定大小的数据目标，并通过 error 报告读取问题；换成它也不会自动猜出协议的端序。

结构体的本机内存布局不能直接当成协议布局。若采用 binary.Read 读取结构体，也应按固定宽度字段定义协议，并明确保留字节；不要用 unsafe 或 sizeof 推导跨平台报文长度。对混合端序字段，逐字段解码通常更容易表达真实规则。

编码回环为什么不能独自证明正确

编码后再解码得到原值，是有价值的自洽性判断，但发送与接收两边若一起用了错误端序，回环仍然可能通过。应另外保留协议提供或人工按位权算出的黄金字节样本，确认真实线上的表示，不把“同一个实现能读回自己”当成互通保证。

例如本例的四字节序号，协议期望的是 12 34 AB CD。用 LittleEndian 编码后再用 LittleEndian 解码可以回到同一个数值，却不会生成这组约定的字节。自洽与符合外部协议是两类判断。

把字节样本和失败原因一起保留

把解码失败分成读取失败、标记不符、字段范围错误与业务不接受，自动任务就能决定是等待数据、拒绝报文还是停止处理。记录时至少携带字段名、偏移、预期宽度及有限长度的字节摘要；不要为排错把完整业务载荷、凭据或隐私数据打入日志。

小端机器上必须用 LittleEndian 吗？ 不需要。读取外部格式应服从协议，选择 BigEndian 不会因为机器是小端就自动反转两次。

能先反转整个 byte 切片再解码吗？ 对多字段报文通常不对。这样会同时打乱字段位置，尤其不能处理字符串、标记和不同宽度字段。

网络协议是不是都用大端？ 不能一概而论。某些格式约定大端，另一些约定小端或逐字段混合，编码规则应从目标协议取得。

可靠的解码入口应把“读齐、切对、按约定解释、处理异常”写成明确责任。本文给出原创示例与预期推导，未在本地运行正文代码或测试；实际接入时请用自己协议的真实样本对应这些边界。