Go程序内存持续上涨大概率非泄漏，而是GC延迟或对象本该长期存活；真泄漏需满足稳定负载下HeapInuse/HeapAlloc线性增长且重启归零复现。
Go 程序“内存持续上涨”大概率不是泄漏，而是 GC 没来得及回收、或对象本就该活久一点（比如缓存、连接池）。真泄漏必须满足两个条件：在稳定负载下，HeapInuse 和 HeapAlloc 随时间线性增长；且重启后归零、再次复现。
怎么抓到有效的 heap profile
pprof 不会自动采样堆内存，不手动触发就什么也看不到。线上服务最稳的方式是提前启用 net/http/pprof，本地复现则需在关键路径前后调用 pprof.WriteHeapProfile(f)。
- 线上：启动时加
import _ "net/http/pprof"，再起个 goroutine 跑http.ListenAndServe("localhost:6060", nil)；然后用wget http://localhost:6060/debug/pprof/heap -O heap1.pprof抓快照 - 本地复现：文件名必须带
.heap后缀（如heap_before.heap），否则go tool pprof可能识别失败 - 别在程序刚启动或
MemStats.NextGC接近MemStats.HeapAlloc时采样——这时 GC 正疯狂干活，数据失真
为什么单看 topN 常常找不到泄漏点
泄漏对象在 inuse_space 里占比往往极小，一眼扫过去全是业务主逻辑，根本看不出异常。靠“占比高”找问题，在真实泄漏场景中基本失效。
- 必须做至少两次采样（间隔 30 秒以上），用
-base参数对比：go tool pprof -http=:9999 -base heap1.pprof heap2.pprof - 浏览器打开后，SAMPLE 切换为
inuse_space，再点 “View → Difference” 才能看到净增长部分 - 重点关注调用链末尾是业务代码、但中间夹着
(*ConnPool).reaper、connectionOpener、timerproc这类 runtime 或第三方库函数的路径——它们往往是泄漏入口
goroutine 泄漏为什么总和内存泄漏绑在一起
每个 goroutine 默认栈 2KB，一旦泄漏，不仅本身占内存，还极可能持有 buffer、map、channel、context 等堆对象，形成连锁泄漏。
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
立即学习“go语言免费学习笔记（深入）”；
- 用
runtime.NumGoroutine()打点监控，或直接访问http://localhost:6060/debug/pprof/goroutine?debug=2查看全量栈 - 常见陷阱：Redis
client.Close()漏调、SQL*sql.DB未设SetMaxOpenConns+SetConnMaxLifetime、自定义time.Ticker未Stop() - 怀疑 cgo 时，加
GODEBUG=cgocheck=2运行，看是否 panic；Linux 下可辅以valgrind --tool=memcheck
基准测试里 B.ReportAllocs() 为啥不准
testing.B 默认不控制 GC 触发时机，短时测试中 allocs/op 波动极大，不能单看数字。
- 在
B.ResetTimer()前手动跑两次runtime.GC()，确保上一轮残留被清空 - 用
go test -bench=. -benchmem -memprofile=mem.out生成 profile，再用go tool pprof -alloc_space mem.out看累计分配量，比 allocs/op 更稳定 -
-alloc_space统计的是总分配量，-inuse_space才是当前存活量——泄漏要看后者趋势，但压测比对建议用前者
真正难的不是工具怎么用，而是区分“对象该活多久”和“对象不该活却一直活”。很多泄漏藏在闭包捕获、全局 map 未删、context.WithCancel 未 cancel、unsafe.Pointer 跨边界传递这些隐式引用里，pprof 看不到，只能靠代码审查+运行时打点交叉验证。
