Golang中的指针运算与unsafe.Pointer Go语言突破类型系统限制

go 里不能做指针算术，unsafe.Pointer 不是 C 的 void*

Go 明确禁止对普通指针（如 *int）做加减运算，比如 p + 1 直接报错：invalid operation: p + 1 (mismatched types *int and int)。这不是语法限制，而是类型安全设计的硬性边界。unsafe.pointer 确实能绕过类型检查，但它本身不支持算术——必须先转成 uintptr 才能加减，再转回 unsafe.Pointer。

常见错误是直接写 unsafe.Pointer(&x) + 4，这会编译失败。正确路径只有一条：uintptr(unsafe.Pointer(&x)) + 4，然后用 unsafe.Pointer() 包一层。

• 加减操作必须在 uintptr 上进行，unsafe.Pointer 本身不可运算
• 所有转换必须显式，Go 不允许隐式类型穿透
• 转换链越长（比如 *T → unsafe.Pointer → uintptr → unsafe.Pointer → *U），越容易因 GC 或编译器优化出问题

用 unsafe.Offsetof 比硬编码偏移更安全

想访问 Struct 字段的内存地址？别手算字节偏移。字段对齐、填充、平台差异会让 unsafe.Pointer(uintptr(unsafe.Pointer(&s)) + 8) 在 32 位机器或不同 Go 版本上突然失效。

unsafe.Offsetof(s.field) 返回的是从 struct 起始到该字段首字节的偏移量，由编译器保证正确。它返回 uintptr，可直接用于地址计算。

立即学习“go语言免费学习笔记（深入）”；

• 永远优先用 unsafe.Offsetof，而不是靠 unsafe.Sizeof 自己累加
• unsafe.Offsetof 只接受字段选择器（s.f），不能传表达式或临时值
• 字段必须是导出的（首字母大写）才能被 unsafe.Offsetof 接受，否则编译报错：cannot refer to unexported field

reflect.SliceHeader 和 reflect.StringHeader 是危险捷径

想把 []byte 快速转成 string 而不拷贝？很多人直接改 reflect.StringHeader 的 Data 和 len 字段，再用 unsafe.Pointer 转成 string。这确实快，但有两个致命前提：

• 源 []byte 的底层数组不能被回收——这意味着不能传入局部 slice（比如函数参数里新切出来的），否则 string 可能指向已释放内存
• Go 1.20+ 开始，string 的底层数据默认不可写，但更关键的是：GC 不跟踪通过 unsafe 构造的 string 引用，可能提前回收底层数组
• 这种转换在 cgo 场景下尤其脆弱，C 函数修改内存后，Go runtime 可能完全不知情

为什么 unsafe.Slice（Go 1.17+）比手动构造 []T 更可靠

手动用 unsafe.Pointer + reflect.SliceHeader 构造 slice，需要自己填 Data、Len、cap，稍有不慎就导致 panic 或越界读写。Go 1.17 引入的 unsafe.Slice 把这个过程封装成一个函数调用，它做了三件事：校验指针非 nil、检查长度是否溢出、确保结果 slice 符合 runtime 内存模型。

• 用 unsafe.Slice((*T)(ptr), len) 替代手拼 reflect.SliceHeader，代码更短，语义更清晰
• unsafe.Slice 不接受 nil 指针，也不接受负长度，运行时会 panic，反而帮你提前暴露问题
• 它返回的 slice 会被 GC 正常追踪——只要原始指针所指内存本身是活的（比如来自 make 或全局变量）

真正难的从来不是怎么突破类型系统，而是让突破后的内存生命周期和 Go 的 GC 节奏对得上。哪怕一行 unsafe，也得想清楚：这块内存谁分配、谁释放、谁持有引用、会不会被编译器优化掉。