Finalizer 不是析构函数，不保证执行时机或一定执行；仅用于资源泄漏兜底、调试或C联动，不可用于业务逻辑清理，且需确保对象堆分配、避免循环引用、进程退出时可能被跳过。
Finalizer 不是析构函数，别指望它准时执行
Go 的 runtime.SetFinalizer 不会保证对象回收时机，也不保证一定执行。它只在垃圾回收器决定回收该对象、且该对象已不可达时「可能」触发——前提是当时 finalizer 还没被显式清除，且 runtime 没崩溃或提前退出。
常见错误现象：defer fmt.Println("cleanup") 被替换成 runtime.SetFinalizer(obj, func(_ *MyType) { fmt.Println("finalized") })，结果程序结束也没打印；或者并发压测中部分对象永远不触发 finalizer。
- 使用场景仅限：资源泄漏兜底（如忘了
Close()的文件描述符）、调试内存生命周期、极少数需与 C 代码联动的资源释放 - 绝不用于业务逻辑清理（如释放锁、更新状态、写日志），因为无法控制执行时机和 goroutine 上下文
- finalizer 函数运行在独立的 finalizer goroutine 中，不能依赖调用方的栈、局部变量或已退出的 defer 链
必须传入指针，且目标类型不能是栈逃逸失败的临时值
runtime.SetFinalizer 第一个参数必须是 *T 类型的指针，且该指针指向的对象必须能被 GC 管理——也就是不能是纯栈上分配、未逃逸的临时变量。
常见错误现象：obj := MyType{}; runtime.SetFinalizer(&obj, f) → finalizer 永远不会触发，因为 &obj 是栈地址，GC 不扫描栈上的指针（除非它逃逸到堆）；runtime.SetFinalizer(new(MyType), f) 可以，但要注意 new 返回的是堆地址。
立即学习“go语言免费学习笔记（深入）”；
- 正确做法：确保对象分配在堆上，例如用
obj := &MyType{}或obj := new(MyType) - 验证是否逃逸：加
-gcflags="-m"编译，看到... escapes to heap才算安全 - 切片、map、channel 自带堆分配，但它们的 header 结构体本身仍是栈变量，不能对
&slice设 finalizer
Finalizer 持有引用会导致对象无法回收
finalizer 函数体内部若意外捕获了外部变量（尤其是它本应清理的那个对象的其他引用），就会形成循环引用，让 GC 认为对象仍可达，从而跳过回收和 finalizer 调用。
常见错误现象：finalizer 函数里调用了某个全局 map 的 delete(m, obj.ID)，而这个 obj.ID 是从闭包外传进来的指针字段，结果整个 obj 被隐式持有。
- 避免闭包捕获：finalizer 回调尽量只用参数传入的
*T，不要引用外部变量 - 如果必须访问外部状态，用弱引用方式（如通过 ID 查表），并确保查表逻辑不反向 hold 住对象本身
- 可配合
debug.SetGCPercent(-1)和runtime.GC()强制触发一轮 GC 测试 finalizer 是否如期运行
进程退出时 finalizer 很可能被跳过
Go 程序调用 os.Exit() 或主 goroutine 退出后，runtime 会直接终止，不等待 finalizer goroutine 完成，也不做任何 GC 清扫。
常见错误现象：命令行工具中设了 finalizer 去 flush 日志缓冲区，但加了 os.Exit(0) 后日志全丢；或测试函数里用 t.Fatal() 导致 finalizer 未执行就退出。
- 需要确定性清理的场景，必须显式调用清理函数，finalizer 只作补充
- 想观测 finalizer 行为？改用
time.Sleep(100 * time.Millisecond); runtime.GC()模拟，而不是靠程序自然结束 - 注意：即使没有
os.Exit，main 函数 return 后，若还有活跃 goroutine，finalizer 仍可能执行；但一旦所有 goroutine 结束，runtime 就立即收尾
Finalizer 最难把握的不是怎么写，而是怎么“忍住不用”——它像一把没保险的扳手，修得了漏油的引擎，也可能拧掉螺丝自己滚进曲轴箱里。
