runtime.setfinalizer只能绑定到显式指针类型变量，不保证执行且不可用于资源清理；正确用法是先声明变量再取地址绑定，适用于cgo内存释放等极少数场景。
runtime.SetFinalizer 只能绑定到指针类型上
你传给 runtime.SetFinalizer 的第一个参数，必须是显式的指针类型变量（比如 *MyStruct），不能是值类型、接口、切片头、map 或 channel 本身。Go 运行时靠这个指针地址来追踪对象生命周期，一旦传入非指针（如 MyStruct{} 或 interface{}），会直接 panic：runtime.SetFinalizer: pointer required。
常见错误是试图对 struct 字段或局部变量取地址后立刻绑定，但该变量很快逃逸失败或被优化掉；更隐蔽的是把接口值（interface{}）强制转成 *any——接口底层是两字宽结构，强转指针会导致 finalizer 绑定到错误内存位置，GC 时触发未定义行为。
- ✅ 正确做法：先声明变量，再取地址：
obj := &MyStruct{}; runtime.SetFinalizer(obj, f) - ❌ 错误写法：
runtime.SetFinalizer(&MyStruct{}, f)（临时对象地址不可靠） - ⚠️ 接口场景下，必须确保接口底层持有一个可寻址的指针，且该指针生命周期 >= finalizer 需求
finalizer 不保证执行，也不保证执行时机
Go 的 finalizer 是“尽力而为”的 GC 钩子，不是析构函数。只要程序退出前 GC 没触发、或对象被编译器判定为“永远可达”，f 就永远不会调用。它不参与 panic 恢复，不阻塞 GC，也不排队——同一对象多次调用 SetFinalizer 会覆盖前一个。
典型误用是拿它做资源清理（如 close file、free C 内存）。一旦 finalizer 没跑，就泄漏；一旦跑了两次（比如手动 close 后 finalizer 又跑），就 crash。它只适合极少数场景：调试对象存活状态、记录未释放资源的统计、或作为“最后防线”补救（但不能依赖）。
立即学习“go语言免费学习笔记（深入）”；
- ✅ 适合：
log.Printf("object %p finalized")或原子计数器减一 - ❌ 禁止：
fclose(cPtr)、obj.Close()、任何有副作用且不可重入的操作 - ⚠️ 即使对象被回收，finalizer 函数也可能在任意 goroutine 中执行，需自行同步
绑定后对象不会因 finalizer 存活，但指针本身会影响逃逸分析
runtime.SetFinalizer 不延长对象生命周期——它只是告诉 GC：“当这个指针指向的对象变得不可达时，请调用 f”。但反过来，如果你把该指针赋给了全局变量、闭包捕获、或传进 channel，那对象就真“活”下来了，finalizer 永远等不到那天。
更实际的影响在编译期：只要代码里出现 &x 并传给 SetFinalizer，编译器大概率会把 x 从栈挪到堆（逃逸），即使逻辑上它本可栈分配。这会增加 GC 压力，尤其高频创建小对象时。
- ✅ 控制逃逸：用
go tool compile -gcflags="-m" main.go确认变量是否逃逸 - ❌ 避免无谓绑定：不要给每个 new 出来的对象都设 finalizer，除非真需要观测其回收
- ⚠️ 如果 finalizer 函数内引用了外部变量，那些变量也会随 finalizer 一起被隐式捕获并堆分配
与 CGO 交互时 finalizer 是唯一可控的释放时机
当你用 C.malloc 或 C.CString 分配 C 内存，并把它存在 Go 对象里，Go 的 GC 不知道怎么 free 它。这时 runtime.SetFinalizer 是唯一合理手段：把 C 指针和 finalizer 绑定，让 GC 在 Go 对象回收时顺手调 C.free。
但这里有个关键细节：C 指针本身必须由 Go 对象持有（比如存为 *C.char 字段），且 finalizer 必须绑定到该 Go 对象的指针上，而不是 C 指针本身（C 指针不是 Go 类型，无法传给 SetFinalizer）。
- ✅ 正确模式：
type Wrapper struct { data *C.char }; w := &Wrapper{C.CString("hi")}; runtime.SetFinalizer(w, func(w *Wrapper) { C.free(unsafe.Pointer(w.data)) }) - ❌ 错误模式：
ptr := C.CString("hi"); runtime.SetFinalizer(&ptr, ...)（ptr是栈变量，地址无效） - ⚠️
C.free必须在 finalizer 中调用，不能依赖defer或手动清理——因为 Go 对象可能长期存活，C 内存却早该释放
finalizer 的语义非常轻量，也极其脆弱。真正难的不是写那几行代码，而是判断“这里到底该不该用 finalizer”——绝大多数时候，答案都是“不该”。它不像 Rust 的 Drop 那样确定，也不像 Java 的 finalize 那样被框架兜底。你得自己画清楚对象图、确认所有引用路径、预判 GC 行为，稍有疏漏就是静默泄漏或二次释放。
