goroutine 长期不退出会导致内存持续增长。因其栈、闭包变量、channel 缓冲区均不释放，常见于无退出控制的 for range ch 或未设超时的 time.sleep；应使用 context.context 控制生命周期，避免裸启 goroutine，channel 操作前检查关闭状态，select 必含 default 或 case。
goroutine 启动后没退出，内存就一直涨
Go 的 goroutine 不是系统线程，但每个 goroutine 会分配栈（初始 2KB，可增长），如果它长期阻塞又没被回收，栈内存、闭包捕获的变量、channel 缓冲区都会持续占用。最常见的是启动了 goroutine 却忘了加退出控制，比如 for range ch 卡在空 channel 上，或 http.HandleFunc 里启了个不带超时的 time.Sleep。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 所有长生命周期 goroutine 必须有明确退出路径：用
context.Context传入取消信号，监听ctx.Done() - 避免裸写
go fn()，尤其在循环里——漏掉ctx或sync.WaitGroup就等于放生 goroutine - channel 操作前先确认是否已关闭；
select中必须含default或case ，否则可能永久阻塞
defer + goroutine 组合导致变量无法释放
闭包捕获的局部变量生命周期由 goroutine 决定，不是函数返回就结束。典型陷阱：在 defer 里启动 goroutine，结果函数返回了，但 goroutine 还拿着参数、接收者甚至整个 struct，导致整块内存卡住。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 别在
defer里直接go func() { ... }()；若必须异步清理，显式拷贝需要的值，比如v := x; go func(val int) { ... }(v) - 检查 struct 方法是否被 goroutine 引用：如果方法里用了
h.field，而 goroutine 持有h，那整个h实例都释放不了 - 用
go tool pprof查 heap profile，重点关注runtime.gopark和闭包符号，定位“活着但不该活”的 goroutine
忘记 close(channel) 导致 range 永远等不到 EOF
for range ch 会一直阻塞直到 channel 被 close()，但如果 sender goroutine 因 panic、return 或逻辑错误提前退出，channel 没关，receiver 就永远挂起——这是 goroutine 泄露最隐蔽的来源之一。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- sender 责任制：谁创建 channel、谁负责 close；receiver 绝不 close
- 用
sync.Once包裹close(ch)，防止重复 close panic - 更安全的模式：用
context.WithCancel控制生命周期，receiver 监听ctx.Done()主动退出，不依赖 channel 关闭 - 测试时加超时：
select { case v :=
第三方库启动 goroutine 却没暴露关闭接口
像 http.Server、grpc.Server、某些日志库或 metrics collector，内部会启 goroutine 处理连接、上报、心跳等。如果只调 server.ListenAndServe() 不调 Shutdown()，进程退出时这些 goroutine 仍存活，pprof 里能看到它们卡在 netpoll 或 runtime.gopark。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 所有带
Start/Run的库，先查文档有没有对应Stop/Shutdown方法；没有的话，得看源码确认 goroutine 是否受控 -
http.Server必须配Shutdown(ctx)，且 ctx 带 timeout，不能只用Close() - 用
runtime.NumGoroutine()在关键节点打点，上线前做 goroutine 数量 baseline 对比
真正难的不是写 go，是写完之后知道它什么时候该停、为什么还没停、以及停不掉时怎么揪出那个多出来的引用。pprof 是唯一可信的裁判，其他都是猜测。
