Go中“goroutine内存泄漏”本质是goroutine卡在select等阻塞操作而永不退出，并非堆内存未被GC回收。
goroutine 永远不退出，不是内存没释放，是它卡住了
Go 里所谓“goroutine 内存泄漏”，本质不是堆内存没被 GC 回收，而是 goroutine 启动后卡在 select、、<code>time.Sleep 或 http.Get 上，永远不返回。它持续占着栈（至少 2KB）、调度器跟踪开销、以及闭包捕获的所有变量——这些对象全不能被 GC。
- 典型现象：程序运行越久，
runtime.NumGoroutine()只增不减；pprof 查/debug/pprof/goroutine?debug=2显示大量 goroutine 停在chan receive、semacquire或select - 最常见场景：后台轮询、HTTP handler 中启 goroutine 处理异步任务、worker pool 的 worker 从 channel 取任务但没退出逻辑
- 别信“defer 能兜底”：如果 goroutine 卡在死循环或永久阻塞里，
defer根本不会执行
所有阻塞操作必须配合 ctx.Done() 做 select
不是加了 context.Context 就安全，关键是要让 goroutine 主动响应取消信号。裸调 time.Sleep(1 * time.Second) 或直接 ch 都是高危操作。
- 错误写法：
go func() { for { doWork(); time.Sleep(1 * time.Second) } }()—— 一旦ctx被 cancel，它照样睡下去 - 正确写法：把阻塞操作放进
select，且必含分支 - 示例：
go func(ctx context.Context) { ticker := time.NewTicker(1 * time.Second) defer ticker.Stop() // 必须显式 stop for { select { case <-ticker.C: doWork() case <-ctx.Done(): log.Println("shutting down:", ctx.Err()) return } } }(ctx) - 第三方库也要看是否真正支持 context：比如数据库要用
QueryContext，而不是Query；HTTP 客户端要用Do(req.WithContext(ctx))
channel 发送/接收必须有兜底，不能只靠“有人会收”
向无缓冲 channel 发送数据，若无人接收，goroutine 立刻阻塞；有缓冲 channel 若已满，同样阻塞。这不是设计缺陷，是使用错误——你得明确谁负责消费、何时关闭、怎么避免卡死。
- 发送方不能假设 receiver 一定存在或永不退出；receiver 也不能假设 sender 一定会 close channel
- 避免裸写
ch ：改用带 <code>default或超时的select - 示例（防阻塞发送）：
select { case ch <- data: // 成功 default: log.Println("channel full, dropping") } - 示例（可靠接收）：
for { select { case job, ok := <-jobs: if !ok { return // channel 已关闭 } handle(job) case <-ctx.Done(): return } } - 记得：sender 关闭 channel；receiver 用
ok判断；永远不要向已关闭的 channel 发送（会 panic）
timer/ticker 和 HTTP handler 是泄漏重灾区
很多人以为 time.NewTicker 或 handler 里启个 goroutine 是“轻量操作”，但它们生命周期失控时，比普通 goroutine 更难察觉。
立即学习“go语言免费学习笔记（深入）”；
-
time.Ticker和time.Timer不会随变量作用域结束而自动销毁，必须手动调ticker.Stop() - HTTP handler 中启 goroutine 最容易出问题：请求结束，
responseWriter和request.Body已失效，但 goroutine 还在试图写或读 - 安全姿势：handler 中启动 goroutine，必须传入 request 的
ctx（即r.Context()），并在select中监听它；避免闭包捕获http.ResponseWriter - 别依赖全局 flag 或 sleep 等待退出：没有
ctx.Done()的 select，就等于没出口
真正难的不是写对一个 goroutine，而是确保整条调用链上的每个子 goroutine 都收到并响应同一个 ctx。漏掉一层，就可能留下一个永远不退出的 goroutine —— 它不报错，不 panic，只是悄悄吃掉内存和调度资源，直到某天服务变慢、OOM 或监控报警响起来。
