Go runtime.AddCleanup 为什么需要保留返回的清理句柄：终结动作与生命周期边界

写一个包住文件描述符、C 句柄或临时资源的 Go 类型时，很多人会把释放动作交给垃圾回收，再把 runtime.AddCleanup 当成“最终一定会执行的 defer”。这个理解会留下隐蔽的生命周期问题：清理函数是在对象不可达后由独立 goroutine 排队执行，返回的 runtime.Cleanup 句柄则决定了你能否在正常关闭路径上取消这次兜底。真正稳妥的做法是显式关闭负责确定性释放，AddCleanup 只承担遗忘释放时的最后保护，并在必要时用 runtime.KeepAlive 延长对象可达时间。

runtime.AddCleanup 的返回值不是装饰：正常释放后用 Cleanup.Stop() 取消兜底，资源操作结束后用 runtime.KeepAlive 防止对象过早变得不可达；不要把 GC 清理当成准时的业务回调。

为什么 AddCleanup 不是一个延迟版 defer

defer 绑定的是当前函数返回；runtime.AddCleanup 绑定的是指针对象的可达性。下面这个小类型模拟一个需要关闭的底层资源，fd 是资源标识，cleanup 是回收兜底函数：

type Resource struct {
    fd int
}

func release(fd int) {
    // 释放底层资源
}

func newResource(fd int) (*Resource, runtime.Cleanup) {
    resource := &Resource{fd: fd}
    cleanup := runtime.AddCleanup(resource, release, resource.fd)
    return resource, cleanup
}

当 resource 不再可达后，运行时才会把 release 排进清理队列。它没有承诺“下一次 GC 立刻执行”，也不能替代业务层对关闭时机的要求；文档还明确说明清理函数运行在独立 goroutine 中。

返回的 Cleanup 句柄应该放在哪条正常路径

包装类型通常有一条明确的 Close 路径。句柄应当作为对象状态的一部分保存，让 Close 先释放真实资源，再停止 GC 兜底。这里用三个正文节点表示真实调用链：Resource.Close、release、Cleanup.Stop。

type Resource struct {
    fd      int
    cleanup runtime.Cleanup
}

func newResource(fd int) *Resource {
    resource := &Resource{fd: fd}
    resource.cleanup = runtime.AddCleanup(resource, release, resource.fd)
    return resource
}

func (resource *Resource) Close() error {
    if resource == nil {
        return nil
    }
    release(resource.fd)
    resource.cleanup.Stop()
    runtime.KeepAlive(resource)
    return nil
}

Stop 只取消尚未排队的清理。如果指针已经不可达、清理任务已经入队，再调用 Stop 不保证撤回。因此 Close 不应把它当成释放动作本身；它只是正常路径完成释放后的去重措施。

KeepAlive 解决的是哪一种过早清理

编译器可以在函数最后一次使用对象之后，把它视为不可达，即使当前函数还没有返回。对于包装外部资源的代码，最后一次系统调用和清理兜底之间可能存在这个窗口。runtime.KeepAlive(resource) 要放在最后一次必须保持对象有效的操作之后。

func (resource *Resource) Read(dst []byte) (int, error) {
    n, err := readFD(resource.fd, dst)
    runtime.KeepAlive(resource)
    return n, err
}

这行代码不会阻塞 GC，也不会主动触发清理；它只把可达性边界推进到调用点。若 readFD 由外部库使用了包装对象关联的资源，KeepAlive 就应紧跟在该调用之后，而不是随意放在函数开头。

可达性、参数和并发边界怎么判断

还有一个容易忽略的事实：多个清理函数可以并发运行，清理回调不适合执行长时间阻塞工作。若资源释放需要复杂协调，应让显式生命周期管理承担主流程，回调只做短小、幂等的兜底。

哪些场景不适合用 AddCleanup 承担主逻辑

需要立刻完成的事务提交

GC 没有业务时间表，事务、锁、文件写入和网络连接都应该在显式路径中关闭或提交。

依赖固定顺序的资源树

文档不保证多个对象的 cleanup 顺序。父子资源应由一个明确的 Close 流程按逆序释放。

必须观测失败的释放动作

清理函数在独立 goroutine 中执行，错误不能自然返回给原调用方。需要记录结果时，应把正式释放放到 Close，并让兜底路径只记录有限诊断信息。

用什么方式验证生命周期代码

测试不要只调用一次 runtime.GC() 就断言回调已经完成。可以让 cleanup 通过 channel 发出信号，再在测试中等待信号并设置超时；显式 Close 则直接验证底层释放函数只发生一次。若要验证 Stop，应保留指针可达直到调用完成，避免把“句柄已停止”和“对象已经不可达”混成一个条件。

相关问题

AddCleanup 会保证一定执行吗？

不会。程序退出、对象仍然可达、参数反向持有对象或清理队列未及时运行，都不应被当成确定性完成信号。

Cleanup.Stop 能撤销已经排队的回调吗？

不能保证。它只对尚未排队的清理有效；调用前还要保证传给 AddCleanup 的指针仍然可达。

AddCleanup 能完全替代 SetFinalizer 吗？

新代码通常优先考虑 AddCleanup，但两者都属于 GC 兜底机制，不能替代显式资源管理。迁移时要重新检查可达性、依赖顺序和并发行为。

把 GC 兜底放回它该在的位置

一条可复查的规则是：显式 Close 负责确定性释放，Cleanup.Stop 负责取消尚未入队的兜底，runtime.KeepAlive 负责把最后一次资源操作和对象生命周期对齐。这样即使调用方忘记关闭，运行时仍有补救机会；而正常路径不会把业务正确性押在下一次 GC 上。