内存泄漏根源在于指针导致对象逃逸并长期被持有：返回局部变量地址使变量堆分配，若外部长期持有则GC无法回收；资源泄漏则因指针间接持有文件描述符等需手动释放的底层资源。
*int 本身不会导致内存泄漏，但**返回局部变量指针、闭包捕获变量、或指针被意外长期持有**，会让本该在栈上自动回收的对象逃逸到堆上，并因引用未断而无法被 GC 回收——这才是泄漏的根源。
为什么返回 &x 是高危操作？
Go 编译器会做逃逸分析：只要函数返回了局部变量的地址，该变量就必须分配到堆上。一旦外部持有这个指针，且生命周期远超原函数作用域，就可能形成“悬空引用链”，阻塞 GC。
- 错误示例：
func foo() *int { x := 42; return &x }→x被逃逸到堆，但若调用方长期保存返回值（如存入全局map），GC 就无法清理 - 正确做法：避免返回栈变量地址；如必须传递数据，优先用值拷贝或显式堆分配 + 明确生命周期管理
- 验证方式：加
-gcflags="-m"编译，看是否输出move to heap
defer file.Close() 和 defer resp.Body.Close() 为什么和指针无关却常被一起提？
这不是指针问题，而是资源泄漏的典型共性场景：**对象本身没泄漏，但它持有的底层资源（文件描述符、socket、C 内存）被指针间接持有且未释放**。比如 http.Response 中的 Body 是一个 io.ReadCloser 接口，底层可能持有一个指向 TCP 连接的指针。
- 漏掉
resp.Body.Close()→ 底层连接不释放 → 复用池失效 → 新建连接堆积 → Goroutine + socket 双泄漏 - 漏掉
file.Close()→ 文件句柄持续增长 → 达到系统上限后open: too many open files - 关键点：这些资源不归 Go GC 管，必须手动释放；指针只是它们的载体，不是罪魁
哪些“指针使用”真正容易埋雷？
不是所有指针都危险，但以下模式极易引入隐式长生命周期引用：
- 把结构体指针存进全局
map[string]*MyStruct，却不提供清除逻辑 → key 不删，value 永远不回收 - 用
sync.Pool存放含指针字段的结构体，但忘记重置字段 → 上次使用的指针残留，意外延长其他对象生命周期 - CGO 中用
C.CString()转字符串，返回的是*C.char，必须配对C.free()；否则 C 堆内存永不释放 - 闭包中捕获大对象的指针（如
func() { fmt.Println(largeSlice) }），该闭包又被注册为 HTTP handler 或 timer func → 整个largeSlice被钉在堆上
append、一次 map 赋值、或一次 http.HandleFunc 注册。查泄漏时别只盯 & 符号，要顺藤摸瓜找引用源头。 
