unsafe.pointer 是类型擦除后的裸地址容器，不携带类型信息、不可算术运算，必须严格遵循六种合法转换模式，否则触发未定义行为。
unsafe.pointer 是 go 里唯一能绕过类型系统、直接表示内存地址的指针类型——它不是“泛型指针”，也不是“万能指针”，而是一个**类型擦除后的裸地址容器**。它本身不携带任何类型信息，也不能参与算术运算，必须配合 uintptr 才能做偏移计算，且转换链必须严格符合 Go 规范定义的六种合法模式，否则就是未定义行为（可能 crash、静默错误、或在不同 Go 版本/架构下表现不一）。
为什么不能直接用 unsafe.Pointer 做加法？
因为 unsafe.Pointer 被设计为“不可运算”的安全边界：它只允许做类型桥接和地址传递，不许当整数用。想移动指针，必须先转成 uintptr，算完再立刻转回 unsafe.Pointer——中间不能存成变量、不能跨函数传、不能被 GC 误判为无效地址。
- ❌ 错误写法：
ptr := uintptr(unsafe.Pointer(p)) + offset; ...; use(unsafe.Pointer(ptr))——ptr是个纯整数，GC 不知道它还指向有效内存，原对象可能已被回收 - ✅ 正确写法：
unsafe.Pointer(uintptr(unsafe.Pointer(p)) + offset)—— 整个表达式是原子的，Go 编译器能识别这是“临时地址计算” - ⚠️ 注意：
uintptr不是指针类型，它只是个整数别名；一旦脱离unsafe.Pointer ↔ uintptr ↔ unsafe.Pointer这个闭环，就失去内存生命周期保障
结构体字段访问：为什么 Offsetof 比反射快但更危险？
用 unsafe.Offsetof 配合地址运算访问私有字段（比如 sync.Mutex.state 或 http.Header 底层 map），比反射快一个数量级，但前提是结构体布局稳定、字段顺序没变、且你清楚对齐规则。
- 字段偏移不是“源码顺序”，而是编译器按大小+对齐填充后的真实内存位置；
unsafe.Offsetof(u.Age)返回的是从结构体起始到Age字段首字节的字节数，不是第几个字段 - 如果结构体含
String、slice等头结构，它们内部的Array字段是unsafe.Pointer类型，可进一步解引用，但必须确保底层数组未被扩容或移动 - 典型翻车点：对
Struct{ x int; y [100]byte }做偏移计算时，以为y紧跟x后面，实际因对齐可能有填充字节——永远用Offsetof和Sizeof实测，别猜
函数指针转换：为什么 &fn 不等于 fn 的地址？
Go 中函数变量（如 var f func(int) string）本身是个值，存储的是函数入口地址；&f 是这个变量的地址（即栈上存放函数地址的位置），而 unsafe.Pointer(&f) 拿到的是这个“存放地址的变量”的地址，不是函数本身的地址。
立即学习“go语言免费学习笔记（深入）”；
- 要获取函数真实入口地址，目前没有标准、安全、可移植的方式；
runtime.FuncForPC只能反查，不能正向导出 - 常见误用：
genericPtr := unsafe.Pointer(&myFunc)—— 这其实是取了函数字面量的地址（Go 编译器可能优化掉或复用），行为未定义 - 真正可控的场景仅限 CGO：C 函数指针可转
unsafe.Pointer，再传给 C 代码；Go 函数暴露给 C 时，用//export标记，由 cgo 生成适配 glue，不手动转
最常被忽略的一点：unsafe.Pointer 的合法性不取决于你“有没有报错”，而取决于是否落在 Go 规范明确定义的六种使用模式内。哪怕代码在本地跑通十年，一次 GC 优化、一次编译器升级、或换个 CPU 架构（比如 arm64 vs amd64 对齐差异），都可能让看似稳定的内存操作突然失效。