确认是CGO泄漏而非Go堆泄漏：容器RSS持续上涨但runtime.ReadMemStats中HeapInuse几乎不变，因pprof无法追踪C.malloc、mmap等CGO分配，需结合memory.usage_in_bytes、pprof火焰图聚焦mmap/malloc、GODEBUG=cgocheck=2及valgrind验证。
怎么确认是CGO泄漏而不是Go堆泄漏
容器RSS持续上涨但runtime.ReadMemStats里HeapInuse几乎不动，就是典型CGO泄漏信号。Go堆只占几十MB，RSS却涨到2GB？别查pprof/heap了——它根本看不见C.malloc、mmap或SQLite的sqlite3_prepare_v2分配的内存。
先验证：用cat /sys/fs/cgroup/memory/memory.usage_in_bytes确认容器真实RSS；再跑go tool pprof http://localhost:6060/debug/pprof/heap，如果top里大量出现runtime.mmap或调用栈断在C.goexit，基本坐实是CGO层问题。
- 启动时加
GODEBUG=cgocheck=2，运行中panic说明有野指针或提前释放，这是最廉价的早期拦截 - Linux环境用
valgrind --tool=memcheck --leak-check=full ./your-binary，专抓C堆泄漏（注意：macOS不支持） - 若用
github.com/mattn/go-sqlite3，检查所有rows.Close()是否漏调——没close，mmap内存永不归还
pprof里为什么看不到CGO分配路径
pprof默认只聚合Go调用栈，一旦进入C函数就断链，你看到的top全是runtime.goexit，不是没泄漏，是栈透不出来。
必须切换分析视角：用go tool pprof -http=:8080 binary http://localhost:6060/debug/pprof/heap打开Web界面，点View → Flame Graph，右上角Focus on输入mmap或malloc，直接过滤出C层热点。
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 重点关注调用链里带
net/http大文件上传、database/sql查询、encoding/json序列化后传C的路径——这些是CGO高频泄漏入口 - 如果
Flame Graph里C.CString占比高，立刻检查对应Go代码有没有配对defer C.free(unsafe.Pointer(cs)) -
bytes.Buffer无限制拼接大文件也会触发底层mmap，且扩容策略导致RSS滞后释放，这不是GC问题，是C堆管理失当
CGO内存泄漏最常踩的三个坑
不是写法错，是生命周期理解偏差。C内存地址稳定，Go对象会移动，混用时稍不注意就悬空或泄漏。
-
C.CString没配defer C.free：错误示例里cs := C.CString(s)后直接C.useString(cs)，C层拿到指针用了，但Go没释放——C堆泄漏 - Go切片引用大数组子集：
bigData := make([]byte, 1e6); return bigData[:10]，整个1MB数组被钉住无法GC，表面是Go泄漏，根子在CGO交互时误传了底层数组 - 长时间C函数阻塞：C函数执行超10秒，Go runtime无法伸缩栈，goroutine被挂起，可能拖垮整个P，间接导致channel堆积、buffer滞留——这算CGO引发的连锁泄漏
怎么验证修复是否生效
别只看单次RSS下降，要测“稳态增长率”。一个刚启动的Go服务RSS到400MB可能是模板加载，但运行2小时后每分钟涨15MB，就是硬伤。
监控指标必须带时间维度：用Prometheus采集container_memory_usage_bytes，计算rate(...[5m])，阈值设为5e6（即5MB/min），连续3个周期超限才告警。
- 本地复现时，用
go run -gcflags="-m" main.go看编译期逃逸分析，确认大对象是否真逃逸到堆——避免误判 - 修复后压测，对比
go tool pprof -base before.heap after.heap的diff结果，重点盯inuse_space新增路径里是否还有C.malloc或mmap调用 - 上线前加
GODEBUG=madvdontneed=1（默认已开），让runtime更积极归还内存给OS，但这只是缓解，不是根治
CGO泄漏最难缠的地方在于：它不报错、不panic、GC完全不管，只默默吃掉RSS直到OOM killer动手。定位时永远优先怀疑C层分配，而不是盯着Go堆profile找“谁占得多”。
