只要变量地址被传给C函数，其内存必然逃逸到堆；因Go GC不感知C侧引用，所有经C.xxx接收的Go指针、C.CString返回值、&struct转C指针、unsafe.Pointer转换及闭包捕获后转C回调的变量均强制逃逸。
CGO调用中哪些变量必然逃逸到堆
只要变量地址被传给C函数，编译器就无法证明它在C侧的生命周期可控，因此所有通过 C.xxx 函数接收的 Go 指针所指向的内存，都会被标记为逃逸。这不是保守策略，而是强制规则——因为Go GC完全不感知C代码是否还在用这块内存。
常见逃逸点包括：
-
C.CString()返回的*C.char，底层是malloc分配，必然堆上 - 任何 Go struct 地址传给 C（如
C.some_c_func((*C.struct_foo)(unsafe.Pointer(&foo)))），&foo立即逃逸 - 闭包捕获的变量若被转成
C.callback，整个闭包环境逃逸 -
unsafe.Pointer转换后参与 C 调用，原始 Go 对象逃逸
为什么 new(T) 或 &T{} 在 CGO 上下文中几乎总是堆分配
单独看 new(Foo) 可能不逃逸，但一旦你把它塞进 C.some_func((*C.Foo)(unsafe.Pointer(p)))，编译器就失去上下文：它不知道 C 函数会不会把指针存起来、异步调用、甚至跨线程使用。所以CGO 边界是逃逸分析的“黑盒边界”，越过它，一切指针都视为长期存活。
验证方式很简单：go build -gcflags="-m" main.go，如果看到类似 &foo escapes to heap 或 xxx escapes to heap via unsafe.Pointer，说明已逃逸。
立即学习“go语言免费学习笔记（深入）”；
注意：//go:nosplit 对逃逸无影响；runtime.Pinner 也不能阻止逃逸判定——它只影响 GC 是否回收，不改变分配位置。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
如何避免 CGO 引发的意外堆分配
核心思路不是“绕过逃逸分析”，而是让数据根本不出现在 Go 堆上。可行路径只有三条：
- 用
C.malloc+C.free在 C 堆上分配，Go 端只传裸指针，不持有 Go 对象引用 - 把结构体定义在 C 侧（
typedef struct { ... } foo_t;），Go 只用C.foo_t字面量构造，再取地址——此时 Go 编译器知道这是 C 类型，不触发 Go GC 管理逻辑 - 对小固定长度数组，改用
[N]C.char而非*C.char，避免C.CString；例如传字符串时用C.struct{ data [256]C.char }+copy填充
别尝试用 sync.Pool 缓存 CGO 对象——Pool 中的对象仍受 GC 管理，且 C 侧无法感知 Pool 回收时机，极易悬空。
CGO 中悬空指针的真实触发条件
很多人以为“Go 函数返回后指针就失效”，其实更危险的是：GC 在任意时刻回收未被 Go 代码显式引用的对象，哪怕该对象刚传给 C 十毫秒。典型表现是 C 回调里访问 struct 字段时值为零或乱码，GDB 显示对应内存已被覆写。
可靠保活方式只有一种：在 Go 侧长期持有该对象的根引用，比如存进全局 map、或作为 struct 字段嵌入长生命周期对象。注意：runtime.KeepAlive 只延长到语句末尾，对异步 C 调用无效；runtime.SetFinalizer 更是陷阱——它在 GC 时才执行，此时内存可能已被复用。
真正安全的模式是：C 侧需要长期持有的 Go 内存，必须由 Go 侧显式管理生命周期，且不能依赖 GC 的“不回收”假设。
