Go中将整数转为网络字节序（大端）应使用encoding/binary包的binary.BigEndian.PutUint16/32/64方法，而非手动位移或unsafe操作；读取时用对应Uint16/32/64函数解析，注意切片长度需足够，高频场景可用sync.Pool复用字节切片。
Go里怎么把整数转成网络字节序（大端）
Go标准库不提供类似C的htonl或htons这种“名字带协议语义”的函数，但encoding/binary包直接支持按指定字节序读写——本质就是用binary.BigEndian这个预定义的binary.ByteOrder实例。
常见错误是手动位移拼接，比如uint32((v>>24)&0xff) | ...，既易错又难维护。Go的设计哲学是“用标准库做标准事”，别自己造轮子。
- 对
uint16：用binary.BigEndian.PutUint16([]byte{0,0}, v) - 对
uint32：用binary.BigEndian.PutUint32([]byte{0,0,0,0}, v) - 对
uint64：用binary.BigEndian.PutUint64([]byte{0,0,0,0,0,0,0,0}, v)
注意：目标[]byte必须长度足够，否则会panic；推荐用make([]byte, 2)等显式分配，而不是传nil切片。
为什么不能直接用unsafe或reflect强行改字节顺序
有人试图用unsafe.Pointer把uint32地址转成*[4]byte再翻转，这在小端机器上看似能work，但实际违反了Go内存模型——整数和字节数组的底层表示不是稳定可互换的，尤其在不同架构（如ARM64的某些模式）或未来Go版本中可能出问题。
立即学习“go语言免费学习笔记（深入）”；
binary包内部确实做了平台适配，但对外只暴露统一接口。你看到的BigEndian.PutUint32在x86_64上可能是优化过的内联汇编，在ARM上则是另一套逻辑，这些细节被完全封装。
- 别依赖
unsafe.Sizeof(uint32(0)) == 4以外的任何布局假设 -
reflect.ValueOf(v).Bytes()返回的是值的“编码副本”，不是内存视图，且对未导出字段行为未定义 - 即使测试通过，这类代码也极难通过静态分析工具（如
staticcheck）
从网络读取时怎么自动转回主机字节序
和服务端写入对称，客户端用binary.BigEndian.Uint16(buf)、binary.BigEndian.Uint32(buf)等函数直接解析——它们接受[]byte，返回对应类型的值，内部自动按大端解释字节。
容易踩的坑是传错长度：binary.BigEndian.Uint32([]byte{1,2})会panic，因为期望4字节；而binary.BigEndian.Uint32([]byte{1,2,3,4,5})只读前4字节，后面被忽略。
- 务必确保输入切片长度 ≥ 目标类型字节数，否则运行时报
panic: runtime error: index out of range - 如果数据来自
io.Read，建议先用io.ReadFull保证读满所需字节数，再传给binary函数 - 不要用
binary.Read包装bytes.Reader来反复读——它内部有缓冲和状态，不如直接切片操作高效
性能敏感场景下怎么避免重复分配
高频序列化（比如游戏服务器每秒几万次封包）时，反复make([]byte, 4)会产生GC压力。解决方案是复用[]byte底层数组：
- 用
sync.Pool缓存常用尺寸的切片，例如var uint32BufPool = sync.Pool{New: func() any { return make([]byte, 4) }} - 调用前
buf := uint32BufPool.Get().([]byte)，用完后uint32BufPool.Put(buf) - 注意：
Put前别让buf逃逸到其他goroutine，且不要保留对它的引用
另一个轻量级做法是预先分配一个足够大的[]byte，用buf[i:i+4]切出子切片传给PutUint32——只要不超出原始容量，就不会触发新分配。
真正需要抠性能时，字节序转换本身几乎没开销（现代CPU的bswap指令是单周期），瓶颈往往在内存分配和GC，而不是binary.BigEndian的实现。
