用错binary.byteorder会导致解析失败，因encoding/binary不自动适配网络字节序，必须显式指定bigendian或littleendian；网络协议默认大端序，本地主机多为小端，错用将使数值完全错乱。
network.ByteOrder 用错会导致解析失败
Go 的 encoding/binary 包不自动适配网络字节序，必须显式指定 binary.BigEndian 或 binary.LittleEndian。网络协议（如 TCP/IP、HTTP/2 帧头、自定义二进制协议）默认使用大端序（即网络字节序），但本地主机几乎全是小端（x86/amd64/arm），直接用 binary.LittleEndian 解析会得到错误数值。
- 常见错误现象：
binary.LittleEndian.Uint32([]byte{0x00,0x00,0x01,0x00})返回256，而按网络协议本应是256还是65536？——实际是65536，因为网络字节序下0x00000100= 256，0x00000001才是 1；错用 LittleEndian 会让高位字节被当低位，结果完全错乱 - 写入时也一样：发送前若用
LittleEndian.PutUint32(buf, 256)，生成的是[]byte{0x00,0x01,0x00,0x00}，对方按 BigEndian 解析得65536 - 不要依赖“本地测试刚好对”，跨平台（比如和 ARM 大端设备通信）或对接 C/C++ 服务端时必崩
- 建议统一用
binary.BigEndian处理网络字段，除非协议明确要求小端（如某些 GPU 协议、Windows RPC）
string 和 []byte 互转不是字节序问题，但容易引发数据污染
string([]byte) 和 []byte(string) 不涉及字节序——因为单个 byte 没有序，string 是只读字节序列，转换只是类型重解释，不改变内存布局。
- 真正危险的是共享底层数组：比如
s := string(b)后继续修改b，s内容可能突变（尤其在 HTTP handler 中复用req.Body后又调Bytes()） - 安全做法：确定
b不会被再写，才用string(b)；否则用string(append([]byte{}, b...))拷贝一份 - 如果原始数据是二进制（非 UTF-8），转成
string后再传给fmt.Printf("%s")可能打印乱码或截断，这不是 bug，而是string语义上隐含 UTF-8；应改用fmt.Printf("%x", b)或直接操作[]byte - 不要为了“节省分配”在循环里反复做
string(b)，编译器未必优化掉逃逸，尤其当b来自堆分配时
判断主机是否小端不能靠 int 转 byte 的值
用 int32(1) 转 byte 得到 1 并不能可靠判断字节序——这只是取了最低字节，所有架构都一样；真正要测，得看多字节整数在内存中的排列。
- 正确做法：用
unsafe读取int32首字节值：var v int32 = 0x01020304; b := *(*byte)(unsafe.Pointer(&v))，若b == 0x04则为小端，b == 0x01则为大端 - 更稳妥的写法是直接用标准库方式：
binary.LittleEndian.Uint32([]byte{1,0,0,0}) == 1—— 如果成立，说明当前机器按小端解释字节，即主机是小端 - 绝大多数场景不需要手动判断：只要网络通信用
BigEndian，本地内存操作用原生int，就天然隔离了字节序差异 - 别在运行时动态切换
ByteOrder实例，binary.BigEndian和binary.LittleEndian是全局单例，线程安全，直接用即可
binary.Write / binary.Read 比手写 PutUint32 更易出错
binary.Write 看起来简洁，但隐藏了缓冲区长度检查和错误传播路径，比直接调 PutUint32 更难 debug。
- 常见坑：
binary.Write(w, order, uint32(123))要求w实现io.Writer，但如果w是bytes.Buffer，它内部增长没问题；可要是w是固定大小的io.Writer（如 socket conn），写入失败时错误被吞掉，后续读取全错 -
binary.Read同理：若传入的[]byte长度不足 4 字节，Uint32读出来是 0，且不报错——只有配合io.ReadFull才能提前发现截断 - 推荐组合：
binary.BigEndian.PutUint32(buf[off:], val)+ 显式检查len(buf) >= off+4，出错立刻 panic 或返回 error，逻辑清晰可控 - 如果必须用
Write/Read，务必检查返回 error，且确保目标io.Reader/Writer行为符合预期（比如bytes.NewReader总成功，net.Conn可能 partial write）
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
