unsafe.Alignof 返回的是类型在内存中自然对齐边界（alignment）的字节数，仅取决于类型自身，与变量是否为指针无关；例如 int64 在 amd64 上为 8，int8 为 1，结构体对齐由其最大对齐字段决定。
golang中指针的对齐保证_unsafe.alignof">
Go 中 unsafe.Alignof 返回的是什么？
unsafe.Alignof 返回的是类型在内存中**自然对齐边界（alignment）的字节数**，不是结构体字段偏移或大小。它只和类型自身有关，和变量是否是指针无关——unsafe.Alignof(&x) 和 unsafe.Alignof(x) 完全不同，因为前者是对指针类型取对齐值，后者是对原类型取。
常见错误是以为“指针对齐 = 指向类型的对齐”，其实指针本身是固定大小的标量类型（通常 8 字节），其对齐就是 unsafe.Alignof((*int)(nil)) → 8，而 unsafe.Alignof(int(0)) 也是 8（64 位平台），但这是巧合，不是规则。
-
unsafe.Alignof(int8(0))是1 -
unsafe.Alignof(int64(0))在 amd64 上是8 -
unsafe.Alignof([3]uint16{})是2（由元素决定） -
unsafe.Alignof(struct{ a byte; b int64 })是8（由最大对齐字段决定）
为什么结构体字段对齐会影响 unsafe.Offsetof？
结构体字段的偏移不是简单累加；编译器会在字段间插入填充字节，使每个字段地址满足其自身的对齐要求。所以 unsafe.Offsetof(s.b) 可能远大于 unsafe.Sizeof(s.a)。
典型陷阱：手动计算结构体内存布局时忽略对齐约束，导致 unsafe.Pointer 偏移越界或读到填充字节。
立即学习“go语言免费学习笔记（深入）”；
- 字段顺序很重要：
struct{ a int64; b byte }总大小是16（b后补 7 字节）；反过来则为9 -
unsafe.Offsetof(s.b)在struct{ a byte; b int64 }中是8，不是1 - 使用
go tool compile -S或unsafe.Sizeof/unsafe.Offsetof组合验证实际布局
指针转换时对齐不满足会触发什么？
用 unsafe.Pointer 转换为某个类型指针后，如果目标地址未按该类型的对齐要求对齐，运行时可能 panic（取决于架构和 Go 版本），尤其在 ARM64 或启用 -gcflags="-d=checkptr" 时会立即报错。
错误信息类似：panic: runtime error: invalid memory address or nil pointer dereference 或更明确的 checkptr: unsafe pointer conversion。
- 不要把
*[4]byte强转为*uint32，除非确认底层数组起始地址 % 4 == 0 - 从
C.malloc分配的内存默认满足最大对齐（通常 16 字节），但自己构造的切片底层数组不一定 - 安全做法：用
unsafe.AlignedUint32Ptr这类辅助函数做对齐检查，或改用binary.Read解包
什么时候必须关心对齐？
绝大多数 Go 代码完全不用碰 unsafe.Alignof。只有在以下场景才真正需要：
- 手写序列化/反序列化逻辑，且需精确控制二进制格式（如网络协议、文件头）
- 对接 C 代码，结构体 layout 必须与 C 头文件严格一致（此时要同时看
_Alignas和#pragma pack） - 实现高性能 ring buffer、arena allocator 等底层内存管理
- 调试
invalid memory address类 panic，怀疑是未对齐访问
对齐细节高度依赖平台和编译器版本，Go 保证的只是“类型对齐 ≥ 1 且是 2 的幂”，具体数值不承诺跨版本稳定。别把它当 ABI 契约用。
