unsafe.pointer不能直接加减，必须通过uintptr原子中转：先转uintptr、立即加偏移、再立刻转回unsafe.pointer，否则gc可能导致悬空指针。
不能直接对 unsafe.Pointer 做加减运算——这是 Go 编译器的硬性限制，不是风格问题，而是设计使然。所有指针算术必须经由 uintptr 中转，且必须原子完成、不拆分、不缓存。
为什么 unsafe.Pointer 不能直接加减
Go 的 unsafe.Pointer 是受 GC 管理的指针类型，编译器禁止对其执行算术操作，因为它的语义是「类型转换中转站」，不是「内存游标」。直接写 p + 1 会报错：invalid operation: p + 1 (mismatched types unsafe.Pointer and int)。
常见错误包括：
- 试图用
(*int)(p)[1]访问相邻元素 —— 这依赖底层内存布局，一旦结构体字段重排或加//go:notinheaptag 就失效 - 把
uintptr存成变量再复用 —— GC 不追踪uintptr，原对象可能被提前回收，导致悬空指针
正确做法是：先转 uintptr，立即加偏移，再立刻转回 unsafe.Pointer，整条表达式必须原子执行：
ptr := unsafe.Pointer(&slice[0])
newPtr := (*int)(unsafe.Pointer(uintptr(ptr) + unsafe.Offsetof(struct{ a, b int }{}.b)))
uintptr 中转必须「原子完成」
GC 只识别显式指针类型（如 *T、unsafe.Pointer），而 uintptr 是纯整数，GC 完全忽略它。如果把中转过程拆成两步：
u := uintptr(unsafe.Pointer(&x)) // ⚠️ 此刻 GC 可能已回收 &x p := (*int)(unsafe.Pointer(u)) // ❌ 悬空指针，读写都可能 panic
就极大概率触发静默数据损坏或崩溃。必须写成单行原子表达式：
val := *(*int)(unsafe.Pointer(uintptr(unsafe.Pointer(&x)) + offset))
要点：
- 整个表达式不能有中间变量存储
uintptr - 不能在
defer或 goroutine 中延迟使用该指针 - 原始对象（如
&x）必须确保在整个表达式求值期间存活（即不能逃逸到栈外且未被引用）
用 unsafe.Offsetof 和 unsafe.Sizeof 时的陷阱
这两个函数返回编译期常量，但它们反映的是当前平台、当前 Go 版本、当前 struct 字段顺序下的内存布局，不是逻辑定义。
容易踩的坑：
-
unsafe.Offsetof(s.field)要求s是具体值或字面量，不能是nil指针或接口 - struct 字段间存在 padding，
unsafe.Offsetof(s.b)不等于前序字段大小之和（例如struct{ a byte; b int64 }中b偏移是8，不是1） -
unsafe.Sizeof返回的是含末尾 padding 的总大小，不等于各字段Sizeof相加 - 不同架构（
amd64vsarm64）对齐策略不同，跨平台使用需谨慎
永远用 unsafe.Offsetof 算偏移，别手算；字段顺序一变，padding 分布就可能突变。
优先用 unsafe.Slice 替代手动构造切片
Go 1.17+ 提供了 unsafe.Slice，它是对过去用 reflect.SliceHeader + unsafe.Pointer 手动构造 slice 的安全封装。
它内部做了两项关键保护：
- 参数合法性校验（如长度不能为负、不能越界）
- 保持原始指针活跃，防止底层数组被 GC 提前回收
对比示例：
// ❌ 危险：手动构造，无校验，易悬空
hdr := reflect.SliceHeader{Data: uintptr(ptr), Len: n, Cap: n}
slice := *(*[]byte)(unsafe.Pointer(&hdr))
// ✅ 安全：由 runtime 保证生命周期与边界
slice := unsafe.Slice((*byte)(ptr), n)
只要目标 Go 版本 ≥ 1.17，就应无条件使用 unsafe.Slice，而不是自己拼 SliceHeader。
最麻烦的不是算错偏移或写错类型转换，而是你以为对象还活着，其实 GC 已经把它收走了——这种问题不会在本地测试暴露，只会在高负载、长运行时突然爆发。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
