Finalizer 不保证执行时机且不可靠，仅作为资源释放的最后兜底；必须用指针绑定严格匹配类型的清理函数，禁止在其中执行阻塞或调度依赖操作。
Finalizer 不会按你期望的时机运行
Go 的 runtime.SetFinalizer 不是析构函数，也不保证一定会执行。它只在对象被垃圾回收器（GC）判定为不可达、且 GC 完成清理前的某个不确定时刻触发——可能几秒后，也可能永不触发（比如程序提前退出，或对象一直被隐式引用）。
常见错误现象：os.File 或 net.Conn 没关，靠 Finalizer 补救，结果压测时大量文件描述符耗尽；或者测试里没显式 close，却“侥幸”通过，上线后泄漏。
- Finalizer 是最后兜底手段，不是资源管理主路径
- 不能依赖它释放关键资源（如锁、数据库连接、fd、GPU 显存）
- 如果对象被全局 map 缓存、或被闭包捕获、或有循环引用，Finalizer 可能永远不跑
- GC 频率受堆大小和 GOGC 影响，小对象可能等很久才被扫到
SetFinalizer 的参数类型必须严格匹配
runtime.SetFinalizer 要求第一个参数是「指向某类型的指针」，第二个参数是「接收该类型指针的函数」。类型不一致会静默失败——不报错，但 Finalizer 无效。
典型翻车场景：传入 struct 值而非指针；或 finalizer 函数签名里用 *T，但传的是 **T；或 struct 匿名嵌套导致底层类型不一致。
立即学习“go语言免费学习笔记（深入）”；
- 必须用
&obj，不能用obj（值传递会复制，Finalizer 绑定到临时副本） - finalizer 函数形参类型必须和
&obj的类型完全一致，包括包路径（mypkg.MyType≠otherpkg.MyType即使字段一样） - struct 字段含 interface{} 时尤其危险——运行时类型擦除可能导致匹配失败
示例：
type Resource struct{ fd int }
func cleanup(r *Resource) { syscall.Close(r.fd) }
r := &Resource{fd: 123}
runtime.SetFinalizer(r, cleanup) // ✅ 正确：*Resource → *Resource
Finalizer 里不能调用阻塞或依赖调度的操作
Finalizer 函数运行在 GC goroutine 中，这个 goroutine 不参与 Go 调度器的公平调度，且可能被中断。在其中做网络请求、锁竞争、channel 发送、甚至长时间计算，都可能卡住 GC，拖慢整个程序。
错误现象：服务响应延迟突增、pprof 显示 GC STW 时间异常长、CPU 利用率低但吞吐骤降。
- 禁止调用
time.Sleep、net.Dial、sync.Mutex.Lock（除非已知无竞争）、ch - 避免分配新对象（会再次触发 GC，形成递归风险）
- 只做快速、幂等、无副作用的清理：如
syscall.Close、C.free、置空指针字段 - 若需复杂逻辑，应把任务投递到 worker goroutine，Finalizer 只负责发信号
替代方案比 Finalizer 更可靠
99% 的非内存资源清理，应该用显式生命周期控制：接口定义 Close() 方法 + defer xxx.Close()；或用 sync.Pool 管理可复用对象；或封装成 io.Closer 兼容生态。
Finalizer 真正适用的场景极少：C 代码分配的内存（C.malloc）、极低层驱动句柄、或你完全无法修改调用方代码时的补救措施。
- 对
*C.FILE或裸unsafe.Pointer，Finalizer 是合理选择 - 所有 Go 标准库中的资源（
os.File、sql.Rows、http.Response.Body）都自带Close，必须显式调用 - 用
go vet可检测未调用Close的常见模式（如os.Open后没 defer）
Finalizer 最容易被忽略的一点：它不解决「谁该负责释放」的问题，只试图掩盖责任缺失。写的时候省事，查泄漏时花十倍时间。
