unsafe.Pointer 转 *T 时必须确保类型对齐和内存有效
Go 的 unsafe.Pointer 本身不携带类型信息，转成具体指针（如 *int64）后，运行时不会校验目标地址是否真能存下该类型。一旦越界、未对齐或指向已释放内存，程序可能直接崩溃或读到垃圾值。
- 常见错误现象：
panic: runtime error: invalid memory address or nil pointer dereference或静默返回错误数值 - 使用场景：只应在明确知道底层内存布局时用，比如解析二进制协议、与 C 交互、高性能字节切片重解释（如把
[]byte当作[]uint32批量处理） - 关键检查点：目标地址必须满足
uintptr(ptr) % unsafe.Alignof(T{}) == 0；长度需 ≥unsafe.Sizeof(T{}) - 示例（安全转换）：
data := make([]byte, 8) header := (*reflect.SliceHeader)(unsafe.Pointer(&data)) // 注意：这里只是取 header，不是 reinterpret 内容
slice 头部重解释必须手动控制 len/cap，不能只改指针
把 []byte 强转为 []int32 看似方便，但 Go 的 slice 是三元组（ptr, len, cap），unsafe.Pointer 只能改 ptr，len/cap 仍按原类型解释 —— 不手动修正就会导致越界读写。
- 常见错误现象：
index out of range [1] with length 1（实际想访问第 1 个int32，但 len 还是按 byte 算的） - 正确做法：用
reflect.SliceHeader构造新头，且确保新len≤ 原字节数 / 新元素字节数 - 参数差异：
len单位是元素个数，不是字节数；cap同理，且不应超过可用字节上限 - 示例：
b := make([]byte, 12) // 转为 []int32，最多 3 个元素 hdr := reflect.SliceHeader{ Data: uintptr(unsafe.Pointer(&b[0])), Len: 3, Cap: 3, } i32s := *(*[]int32)(unsafe.Pointer(&hdr))
uintptr 不能长期保存，仅限单次转换链中临时使用
uintptr 是整数，GC 不会追踪它指向的内存。如果把它存成全局变量、结构体字段或传入 goroutine 长期持有，原始对象被回收后，这个 uintptr 就变成悬垂地址。
- 常见错误现象：程序偶发 panic 或数据错乱，尤其在 GC 触发后
- 使用场景：仅限函数内“指针 → uintptr → unsafe.Pointer”这一条链，中间不能断开或存储
- 性能影响：看似绕过类型检查能提速，但滥用会导致不可预测的内存错误，调试成本远高于收益
- 绝对禁止：
var badPtr uintptr = uintptr(unsafe.Pointer(&x))（跨语句生命周期）
与 C 函数交互时，C 字符串需显式管理生命周期
Go 的 C.CString 分配的是 C 堆内存，Go 侧无所有权；而 (*C.char)(unsafe.Pointer(&s[0])) 指向的是 Go 的底层数组 —— 如果该 slice 是局部变量或后续被修改/回收，C 侧再访问就是野指针。
立即学习“go语言免费学习笔记（深入）”；
- 常见错误现象：C 函数返回后，Go 侧 slice 被 GC，C 回调时 crash
- 正确选择：
C.CString+defer C.free（适合短时传递）；或用C.CBytes配合C.free（适合二进制数据） - 兼容性注意：Windows 下
C.CString用LocalAlloc，Linux/macOS 用malloc，都需对应C.free - 示例：
s := "hello" cstr := C.CString(s) defer C.free(unsafe.Pointer(cstr)) // 必须配对 C.some_c_func(cstr)
