runtime.SetFinalizer 会让对象多活一个 GC 周期：GC 发现不可达后先执行 finalizer 再标记为待二次回收，导致至少两个周期才释放内存，易引发堆滞留与 GC 压力。
runtime.SetFinalizer 会让对象多活一个 GC 周期
这是最直接、最确定的延迟影响：GC 发现对象不可达后，不会立即回收，而是先解绑 finalizer、启动独立 goroutine 执行回调，再将对象标记为“待二次回收”。这意味着对象至少要经历两个完整 GC 周期才真正释放内存。
常见错误现象：runtime.ReadMemStats() 中 M.HeapInuse 持续偏高，或 M.FinalizeNum 不断增长，说明 finalizer 队列积压，对象卡在“带 finalizer 待处理”状态。
- 高频分配的对象（如 HTTP request 结构体、临时 buffer）一旦注册 finalizer，极易造成堆内存滞留和 GC 压力上升
- finalizer 执行本身不阻塞当前 goroutine，但其调度依赖 runtime 的 finalizer goroutine，该 goroutine 并非高优先级，可能被延迟数秒甚至更久
- 若 finalizer 函数内触发新分配（比如 log 打印、map 写入），还会间接延长其他对象生命周期
finalizer 执行期间对象可能重新变为可达
finalizer 函数运行在独立 goroutine 中，且完全不受调用方栈帧保护。如果它意外持有原对象的引用（例如闭包捕获、存入全局 map、作为 channel 发送值），GC 会判定该对象“再次可达”，从而跳过后续回收——这不是 bug，是设计使然。
使用场景：调试时加日志观察回收行为，或实现弱引用缓存；但业务代码中绝不能依赖这种“重入可达”做逻辑分支。
- 禁止在 finalizer 中调用
append、map[xxx] = yyy、send等可能隐式持有对象的操作 - 若必须查表，用只读方式（如
map[xxx]而非delete或range），并确保 key 是轻量值类型（int64、string），而非指针或结构体字段地址 - 测试时可用
runtime.GC()+time.Sleep(10 * time.Millisecond)多次触发，观察是否出现“本该回收却一直存活”的对象
栈变量取地址传给 SetFinalizer 必然失败
runtime.SetFinalizer 第一个参数必须是指向堆上对象的指针。传入栈变量地址（哪怕用了 &x）会导致运行时 panic：runtime.SetFinalizer: pointer not in heap。更隐蔽的问题是：你以为逃逸了，其实没逃逸。
参数差异：传 &localVar ❌，传 new(T) 或 &MyStruct{} ✅（前提是编译器确实让它逃逸）。
- 用
go build -gcflags="-m" main.go确认输出含escapes to heap，否则 finalizer 不会注册成功 - 切片、map、channel 的 header 是栈变量，对其取地址（如
&slice）无效；应对其底层数组或元素设 finalizer（极少需要） - sync.Pool 复用的对象绝对不能在
Put前注册 finalizer——对象可能被反复取出，finalizer 会被重复注册或触发多次
程序退出时 finalizer 很可能被跳过
main 函数返回或 os.Exit() 调用后，runtime 会强制终止所有未执行的 finalizer，不等待也不重试。这导致大量“兜底清理”逻辑失效，尤其在短生命周期命令行工具或测试中。
性能影响：finalizer 不适用于需要确定性释放的资源（如文件句柄、C 内存）。延迟不只是时间问题，更是语义问题——你无法靠它保证 fd 不耗尽。
- 显式关闭永远优于 finalizer：用
defer obj.Close()，并在Close()中置obj.fd = -1防重入 - 若真需 finalizer 兜底，只做告警（
log.Printf("WARNING: %T not closed, fd leak possible", obj)），不执行实际释放 - 测试 finalizer 是否生效，必须在 main 结束前手动调用
runtime.GC()并 sleep 等待，否则大概率以为“写错了”
finalizer 的延迟不是毫秒级抖动，而是整个 GC 周期级别的不确定性；它把“对象何时死”从确定性语义变成了概率事件。真正关键的资源清理，必须由 owner 显式控制——finalizer 只能是最后一道、无声的、不可靠的防线。
