Go编译器禁止(int)(unsafe.Pointer(&x))，因unsafe.Pointer须经uintptr或byte桥接，强制校验对齐、生命周期等；正确链为&x→unsafe.Pointer→uintptr→unsafe.Pointer→*int。
为什么 (*int)(unsafe.Pointer(&x)) 会编译失败
Go 编译器明确禁止 (*int)(unsafe.Pointer(&x)) 这种写法——它不是疏忽，而是类型系统主动拦截。unsafe.Pointer 不能直接转成任意指针类型，必须经由 uintptr 或 *byte 中间桥接。这不是语法糖缺失，是防止你跳过对齐、生命周期、内存布局等关键校验的强制关卡。
常见错误包括：
-
*(int)(unsafe.Pointer(&x))：试图把指针当整数解引用，类型不匹配，编译报错 -
(*int)(unsafe.Pointer(uintptr(&x)))：&x是*T类型，不能直接转uintptr；必须先转unsafe.Pointer，再转uintptr
正确链条只有一条：&x → unsafe.Pointer → uintptr → unsafe.Pointer → *int。少任何一环，编译器就拒绝放行。
切片转结构体时 &slice[0] 和 &slice 的区别
这是最常引发 panic 的误用点。&slice 拿到的是 slice header（含 len/cap/data 三字段）的地址，不是底层数组内存起始位置；而 &slice[0] 才真正指向数据首字节。
立即学习“go语言免费学习笔记（深入）”；
错误写法：(*Point)(unsafe.Pointer(&buf)) —— 覆盖的是 header 内存，后续访问 buf 可能直接崩溃。
正确前提有三个：
- 必须用
&buf[0]，且buf长度 ≥ 目标结构体大小（unsafe.Sizeof(Point{})） - 若
buf是局部变量切片，其底层数组可能被 GC 回收，需确保它是堆分配（如make([]byte, n)）或加runtime.KeepAlive(buf) - Go 1.17+ 推荐改用
unsafe.Slice(&buf[0], n)，语义清晰且 debug 模式下带越界检查
uintptr 是 GC 安全断点，不是“轻量指针”
uintptr 是纯数值，GC 完全不追踪它。一旦你把地址存成 uintptr，就等于主动放弃 GC 保护。
危险模式：
- 先存
u := uintptr(unsafe.Pointer(&x))，中间调用fmt.Println或time.Sleep，再*(*int)(unsafe.Pointer(u)) = 42——&x可能在间隔中被回收，解引用即野指针 - 把
uintptr存进 map、全局变量、闭包，原始变量作用域结束就不可靠
安全做法只有两种：
- 所有转换在单表达式内完成：
(*int)(unsafe.Pointer(uintptr(unsafe.Pointer(&x)) + offset))，无中间变量、无函数调用 - 跨函数传递时，必须保留原始 Go 指针（如传入
*T并返回转换结果），或在作用域末尾显式调用runtime.KeepAlive(x)
函数指针转换的特殊约束
函数指针转 unsafe.Pointer 时，必须取函数变量的地址（&fn），而不是函数字面值本身（unsafe.Pointer(fn) 不合法）。因为函数值本身不可取地址，只有存储它的变量才有稳定地址。
还原时也必须严格匹配步骤：
- 先转成目标函数类型的指针：
(*func(int) bool)(ptr) - 再解引用得到可调用函数：
*(*func(int) bool)(ptr)
风险极高：
- 签名不匹配会导致栈帧错位，panic 或静默损坏
- 闭包函数、方法值、内联函数地址不稳定，不能用于跨包或长期缓存
- CGO 场景下必须确保 C 函数签名与 Go 端完全一致，否则 ABI 错乱
真正需要函数指针转换的场景极少，绝大多数回调、插件、钩子机制都能用接口或反射替代。动用 unsafe 前，先问自己：这个函数地址是否真的必须被当成裸内存处理？
