返回局部变量指针会逃逸到堆但不导致内存泄漏，真正的泄漏源于长生命周期引用（如全局map、闭包、channel未消费等）；逃逸是分配位置问题，泄漏是引用关系问题。
返回局部变量指针一定会逃逸，但不等于内存泄漏
Go中写 func foo() *int { x := 42; return &x }，x 确实会逃逸到堆上——这是编译器的逃逸分析决定的，目的是保证返回的指针有效。但这不是内存泄漏：GC 仍能正常回收它，只要没有其他强引用持续持有该地址。
真正危险的是「本该短命的指针被意外延长生命周期」，比如把返回的 *int 存进全局 map 或闭包里长期持有，或者作为 channel 消息发出去后没人消费，导致整个对象链无法回收。
- 逃逸是分配位置问题（栈→堆），泄漏是引用关系问题（该释放时不释放）
- 用
go build -gcflags="-m -l"可确认是否逃逸，但不能判断是否泄漏 - 别一看到“allocated on heap”就慌——得看谁在 hold 它
闭包捕获变量是高频泄漏源头
闭包看似轻量，但一旦捕获了大对象（比如一个几 MB 的 []byte 或结构体），而该闭包又被注册为 HTTP handler、定时任务或塞进 goroutine 池，就极易造成泄漏。
典型错误：func makeHandler(data []byte) http.HandlerFunc { return func(w http.ResponseWriter, r *http.Request) { fmt.Fprintf(w, "%s", data) } } —— 这个 data 会被整个闭包持有，哪怕 handler 只读前 10 字节。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 修复方式：只传必要字段，或用
copy/append切出独立副本，切断对原底层数组的引用 - 尤其警惕
time.AfterFunc、http.HandleFunc、sync.Once.Do等注册型 API - 用
pprof heap查看 top allocators，常能定位到闭包类型名（如main.(*handler).ServeHTTP·f）
全局 map/slice + 指针 = 隐形内存黑洞
这是最隐蔽也最常被忽略的泄漏模式。例如：var cache = make(map[string]*User)，每次插入都用 &u，但忘了定期清理过期项；或者用 cache[k] = u[:1] 导致整个原始 u 底层数组被锁死。
更糟的是 slice header 复用：a := make([]byte, 10，然后把 <code>b 存进全局变量——此时 10MB 内存全被钉住，GC 不敢动。
- 永远检查 slice 的
cap是否远大于len，再决定是否深拷贝 - 用
make([]T, 0, N)初始化目标切片，避免复用旧底层数组 - 缓存类结构务必配 TTL 或 LRU，且清理时要置
nil或 delete 键，不能只删 value
CGO 中 CString/CBytes 不 free 就真泄漏
这和 Go 自身 GC 完全无关——C.CString 调用的是 libc 的 malloc，Go 不管，必须手动 C.free。漏一次，就是实实在在的物理内存增长，且永不回收。
现象很直接：程序运行几分钟，RSS 涨到几十 MB，pprof heap 却看不到大对象——因为那块内存压根不在 Go heap 上。
- 必须成对出现：
cs := C.CString(s); defer C.free(unsafe.Pointer(cs)) - 别用
defer在循环里——defer 队列会堆积，改用显式C.free - 视频、AI 推理等高频 CGO 场景，建议封装工具函数，内置 free 逻辑
真正难排查的泄漏，往往藏在「引用关系没断」而非「指针本身」；逃逸分析报告只是起点，pprof 的 goroutine 和 heap 才是真相入口。盯住谁在 hold 谁，比盯住谁在 new 更重要。
