go不支持union，但可通过unsafe.pointer和struct手动实现内存重叠；需确保字段大小一致、避免指针类型、校验c布局，并承担gc不可见、越界静默错误等风险。
Go 里没有 Union，但可以用 unsafe + struct 挤出类似行为
Go 不支持 C 风格的 union，因为类型安全和内存布局控制被刻意收窄。但如果你真需要共享同一块内存、不同字段解释同一段字节（比如解析二进制协议、对接 C ABI），unsafe 是唯一路径——前提是接受失去 GC 保护、跨平台风险和维护成本。
核心思路是：定义一个 struct，所有字段从同一偏移开始，靠 unsafe.Offsetof 强制对齐；用 unsafe.Pointer 在字段间“重解释”内存。
- 必须用
//go:noescape或手动管理指针生命周期，避免逃逸导致 GC 误回收 - 字段类型大小必须一致（如全为
uint32、float32），否则读写越界静默损坏数据 -
struct不能含指针或非平凡类型（如string、slice），否则 runtime 会 panic
用 unsafe.Offsetof 手动对齐字段实现内存重叠
Go 的 struct 默认按字段顺序和对齐规则排布，要模拟 union，得让所有字段起始地址相同。最可靠方式是定义单字段 struct，再用 unsafe.Offsetof 计算偏移并强制转换：
type MyUnion struct {
_ [4]byte // 占位，确保大小为 4
}
func (u *MyUnion) AsUint32() *uint32 {
return (*uint32)(unsafe.Pointer(&u._))
}
func (u *MyUnion) AsFloat32() *float32 {
return (*float32)(unsafe.Pointer(&u._))
}
这样 AsUint32() 和 AsFloat32() 返回的指针指向同一地址，写入一个，另一个读出来就是按对应类型解释的比特值。
立即学习“go语言免费学习笔记（深入）”；
- 别直接在 struct 里声明多个字段（如
a uint32; b float32），Go 不保证它们地址重合 - 字段大小不一致时（比如混用
int64和int16），小字段读写可能只覆盖部分内存，引发未定义行为 - ARM64 和 x86_64 对浮点寄存器和整数寄存器的别名处理不同，同段内存解释结果可能不一致
对接 C union 时，用 cgo + unsafe.Sizeof 校验布局
如果目标是和 C 头文件里的 union 互操作，不能只靠 Go 端“模拟”，必须确保内存布局完全一致。关键动作是：用 cgo 导入 C union，用 unsafe.Sizeof 和 unsafe.Offsetof 双向比对。
// #include <stdint.h>
// union c_pkt {
// uint32_t id;
// float32_t val;
// };
然后在 Go 中：
var cSize = C.sizeof_struct_c_pkt
var goSize = unsafe.Sizeof(MyUnion{})
if cSize != goSize {
panic("size mismatch")
}
- C union 大小等于其最大成员大小，但 Go struct 默认含填充，需用
//go:packed（不推荐）或手动控制字段顺序+填充字节 - 用
C.GoBytes或C.CBytes转换时，务必确认源内存生命周期 —— C 分配的内存不能被 Go GC 自动管理 - 交叉编译（如 darwin/amd64 → linux/arm64）时，C union 的对齐策略可能变化，必须在目标平台验证
别忘了 unsafe 的代价：GC 不可见、无 bounds check、跨版本失效
每次用 unsafe 绕过类型系统，就等于主动放弃 Go 的一条安全带。不是不能用，而是得清楚断掉哪几根：
-
unsafe.Pointer转换后的变量，GC 完全不知道它指向哪，若原始内存被回收，后续读写就是野指针 - 数组越界、结构体字段越界访问不会 panic，只会静默读到垃圾值或 crash
- Go 1.22+ 对
unsafe使用加了更多静态检查，某些旧写法（如unsafe.Slice替代方案）已失效 - 如果只是想节省内存或做状态枚举，用
interface{}+ 类型断言或switch+reflect.Type更安全，性能差不了多少
真正需要 union 的场景极少，多数时候是协议解析或驱动层交互。一旦选了这条路，就得把内存生命周期攥在自己手里，别指望 runtime 善意兜底。
