runtime.setfinalizer 不是析构函数，仅在gc判定对象不可达、完成清扫且finalizer goroutine空闲时触发一次弱通知；类型匹配严格、禁止重操作、易致循环引用泄漏，不可替代显式资源管理。
runtime.SetFinalizer 不会“执行析构”，它只可能触发一次弱通知
Go 没有析构函数，runtime.SetFinalizer 也不是析构入口。它只是在 GC 判定对象不可达、完成本轮清扫、且 finalizer goroutine 空闲时，“顺手”调用一次注册的函数——三个条件缺一不可。程序 main 返回、os.Exit()、或 GC 根本没触发，SetFinalizer 就永远不跑。你写个 obj.Close() 放里面，和没写一样。
类型匹配错一个字节，finalizer 就静默失效
SetFinalizer 对参数类型极其敏感，失败不报错，只丢弃回调：
-
runtime.SetFinalizer(obj, func(*MyStruct) {})✅ ——obj必须是*MyStruct类型指针，且指向堆上对象（go build -gcflags="-m"确认 escapes to heap） -
runtime.SetFinalizer(obj, func(MyStruct) {})❌ —— 参数是值类型，运行时 panic -
var i interface{} = obj; runtime.SetFinalizer(i, ...)❌ ——interface{}包装后底层类型失配，静默失败 -
runtime.SetFinalizer(&localVar, ...)❌ —— 栈变量地址传入直接 panic：pointer not in heap
finalizer 函数里干重活，GC 就卡住
SetFinalizer 回调运行在 GC 自己的 goroutine（fing）中，环境受限：
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 禁止调
log.Printf、fmt.Println、http.Get、time.Sleep、runtime.GC()（会死锁） - 禁止启动新 goroutine、向已关闭 channel 发送、解引用可能已被回收的字段（如
obj.buf[:]） - 推荐只做原子计数
atomic.AddInt64(&leakCount, 1)、syscall 级日志、或发信号给外部 cleanup goroutine
循环引用 + finalizer = 对象永不回收
哪怕只是两个结构体互相存对方指针，再给其中一个注册 SetFinalizer，GC 就判定它们都“可达”：
-
x.Other = &y; y.Other = &x; runtime.SetFinalizer(&x, f)→x和y都不会被回收 - 闭包捕获原对象（
func() { use(x) }）也构成隐式循环引用 - 对象在 finalizer 中被重新存入全局 map / channel / slice，也会“复活”，跳过后续回收
最易被忽略的是：finalizer 不是兜底方案，而是泄漏放大器；真正该做的，是在业务逻辑中显式切断引用链、调用 Close()、用 defer 控制生命周期——而不是等 GC 来猜你想要什么。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
