binary.Write() 仅对固定大小的整数类型（如 uint16、int32）应用字节序转换，而对 []byte 类型直接原样写入，不进行任何字节序调整——这是由其设计语义决定的，而非 bug。
`binary.write()` 仅对固定大小的整数类型（如 `uint16`、`int32`）应用字节序转换，而对 `[]byte` 类型直接原样写入，不进行任何字节序调整——这是由其设计语义决定的，而非 bug。
在 Go 的 encoding/binary 包中，binary.Write() 的核心职责是将 Go 值序列化为平台无关的二进制流，其字节序（binary.LittleEndian 或 binary.BigEndian）仅作用于可明确解析为多字节整数的类型，例如 uint16、int32、uint64 等。这些类型的内存布局依赖字节序：例如 uint16(256)（即 0x0100）在小端模式下写为 [0x00, 0x01]，大端模式下为 [0x01, 0x00]——binary.Write() 自动完成该转换。
但 []byte 是一个字节容器，而非数值类型。它本身不携带“数值含义”或“长度语义”，binary 包无法也不应假设其内容应被解释为某种整数数组（如 []uint16）或需整体翻转。试想：若传入 []byte{0,1,2,3,4,5}，binary 包无法判断你期望的是：
- 按
uint16分组翻转 →[1,0,3,2,5,4]， - 按
uint32分组翻转 →[3,2,1,0,5,4,?,?]（长度不足）， - 还是简单地整个切片逆序 →
[5,4,3,2,1,0]？
因此，binary.Write() 对 []byte 的处理策略是零变换（no-op）：直接按原始顺序写入每个字节，忽略传入的 endian 参数。这正是你示例中输出 [0,1,0,1] 的原因——两个 []byte{0,1} 均被原样写入，字节序参数完全无效。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
✅ 正确做法：若需对字节切片应用特定字节序（例如将其视为 []uint16 并逐项小端写入），应显式转换类型或手动处理：
// 示例：将 []uint16 切片按 LittleEndian 写入
data := []uint16{0x0100, 0x0200} // 即 {256, 512}
buf := new(bytes.Buffer)
for _, v := range data {
binary.Write(buf, binary.LittleEndian, v) // ✅ 正确：对每个 uint16 应用字节序
}
// 结果：[0x00,0x01, 0x00,0x02]
// 若你确实有一段原始 []byte 且需“整体反转”（非常规需求）
raw := []byte{0, 1, 2, 3}
reversed := make([]byte, len(raw))
for i, b := range raw {
reversed[len(raw)-1-i] = b
}
// reversed == []byte{3,2,1,0}⚠️ 注意事项：
- 不要依赖
binary.Write(b, endian, []byte{...})触发字节序转换——它永远不会生效； - 对复合结构（如
struct），binary.Write()会递归处理每个字段，仅对其中的整数字段应用字节序，[]byte字段仍原样写入； - 如需高性能批量写入整数切片，推荐使用
binary.Write()循环，或预分配[]byte后用binary.PutUint16()等函数填充。
总之，[]byte 的“无字节序”行为是 encoding/binary 保持语义清晰与类型安全的设计选择。理解这一点，就能避免误用，并在需要时选择恰当的手动转换策略。
