C.malloc分配的内存必须手动C.free，Go不自动管理；转为[]byte或string不改变所有权，不free会导致C堆泄漏；C.CString/C.CBytes同理需配对C.free，不可用Finalizer兜底。
CGO里用C.malloc分配的内存必须手动C.free
Go不会自动管理C堆内存，哪怕你把*C.char转成[]byte或string，底层指针仍指向C分配的地址。不C.free就等于C侧内存泄漏。
常见错误现象：valgrind报C堆未释放、程序长期运行后RSS持续上涨、反复调用后C.malloc返回nil（分配失败）。
- 必须在Go侧明确调用
C.free(unsafe.Pointer(p))，且仅对C.malloc/C.calloc等分配的内存有效 - 不能对Go变量（如
&x）、C静态数组、函数返回的栈内存（如C.getenv返回值）调用C.free，会崩溃 - 释放前确保没有其他Go goroutine 或 C线程仍在读写该内存
Go字符串/切片转C指针后，谁负责释放？
用C.CString或C.CBytes生成的指针，Go不持有所有权，必须手动C.free；反过来，C传入的指针若由C分配，Go也不能用runtime.SetFinalizer自动清理——Finalizer运行时机不可控，可能在C还在用内存时就触发了C.free。
-
C.CString("hello")→ 返回*C.char，需配对C.free(unsafe.Pointer(...)) -
C.CBytes([]byte{1,2,3})→ 同样要C.free，别以为切片本身会被GC带走 - 不要给C返回的
*C.char加Finalizer，尤其当C库会异步回调时，极易UAF（use-after-free） - 如果C接口要求你“接管”某块内存（如回调中传入
void*），那就得在对应时机主动C.free
用unsafe.Slice或unsafe.String包装C内存时，释放时机怎么卡？
这类转换只是视图映射，不复制数据，也不改变内存归属。释放时机完全取决于C内存的生命周期契约，不是Go变量作用域结束就能释放。
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
立即学习“go语言免费学习笔记（深入）”；
- 例如：
s := unsafe.String((*byte)(p), n)，s是只读视图，p仍需按C侧规则释放 - 若C函数文档写明“返回值由调用方释放”，那不管你在Go里怎么转，都得在逻辑完成后再
C.free - 常见坑：在defer里
C.free，但函数提前return或panic，导致释放被跳过；建议用runtime.SetFinalizer仅作兜底，主路径必须显式释放 - 跨goroutine传递C指针时，务必同步释放动作，避免多线程竞争释放同一块内存
为什么CGO_CFLAGS=-g和CGO_LDFLAGS=-g对排查内存问题没用？
调试符号只能帮你看清C函数调用栈，但CGO内存泄漏本质是所有权归属混乱，不是代码行号缺失。真正有效的手段是结合C侧工具链。
-
valgrind --tool=memcheck ./myprogram能直接定位C.malloc未配对C.free的位置 - macOS用
leaks ./myprogram或malloc_history查分配点 - Linux可开
MALLOC_TRACE环境变量记录malloc/free轨迹 - Go侧
pprof对C堆无效，别指望go tool pprof看到C malloc统计
最麻烦的其实是C库内部分配再通过接口暴露给你——你根本不知道它用的是malloc还是arena_alloc，这时候只能严格按文档约定，或反向看C源码确认释放责任方。
