unsafe.Pointer转换必须手动处理对齐偏移，因它仅擦除类型信息而不绕过对齐限制；若目标地址未满足unsafe.Alignof(T)要求，运行时将panic，尤其在arm64或启用race detector时立即崩溃。
unsafe.Pointer 转换时必须手动处理对齐偏移
Go 的 unsafe.Pointer 本身不绕过对齐限制——它只是“指针类型擦除”，真正绕过对齐检查的是后续用 (*T)(unsafe.Pointer(...)) 强转并解引用。但若目标地址未按 unsafe.Alignof(T) 对齐，运行时 panic（在启用 race detector 或 GC 扫描时尤其明显）。
所以所谓“绕过”，本质是：你得自己确保地址合法，或接受未定义行为风险。常见错误是直接对结构体内某个字段地址做 uintptr 加减后强转：
type S struct {
a uint16 // offset 0, align 2
b uint64 // offset 8, align 8
}
s := S{a: 1, b: 2}
p := unsafe.Pointer(&s.b) // 正确：&s.b 本身对齐
q := unsafe.Pointer(uintptr(unsafe.Pointer(&s)) + 2) // 危险：+2 后指向 a[1] 和 b 高位之间，非 8 字节对齐
x := *(*uint64)(q) // panic: misaligned 64-bit access on arm64 / race-enabled build用 uintptr 算术前必须校验对齐边界
如果真要基于 base 地址做偏移计算（比如解析二进制协议、内存映射文件），必须显式对齐目标地址。Go 标准库中 reflect.Value.UnsafeAddr 和 unsafe.Offsetof 返回的都是已对齐值，但手工算出来的 uintptr 不是。
- 先用
unsafe.Alignof(T)获取目标类型的对齐要求 - 用
(addr + align - 1) &^ (align - 1)向下对齐（常用），或addr + (align - addr%align) % align向上对齐 - 用
unsafe.Offsetof验证结构体内字段偏移是否自然满足对齐，避免假设字段紧挨着 - 注意：
uintptr运算结果不能保存为unsafe.Pointer跨 GC 周期使用，否则可能被回收
替代方案比硬写 unsafe 指针计算更安全
99% 的场景下，你并不需要手动绕对齐——而是该换方法：
- 用
encoding/binary.Read解析字节流，它内部用unsafe但做了对齐兜底和平台适配 - 用
reflect.SliceHeader+reflect.StringHeader构造视图（仍需注意底层数组对齐） - 对固定布局结构体，直接用
unsafe.Offsetof+ 字段名获取偏移，而非靠 sizeof 累加 - 若必须动态偏移，优先用
unsafe.Add(ptr, offset)（Go 1.17+），它比uintptr运算语义更清晰，且部分工具链能做基础检查
arm64 上未对齐访问会直接 crash，不是仅慢一点
x86_64 通常容忍未对齐读写（性能下降），但 arm64 默认触发 EXC_BAD_ACCESS (KERN_INVALID_ADDRESS)。Go runtime 在这类平台会立即终止程序，不给你机会 recover。错误信息形如：
panic: runtime error: invalid memory address or nil pointer dereference（实际是 SIGBUS，但被封装成 panic）
调试时用 go run -gcflags="-S" 看汇编，确认是否生成了 ldur/stur（带 unaligned 支持）还是 ldr/str（strict aligned）。后者出错就是没对齐。
真正难缠的点在于：某些结构体在不同 GOOS/GOARCH 下对齐策略不同，同一段 unsafe 代码在本地 x86_64 跑得好好的，CI 上 arm64 直接挂——这种差异往往被忽略到上线才暴露。
