finalizer 不是析构函数，不保证准时执行：它仅在gc标记对象不可达且完成清扫后“可能”调用，时间、顺序不确定，甚至可能不调用；只绑定一次，复活后不再触发；程序退出时不保证执行；参数类型必须严格匹配；禁止阻塞或依赖运行时操作；适合泄漏检测等弱保障场景，资源清理应优先用显式控制。
Finalizer 不是析构函数，别指望它准时执行
Go 的 runtime.SetFinalizer 不提供确定性资源清理能力，它只在对象被垃圾回收器（GC）标记为不可达、且 GC 完成本轮清扫后「可能」调用——时间不确定、顺序不确定、甚至可能完全不调用。你写个 os.Remove 清临时文件，或 Close() 关文件描述符，靠 Finalizer 是靠不住的。
- GC 触发时机受堆大小、分配速率、GOGC 设置影响，空闲程序可能几小时都不触发
- Finalizer 只绑定一次，调用后自动解绑；若对象在 Finalizer 中又被其他变量引用，它就“复活”了，Finalizer 不再触发
- 程序退出时，运行时不保证 Finalizer 执行（
os.Exit会直接终止，连 defer 都跳过）
SetFinalizer 的参数类型必须严格匹配
runtime.SetFinalizer 要求第一个参数是指向某类型的指针，第二个参数是函数，且该函数**唯一参数必须是指向同一类型的指针**。类型不一致会导致 panic，而且这个检查发生在运行时，不是编译期。
- 错误写法：
runtime.SetFinalizer(obj, func(*MyStruct) {})——obj是*MyStruct，但传的是MyStruct{}值类型，会 panic - 正确写法：
runtime.SetFinalizer(&obj, func(p *MyStruct) { ... })，且obj必须是变量（有地址），不能是字面量或函数返回值 - 如果结构体嵌套了字段，Finalizer 函数里拿到的指针仍指向原对象，但要注意：它可能已被部分回收（如字段指向的内存已释放），不要盲目解引用
Finalizer 里不能调用阻塞或依赖运行时的功能
Finalizer 函数运行在 GC 的专用 goroutine 上，环境受限：不能发起网络请求、不能写文件（除非用 syscall 级别非阻塞写）、不能调用 time.Sleep、不能启动新 goroutine（会引发 fatal error）。
- 常见崩溃：在 Finalizer 里调用
log.Printf（内部用锁+channel）、http.Get、fmt.Println（可能触发 malloc） - 安全做法：只做轻量级记录（如原子计数器
atomic.AddInt64(&finalizedCount, 1)）、或把清理逻辑转给一个长期运行的 cleanup goroutine（通过 channel 发送信号） - 注意：Finalizer 函数内不能调用
runtime.GC()或任何可能触发新一轮 GC 的操作，会死锁
替代方案比 Finalizer 更可靠
真要管理资源生命周期，优先用显式控制：实现 io.Closer 接口 + defer xxx.Close()，或用 sync.Pool 复用对象。Finalizer 只适合做「兜底日志」或「泄漏检测」这类弱保障场景。
立即学习“go语言免费学习笔记（深入）”；
- 文件句柄：用
os.Open+defer f.Close()，而不是靠 Finalizer 关 - 数据库连接：用连接池（
sql.DB自带），不是靠 Finalizer 归还 - 检测泄漏：Finalizer 里写
fmt.Printf("leaked: %p\n", p)并配合runtime.ReadMemStats对比，比指望它干活更有价值
Finalizer 最容易被忽略的一点：它让对象至少多活一个 GC 周期——因为 runtime 需要先标记、再排队、再执行。哪怕你立刻 obj = nil，只要 Finalizer 已注册，GC 就不会在本轮回收它。
