unsafe.pointer 是唯一合法的指针转换桥梁，因go规范仅允许 t → unsafe.pointer → u 的显式中转，禁止直接转换以保障类型安全。
为什么 unsafe.Pointer 是唯一合法的指针转换桥梁
Go 禁止直接把 *int 转成 *float64，编译器会报 cannot convert 错误。这不是语法限制，而是类型安全机制在起作用。绕过它只有一条路径：unsafe.Pointer 必须作为中转站。
原因在于 Go 规范明确允许：*T → unsafe.Pointer → *U，但禁止 *T → *U 直接转换。这相当于给内存操作加了一道“安检门”，强制你显式声明“我要越界”。
-
uintptr不能直接转指针再长期持有——GC 可能回收其指向的内存，除非立即转回unsafe.Pointer - 用
unsafe.Pointer做中转时，必须确保源和目标内存布局兼容（比如int32和前 4 字节的[4]byte） - 跨平台时注意字节序：对
int64强制按int32解引用，结果依赖小端/大端
unsafe.Sizeof 和 unsafe.Offsetof 不是运行时函数
这两个函数在编译期求值，返回的是常量。这意味着它们可以用于数组长度声明、const 初始化，甚至 switch case 的分支条件。
但这也带来一个常见误解：有人以为 unsafe.Sizeof(x) 能反映动态分配的内存大小（比如切片底层数组），其实它只计算变量头的大小——unsafe.Sizeof([]byte{}) 永远是 24（64 位系统），和底层数组长度无关。
-
unsafe.Sizeof对结构体返回的是含填充字节的总大小，不是字段大小之和 -
unsafe.Offsetof(s.f)的s必须是结构体字面量或零值，不能是变量（否则编译失败） - 字段偏移量可用于实现反射无法访问的私有字段读写，但字段名拼错会导致偏移计算错误，无任何编译提示
用 unsafe.Slice 替代旧式 reflect.SliceHeader 手法
Go 1.17+ 推出 unsafe.Slice，专门用于从指针构造切片。它比过去靠 reflect.SliceHeader + unsafe.Pointer 手动构造的方式更安全、更直观。
旧写法容易出错：手动设置 Data、Len、Cap 字段时，若 Data 指向栈内存或已释放内存，运行时可能 panic 或静默损坏数据。
-
unsafe.Slice(ptr, len)会做基本校验（如len为负触发 panic），而旧方式完全不检查 - 不要对局部变量地址调用
unsafe.Slice——函数返回后栈内存失效，后续访问即未定义行为 - 配合
unsafe.Add定位起始地址时，确保偏移量不超过原始内存块边界，否则越界读写无提示
哪些场景真需要 unsafe，哪些只是“看起来需要”
真正值得用 unsafe 的场景极少：高频零拷贝（如 HTTP body 到 []byte）、高性能序列化库底层、与 C ABI 交互、自定义内存池。其余多数情况，是设计或 API 使用不当导致的“伪瓶颈”。
典型误用包括：为省一次 copy() 而改用 unsafe 转换字符串；用 unsafe 访问 map 内部结构试图加速遍历；或仅因“想学”就硬套案例——这些几乎都得不偿失。
- Go 1.22+ 中
string和[]byte的零拷贝转换已有标准库支持（unsafe.String/unsafe.Slice），无需手写逻辑 - 所有涉及
unsafe的代码必须加//go:nosplit注释（防止栈分裂干扰指针有效性） - CI 流程中应禁用
go vet -unsafeptr的忽略配置——它能捕获 90% 的常见误用模式
最易被忽略的点：unsafe 代码的正确性极度依赖编译器逃逸分析结果。一旦变量从栈逃逸到堆，或 GC 改变对象布局，原有指针运算就可能失效——这种 bug 往往只在高负载或特定 GC 周期才暴露。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
