uintptr不能参与gc扫描，因gc只识别 t指针；转为uintptr后若无对应 t持有，内存可能被误回收，导致panic或脏数据。
uintptr 不能直接参与 GC 扫描
Go 的垃圾回收器不识别 uintptr，它只认 *T 这类真实指针。一旦你把指针转成 uintptr，GC 就“看不见”它指向的内存了——哪怕那块内存还在被逻辑使用，也可能被提前回收。
常见错误现象：panic: runtime error: invalid memory address or nil pointer dereference 或静默读到脏数据，尤其在 GC 触发后出现。
实操建议：
- 永远避免用
uintptr长期持有对象地址；需要保留引用时，必须同时持有一个对应的*T（哪怕只是临时变量） - 转换链必须是「指针 →
uintptr→ 指针」连续完成，中间不能插入函数调用、goroutine 切换或任何可能触发 GC 的操作 - 典型安全写法：
ptr := &x u := uintptr(unsafe.Pointer(ptr)) // 紧接着还原，不穿插其他逻辑 newPtr := (*int)(unsafe.Pointer(u))
syscall.Syscall 中的 uintptr 参数不是“随便传”
系统调用接口（如 syscall.Syscall、syscall.Syscall6）要求参数为 uintptr，但它的含义是“按平台 ABI 传入一个整数”，不是让你塞任意指针地址进去。
立即学习“go语言免费学习笔记（深入）”；
使用场景：调用 mmap、ioctl、read 等底层系统调用时，需把缓冲区地址、标志位等转为 uintptr。
实操建议：
- 缓冲区地址必须来自
unsafe.Pointer(&slice[0])或unsafe.Pointer(&structField)，不能来自reflect.Value.UnsafeAddr()（可能指向栈上临时值） - 标志常量（如
syscall.MAP_ANON）本身就是uintptr，直接传，不用强转 - 传入的 slice 必须保证生命周期覆盖整个 syscall 调用过程；若 syscall 异步返回（如某些驱动 ioctl），需额外同步机制防止 slice 被回收
reflect.SliceHeader 和 reflect.StringHeader 的 Data 字段必须配 uintptr
这两个结构体的 Data 字段类型是 uintptr，不是 unsafe.Pointer。这是 Go 故意设计的“断开 GC 关联”信号——你明确告诉运行时：“我来负责这块内存的生命周期”。
容易踩的坑：直接把 unsafe.Pointer 赋给 Data，却不做类型转换，编译不过；或者用 uintptr(p) 但 p 是局部变量地址，逃逸分析没生效，栈被复用。
实操建议：
- 构造
reflect.SliceHeader时，Data必须来自uintptr(unsafe.Pointer(&s[0]))，且s必须是 heap 分配的切片（例如由make创建） - 不要手动修改
reflect.StringHeader.Data指向 C 字符串（如C.CString返回值），除非你用C.free显式管理——Go 不会帮你 free - 性能影响：绕过 GC 意味着你要承担全部内存安全责任；用错一次，就是 use-after-free
CGO 边界传递 uintptr 的陷阱
从 Go 传 uintptr 到 C 函数，再由 C 回传给 Go，是常见模式（比如 OpenGL、FFmpeg 绑定）。但 Go 1.17+ 加强了检查：如果 uintptr 来自 Go 分配的内存，且没有对应活跃的 Go 指针，运行时可能 panic 报 invalid argument to unsafe.Slice 或类似错误。
根本原因：Go 现在会尝试追踪 uintptr 的来源，防止悬空引用。
实操建议：
- 传给 C 的
uintptr应该来自C.malloc分配的内存，或确保 Go 侧有强引用（如全局var ptr *byte持有原始地址） - 避免在 C 回调中直接把收到的
uintptr当 Go 指针用；更安全的做法是 C 侧存 ID，Go 侧用 map 查表还原指针 - 兼容性注意：Go 1.16 及以前对此较宽松，升级后原有代码可能突然崩溃
最麻烦的地方不在语法，而在“谁负责释放”和“何时释放”的隐含契约——uintptr 本身不携带所有权信息，所有责任都压在开发者脑内状态上。写完记得问自己一句：这个 uintptr 对应的内存，此刻有没有至少一个活着的 Go 指针在引用它？
