runtime.SetFinalizer 不保证执行，仅在对象不可达且内存被回收时可能调用，常因GC未触发、对象复活或程序退出而失效；应仅作简单资源兜底，优先使用defer+Close()。
为什么 runtime.SetFinalizer 常常不生效？
它不是“析构函数”，也不保证一定会执行——这是最常被误解的点。Go 的垃圾回收器只在对象不可达且内存真正被回收时，才可能调用 finalizer，但这个时机不确定，甚至可能永远不触发（比如程序结束前 GC 没跑完、对象被提前升到老年代但未回收）。
常见误用场景包括：用它替代 defer 关闭文件、等待 finalizer 释放锁、或假设它能及时清理网络连接。这些都会导致资源泄漏或竞态。
- finalizer 不在 goroutine 中同步执行，而是在专用的 finalizer goroutine 里异步运行，无法控制执行顺序
- 对象一旦设置了 finalizer，GC 会额外维护一个 finalizer 队列，增加 GC 开销和延迟
- 如果 finalizer 函数里重新让对象可达（比如赋值给全局变量），该对象会被复活，finalizer 也不会再触发
怎么正确绑定 finalizer 到自定义资源类型？
必须传入指向堆上分配对象的指针，且该指针不能是栈变量地址（否则 panic：runtime.SetFinalizer: pointer to non-heap memory）。典型做法是封装资源结构体，并在构造时显式分配堆内存。
type Connection struct {
fd int
}
func NewConnection() *Connection {
c := &Connection{fd: openSocket()}
runtime.SetFinalizer(c, func(c *Connection) {
closeSocket(c.fd) // 注意：这里 c 是 *Connection，不是 **Connection
})
return c
}
- finalizer 函数签名必须是
func(arg interface{})，但实际传入的是原指针类型的值（如*Connection），不是接口值本身 - 不要在 finalizer 里调用可能阻塞或 panic 的操作（如网络 I/O、锁竞争），它运行在 GC 线程中，会影响 GC 效率
- 如果资源需要确定性释放，优先用
io.Closer+defer；finalizer 只作兜底
如何验证 finalizer 是否被调度？
靠日志或计数器观察不可靠，因为 GC 触发时机受内存压力、GOGC 设置、运行时版本影响很大。更可行的方式是主动触发 GC 并强制等待，配合 runtime.ReadMemStats 观察对象是否被回收。
立即学习“go语言免费学习笔记（深入）”；
- 调用
runtime.GC()后 sleep 一小段时间（如time.Sleep(10ms)），再检查资源是否已释放（如文件描述符是否关闭） - 设置
GOGC=1加速 GC 频率，便于本地测试（但生产环境慎用） - 注意：即使 GC 完成，finalizer 也可能排队未执行，需结合
runtime.SetFinalizer的文档说明理解其“尽力而为”特性
哪些资源类型适合用 finalizer 做兜底？
仅限于那些：（1）用户忘记显式释放、（2）释放失败不会导致严重后果、（3）释放逻辑简单且无副作用的底层资源。比如 C malloc 分配的内存、原始 socket fd、某些 unsafe.Pointer 持有的外部内存。
- 数据库连接、HTTP client、goroutine 池等高级抽象，不应依赖 finalizer —— 它们自带生命周期管理机制
- 涉及锁、channel 发送、或依赖其他 Go 对象的状态清理，finalizer 极易出错（比如 channel 已关闭、mutex 已被销毁）
- Go 1.22+ 对 finalizer 支持更严格：禁止在 finalizer 中调用
runtime.SetFinalizer，也限制部分 unsafe 操作
真正难的不是写 finalizer，而是判断“要不要写”。多数时候，写清楚文档 + 提供 Close() 方法 + 静态检查工具提醒，比加 finalizer 更可靠。
