Go 没有析构函数，runtime.SetFinalizer 是对象被 GC 回收前可能调用一次的弱通知，不保证执行、时机或顺序，不可用于资源清理；应使用显式 Close、defer 和 context 控制生命周期。
Go 没有析构函数，runtime.SetFinalizer 不是“对象销毁时回调”，而是“对象被 GC 回收前、且无其他引用时，可能调用一次的弱通知”——它不保证执行，也不保证时机，更不适用于资源清理。
为什么 runtime.SetFinalizer 经常不触发
根本原因：Finalizer 依赖 GC 周期 + 对象真正不可达 + 运行时调度空闲。常见失效场景：
- 对象仍被栈变量、全局变量、闭包或 channel 缓冲区隐式持有（哪怕只存了一次）
- 程序在 Finalizer 触发前已退出（main 函数结束 → runtime 会强制终止未执行的 finalizer）
- GC 未发生（小内存程序跑完都没触发 GC，finalizer 就一直挂在那里）
- finalizer 函数 panic 了 —— 下次 GC 会直接丢弃该 finalizer，不再重试
实操建议：别靠它等资源释放；加 log.Println("finalizer called") 并配合 runtime.GC() 手动触发测试，否则大概率以为“写错了”。
SetFinalizer 的参数必须是 *T 类型指针，不能是值或 interface{}
这是最常踩的类型坑。传入非指针，或指针类型和目标对象不一致，会静默失败（不 panic，但 finalizer 不注册）。
立即学习“go语言免费学习笔记（深入）”；
- ✅ 正确：
obj := &MyStruct{}; runtime.SetFinalizer(obj, func(*MyStruct) { ... }) - ❌ 错误：
runtime.SetFinalizer(obj, func(MyStruct) { ... })（值类型参数） - ❌ 错误：
var i interface{} = obj; runtime.SetFinalizer(i, ...)（interface{} 会包装为新对象，类型失配） - ❌ 错误：
runtime.SetFinalizer(&obj, ...)（多取了一级地址，类型变成**MyStruct）
验证是否注册成功？没公开 API，唯一可靠方式是：确保对象逃逸到堆、断掉所有引用、强制 GC、观察日志输出。
替代方案：显式 Close + context.Context 控制生命周期
真正需要“资源清理”的场景（文件、网络连接、锁、goroutine），Finalizer 是靠不住的。正确路径是：
- 定义
Close() error方法，并文档注明“必须调用” - 用
defer xxx.Close()配合作用域控制 - 对长期运行资源（如后台 goroutine），接收
context.Context，在ctx.Done()时退出并清理 - 若需“自动兜底”，可结合
sync.Once+ 显式关闭逻辑，在 finalizer 里仅打告警日志（例如：“对象未 Close，请检查资源泄漏”）
Finalizer 在这里唯一的合理角色，是当且仅当开发者漏掉 Close 时，发出信号而非代替执行。
Finalizer 的“不确定性”不是 bug，是设计使然 —— Go 的 GC 不承诺顺序、不保证及时性、不维护对象间依赖。把它当监控探针可以，当清理开关不行。真要保资源安全，代码里那行 defer f.Close() 才是唯一确定的出口。
