不能直接用[]byte(s)做零拷贝转换，因其会分配新底层数组并逐字节复制，造成GC压力和内存浪费；正确做法是unsafe.String(&b[0], len(b))或unsafe.Slice(unsafe.StringData(s), len(s))，且须确保只读、长度足够、对齐合法。
为什么不能直接用 []byte(s) 做零拷贝转换
因为 []byte(s) 会分配新底层数组并逐字节复制，对大字符串（比如几 MB 的 JSON 或日志）会造成明显 GC 压力和内存浪费。这不是语法错误，而是性能陷阱——你每次调用都在悄悄触发堆分配。
Go 1.20+ 提供了真正零拷贝的替代方案，但必须满足前提：字符串内容只读、不修改底层数组。一旦通过 unsafe 绕过检查去写它，行为未定义，可能 crash 或静默损坏数据。
-
unsafe.String(&b[0], len(b))是安全的，前提是b来自已知可读内存（如make([]byte, n)），且后续不改b -
unsafe.Slice(unsafe.StringData(s), len(s))（Go 1.21+）可反向从string得到只读[]byte，无需分配 - 别用
reflect.StringHeader手动构造——它的Data字段是uintptr，存变量就悬垂；必须在单表达式里立刻转回unsafe.Pointer
unsafe.Pointer 转结构体指针时，为什么总 panic “invalid memory address”
最常见原因是取了 slice 变量地址而非底层数组首地址：&mySlice 得到的是三字段描述符（struct{data uintptr; len, cap int}）的地址，不是数据起始位置。一解引用就踩到随机内存。
正确做法永远是 &mySlice[0] —— 这才拿到第一个元素的地址，再用 unsafe.Pointer 桥接过去。但还得确认长度够、对齐合法。
立即学习“go语言免费学习笔记（深入）”；
- 结构体字段偏移不能手算，必须用
unsafe.Offsetof(u.field)；加个字段或换 Go 版本，偏移可能变 - 目标结构体大小不能超过可用字节数：
len(myBytes) >= unsafe.Sizeof(MyStruct{}) - 若结构体含
int64等强对齐字段，要检查起始地址是否满足uintptr(unsafe.Pointer(&b[0])) % unsafe.Alignof(int64(0)) == 0
把 []byte 当作 []int32 用，为什么下标 1 就越界
因为 slice 头部的 len 和 cap 单位是“元素个数”，不是字节。原 []byte 长度为 12，len 就是 12；强行 reinterpret 成 []int32 后，若不重设头部，Go 仍按 12 个 byte 解释长度，访问 i32s[1] 实际读第 4–7 字节，但 runtime 认为索引 1 ≥ len 12？不，它认为 len 是 12 个 int32，所以报 index out of range [1] with length 12 —— 这说明你没改头，只是指针类型变了。
- 必须用
reflect.SliceHeader显式构造新头：Len = len(b) / 4（假设int32占 4 字节），且向下取整 -
Cap同理，且不能超过len(b) / 4；别设更大值，否则写越界 - Go 1.17+ 推荐用
unsafe.Slice((*int32)(unsafe.Pointer(&b[0])), len(b)/4)，更简洁且自动校验长度
uintptr 存成字段或全局变量为什么危险
uintptr 是纯整数，GC 完全不认它指向哪。如果你把它赋给 struct 字段、包级变量，或传进 goroutine 长期持有，原始对象（比如局部 []byte）一旦被回收，这个 uintptr 就变成悬垂地址——下次转回 unsafe.Pointer 解引用，大概率 crash 或读垃圾值。
- 唯一安全用法：仅在单个表达式内临时计算，例如
(*int32)(unsafe.Pointer(uintptr(unsafe.Pointer(&x)) + unsafe.Offsetof(x.field))) - 系统调用场景例外：
syscall.Syscall(SYS_READ, uintptr(fd), uintptr(unsafe.Pointer(p)), ...)，OS 内核会当场用它，不跨调度周期 - 反射返回的
Pointer()或UnsafeAddr()也是uintptr，必须立即转unsafe.Pointer，不能存、不能传参、不能做算术后缓存
所有这些约束不是为了刁难你，而是 Go 在“允许绕过类型系统”和“不让程序轻易崩掉”之间划出的硬边界。越靠近底层，越得自己扛对齐、生命周期、内存有效性这三件事。
