valgrind 不能直接可靠检测 go+cgo 程序，仅能有效检查独立、手动内存管理的 cgo 调用部分；推荐优先使用 cgo_check=2 和 go test -gcflags="-d=checkptr" 进行边界校验。
Valgrind 能不能直接测 Go + CGO 程序
不能直接测，至少不能像测纯 C 程序那样可靠。Go 运行时自己管理堆、调度 goroutine、做栈分裂和写屏障，Valgrind 会把大量 Go 内部内存操作（比如 runtime.mallocgc、runtime.stackalloc）误判为泄漏或非法访问。
真正能用 Valgrind 有效检测的，仅限于你用 CGO 显式调用的 C 代码部分——前提是这部分 C 逻辑独立、不依赖 Go 运行时分配的内存，且你手动管理了所有 malloc/free。
- 常见错误现象：
Invalid read/write报在runtime.cgoCall或runtime.cgocallbackg1里，基本是干扰项，不用理 - 使用场景：只适合排查 C 函数内部的
malloc漏掉free、越界写char*缓冲区、重复free等问题 - 性能影响：开启
--tool=memcheck后程序慢 20–50 倍，且 Go 的 GC 周期会被打乱，容易触发假阳性
怎么让 CGO 部分被 Valgrind 真正“看见”
默认 go build 生成的二进制是静态链接 Go 运行时 + 动态链接 libc，Valgrind 很难跟踪到你的 C 代码；必须把 CGO 部分编译成独立的共享库，并确保符号未剥离。
- 把 C 逻辑抽成单独
.c文件（比如mylib.c），用gcc -fPIC -shared -o libmylib.so mylib.c编译 - Go 侧改用
// #cgo LDFLAGS: -L. -lmylib+import "C"调用，而不是内联/* */C 代码 - 构建时加
go build -ldflags="-linkmode external -extldflags '-g'"，强制外部链接并保留调试符号 - 运行前设
LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH，再跑valgrind --tool=memcheck ./yourprog
比 Valgrind 更靠谱的 CGO 内存检查方式
Go 官方生态里，go test -gcflags="-d=checkptr" 和 CGO_CHECK=2 是更轻量、更贴合实际的方案，它们专为 CGO 边界设计，不干扰运行时。
立即学习“go语言免费学习笔记（深入）”；
-
CGO_CHECK=2会在每次C.CString、C.GoBytes、指针转换时做边界校验，一越界就 panic，错误信息明确指向哪行 Go 代码传了非法指针 -
go test -gcflags="-d=checkptr"在测试时启用指针有效性检查，对*C.int解引用、C.size_t转换等动作实时拦截 - 两者都不需要改 C 代码，也不依赖外部工具链，但只查“Go → C”这一侧的误用，不查 C 内部 malloc/free 逻辑
- 注意：开启后性能下降明显，仅用于开发/CI 阶段，别上生产
一个典型 CGO 内存泄漏的排查顺序
别一上来就开 Valgrind。先确认是不是 CGO 层的问题，再决定要不要动重型工具。
- 先跑
CGO_CHECK=2 ./yourprog，看是否 panic —— 如果 panic，90% 是 Go 侧传参错误，不是 C 侧泄漏 - 用
pprof看runtime.MemStats.Alloc和CGOAllocsTotal是否持续上涨，确认泄漏真实存在 - 检查 C 函数里所有
malloc/calloc是否都有对应free，尤其注意 error path 是否遗漏free - 只有当以上都排除，且你确信泄漏发生在 C 库内部逻辑时，才按前面说的方式编译共享库 + Valgrind
Valgrind 报出来的地址经常是 Go 运行时内部结构体字段偏移，不是你的 C 变量名。这时候得结合 addr2line -e libmylib.so 0x... 手动定位，别指望它自动给你标出 mylib.c:42。
