unsafe.pointer转函数指针必须先取函数变量地址（如&f），再转为unsafe.pointer；直接对函数字面量或函数值取地址非法；转换后需确保变量生命周期可控，避免uintptr中转导致悬垂指针，且函数签名与abi必须严格匹配。
unsafe.Pointer 转函数指针必须走 &funcVar → unsafe.Pointer 这条路径
直接对函数字面量（如 func() {}）取地址会编译失败，因为 Go 不允许对未命名的函数值取地址。你只能对**函数变量**取地址，再转 unsafe.Pointer。
常见错误是写 unsafe.Pointer(func() {}) 或 unsafe.Pointer(myFunc) —— 这两种都非法，前者语法错，后者类型不匹配（myFunc 是函数值，不是指针）。
- 正确做法：先声明变量
var f func() = myFunc，再用unsafe.Pointer(&f) - 注意：
&f指向的是“存放函数入口地址的变量”，不是函数代码段本身；这个地址在 GC 期间不会移动，但变量生命周期必须可控 - 如果
f是局部变量，且转换后存储了unsafe.Pointer并逃逸出函数，需用runtime.KeepAlive(f)防止 GC 提前回收该变量
从 unsafe.Pointer 恢复函数指针时签名不匹配极易 crash
Go 不验证函数调用约定（如参数压栈顺序、返回值处理方式），*(*func(int) string)(ptr) 这种转换只要类型大小对得上就能编译通过，但运行时可能因 ABI 不一致直接 segfault。
典型陷阱：把接收者为 *T 的方法转换成无接收者的 func() —— 方法值实际是闭包结构体，内存布局与普通函数不同。
- 只在明确知道目标函数 ABI 与源函数一致时才转换，比如同包内两个签名兼容的函数变量
- 避免跨包、跨模块转换，尤其是涉及 interface{}、error、或含指针/切片参数的函数
- Go 1.21+ 对部分不安全函数调用增加了 runtime 检查，但不覆盖所有 case，不能依赖
uintptr 中转链断裂会导致悬垂指针
把 unsafe.Pointer 转成 uintptr 后，GC 就完全看不见它了。如果中间有函数调用、channel send/receive、或 goroutine 切换，原函数变量可能被回收，再转回指针就是野指针。
错误示例：u := uintptr(unsafe.Pointer(&f)); time.Sleep(time.Millisecond); p := *(*func())(unsafe.Pointer(u)) —— time.Sleep 可能触发 GC，f 被回收，u 成废地址。
- 必须在单表达式内完成转换：
p := *(*func())(unsafe.Pointer(uintptr(unsafe.Pointer(&f)) + 0)) - 加
+ 0是为了强调“无偏移”，避免误以为可随意加减；函数指针变量本身是固定大小（通常 8 字节），不支持算术偏移 - 不要试图用
uintptr存储函数地址做长期缓存——它不是指针，只是整数
unsafe.Slice 不适用于函数指针数组场景
unsafe.Slice 是为数据 slice（[]T）设计的，底层依赖 runtime 对底层数组长度和 cap 的校验逻辑。函数指针数组（如 [3]func()）本质是固定大小结构体，不能用 unsafe.Slice 构造动态函数 slice。
有人尝试 unsafe.Slice((*func())(unsafe.Pointer(&arr[0])), len(arr))，这在某些版本能跑通，但属于未定义行为：runtime 不保证函数指针数组的连续性，也不检查其元素是否可调用。
- 若需动态函数列表，用
[]interface{}或map[string]func()更安全 - 真要零拷贝操作函数数组，请用
reflect.ValueOf(arr).Call([]reflect.Value{})，虽慢但受控 - 任何基于
unsafe.Pointer构造函数 slice 的操作，都不被 Go 官方保证，升级 Go 版本可能突然失效
(*func())(unsafe.Pointer(...)) 在 GC、调度、ABI 变更、编译器优化等所有条件下都稳定有效——这需要对 runtime 内存模型有持续跟踪，而不是一次写完就完事。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
