Go unsafe.Pointer 转换为什么可能让 GC 失去追踪

在做零拷贝转换或接入系统调用时，看到对象“像是突然被 GC 回收”，第一反应不应该是把所有 unsafe.Pointer 都判定为危险。真正的分界点通常是：指针被转换成 uintptr 后，地址只是一个整数，不再承担 Go 引用的语义；如果这个整数被保存、延后使用，GC 就不会因为它仍然存在而保留原对象。

因此，unsafe.Pointer 转换是否安全，要同时看转换形式、地址是否仍在原始分配对象内，以及外部调用结束前原对象是否仍然可达。下面按一个高压零拷贝场景拆开这条边界。

先把“指针转换”和“地址整数化”分开

unsafe.Pointer 允许在不同指针类型之间重解释内存，但它仍表达“这里有一个指向对象的指针”。真正容易让 GC 失去追踪的是下面这一步：

package main

import "unsafe"

func addressOf(p *byte) uintptr {
    // 这里只把地址拿来记录或打印；uintptr 不应被当成长期引用保存。
    return uintptr(unsafe.Pointer(p))
}

返回值是地址的整数表示，不是一个新的 Go 指针。即使这个整数的数值还等于原地址，它也不会让对象继续保持可达；在支持移动的实现中，GC 也不会把整数里的地址一起更新。把它存进结构体、全局变量或延迟队列，再在之后转回 unsafe.Pointer，就已经脱离了普通的安全转换模式。

相反，*T 转成 unsafe.Pointer，再转成另一个布局兼容的指针类型，是文档明确列出的重解释场景。它并不等于可以任意读写内存：目标类型不能比来源对象更大，布局也要匹配，生命周期仍由原对象负责。

uintptr 偏移只能留在受约束的表达式里

底层代码有时需要通过偏移访问结构体字段或数组元素。这个场景不是“先保存地址，稍后再恢复”，而是一次紧邻的地址计算：从指针转成 uintptr，完成偏移，再立即转回 unsafe.Pointer，并且结果继续指向原始分配对象。

package main

import (
    "unsafe"
)

type header struct {
    kind  uint32
    flags uint32
}

func flagsPtr(h *header) *uint32 {
    // 偏移、加法和转回指针保持在同一表达式中，避免把地址整数化后逃逸。
    return (*uint32)(unsafe.Pointer(
        uintptr(unsafe.Pointer(h)) + unsafe.Offsetof(h.flags),
    ))
}

func invalidLaterUse(h *header) *uint32 {
    // 这是错误示意：地址整数被单独保存，后续恢复不再满足受约束模式。
    addr := uintptr(unsafe.Pointer(h))
    return (*uint32)(unsafe.Pointer(addr + unsafe.Offsetof(h.flags)))
}

还要注意两个容易漏掉的边界：偏移后的地址不能越过原始分配对象的末端，也不能把 nil 当成可以加偏移的起点。go vet 能帮助发现一部分不符合约定的写法，但官方文档也明确提醒，静默通过并不等于程序已经满足所有语义要求。

外部调用前后，原对象的最后使用点要明确

规模上来后，最难排查的不是单次转换，而是“调用参数里看起来只剩一个整数”。编译器可能无法从这个整数推断外部调用仍在使用原对象，尤其是对象还有 finalizer 或底层资源绑定时。此时要把原对象的最后存活点写出来：

package main

import (
    "runtime"
    "syscall"
    "unsafe"
)

type descriptor struct {
    fd int
}

func readInto(d *descriptor, buf []byte) error {
    // 系统调用参数在调用表达式内完成地址转换，避免提前缓存 uintptr。
    _, _, errno := syscall.Syscall(
        syscall.SYS_READ,
        uintptr(d.fd),
        uintptr(unsafe.Pointer(&buf[0])),
        uintptr(len(buf)),
    )
    // 明确标记：调用返回前，相关对象仍必须保持可达。
    runtime.KeepAlive(d)
    if errno != 0 {
        return errno
    }
    return nil
}

上面的示例只用于说明生命周期位置，实际项目还需要根据目标平台和系统调用签名调整导入与参数。runtime.KeepAlive 的作用不是“修复一个悬空地址”，而是把对象标记为在该调用点之前仍可达；它应该放在最后一次外部使用之后，而不是随意放在函数末尾。

cgo 长期边界不要用一个 uintptr 硬扛

如果 C 代码只是把一个值传回 Go，不要把含有 Go 指针的对象强行编码成地址整数。runtime/cgo.Handle 就是为跨 C 传递 Go 值设计的整数句柄：C 侧传回句柄，Go 侧再调用 Value 取回原值，使用结束后调用 Delete。句柄是资源，不能忘记释放。

只有当 C 确实要在 cgo 调用返回后继续保存 Go 指针时，才需要评估 runtime.Pinner。被 Pin 的对象在 Unpin 前不会被移动或释放，但 Pinner 自身必须保持可达；对象内部如果还包含需要由 C 访问的 Go 指针，也要分别考虑固定。这个机制不能替代所有权设计，更不能把任意 Go 堆图变成可长期交给 C 保存的数据结构。

排查时先问这五个问题

当问题表现为数据偶发错乱、系统调用返回异常或 cgo 回调拿到失效状态时，可以按下面顺序看代码：第一，是否把 unsafe.Pointer 变成 uintptr 后跨函数或跨 goroutine 保存；第二，转回指针是否仍在同一表达式且位于原始对象内部；第三，外部调用结束前是否还有 KeepAlive 需要标注；第四，C 保存的是值、句柄还是 Go 指针；第五，是否把 go vet 的通过误当成运行时安全证明。

官方资料可直接查阅：https://pkg.go.dev/unsafe、https://pkg.go.dev/runtime#KeepAlive、https://pkg.go.dev/runtime/cgo#Handle。它们给出的不是“所有 unsafe 都不能用”的结论，而是把允许的转换形状和对象生命周期边界说清楚。工程上最稳妥的改进，通常是缩小 unsafe 代码片段、让地址计算和调用紧邻发生，并为跨语言长期持有改用明确的句柄或固定策略。

相关问题

unsafe.Pointer 转成另一个指针类型一定会让 GC 失去追踪吗？

不一定。只要仍然是指针语义、目标布局兼容且对象生命周期有效，文档允许的指针重解释本身不等于丢失 GC 追踪；更需要警惕的是转成 uintptr 后独立保存。

runtime.KeepAlive 能不能让 uintptr 重新变成安全指针？

不能。KeepAlive 只能保证对象在指定调用点前保持可达，不能把一个已经脱离指针语义的整数地址变成受 GC 管理的引用。

什么时候应该用 cgo.Handle？

当 C 侧需要携带一个 Go 值，随后再回到 Go 侧取回时，优先用 cgo.Handle。它表达的是句柄生命周期，不要求把 Go 对象的裸地址交给 C 长期保存。