goroutine 必须明确退出机制，否则持续占用内存和资源；应使用 context.context 控制生命周期，配合 select 处理阻塞操作，避免 defer 失效、channel 泄漏及 i/o 资源未释放。
goroutine 启动后没地方结束，内存就只涨不降
Go 的 goroutine 本身开销小，但一旦启动就绑定栈、调度器跟踪、可能持有闭包变量，如果它没退出，所有引用的对象都无法被 GC。最常见的是：启动一个 goroutine 去轮询或监听，但忘记加退出信号或条件终止。
- 用
context.Context传取消信号，别靠全局 flag 或 sleep 硬等 - 所有阻塞操作（
time.Sleep、ch 、<code>、<code>http.Get）都得配合ctx.Done()做 select 切换 - 启动 goroutine 前先想清楚：它靠什么退出？超时？channel 关闭？父 context 取消？没答案就先别起
比如：go func() { for { doWork(); time.Sleep(1 * time.Second) } }() —— 这个 goroutine 永远不会停，只要主逻辑没崩溃，它就一直占着内存和 goroutine 计数。
defer 在 goroutine 里失效，资源根本没释放
很多人以为 defer 能保底清理，但在 goroutine 中，如果函数没返回（比如死循环、永久阻塞），defer 根本不会执行。文件句柄、数据库连接、锁、临时 buffer 都可能因此泄漏。
- defer 只在函数 return 时触发，不是“进程退出时”或“goroutine 被杀时”
- 带超时的 I/O 操作必须显式 close，不能依赖 defer + 无限等待
- 用
sync.Once或 channel 配合close()做一次性清理更可靠
典型反例：go func(f *os.File) { defer f.Close(); for { _, _ = f.Read(buf) } }(file) —— f.Close() 永远不执行，fd 泄漏，Linux 下最多打开 1024 个文件就崩。
channel 不关、不消费，sender 和 receiver 全卡住
无缓冲 channel 发送会阻塞直到有人接收；有缓冲 channel 满了也阻塞。如果 sender goroutine 持续发，receiver 却提前退出或没启动，sender 就永远挂起，连带它持有的所有变量（包括大 struct、slice）一起锁在内存里。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 发送前用
select包一层，带default或ctx.Done()分支，避免死等 - receiver 必须确保能跟上节奏，或用
range ch配合 channel 关闭语义 - 别用
chan 或 <code> 类型掩盖关闭责任 —— 谁创建 channel，谁负责 close（除非明确是“只读只写”的边界契约）
例子：ch := make(chan int); go func() { for i := 0; ; i++ { ch —— 没人收，这个 goroutine 第一次 <code>ch 就卡死，栈和 i 的值全留着。
sync.WaitGroup 计数错乱，goroutine 实际还在跑但你认为它结束了
WaitGroup 是手动计数，Add 和 Done 必须严格配对。Done 多了 panic，少了就 forever Wait —— 表现就是 goroutine 数稳定不降，pprof 看到一堆 sleeping goroutine，但代码里找不到它们在哪。
- 不要在循环里反复 Add(1)，然后只 Done 一次；也不要 defer wg.Done() 但函数提前 return 了多次
- 用
go tool trace查 goroutine 状态比看runtime.NumGoroutine()更准：sleeping / runnable / syscall 才算真活着 - 更安全的做法是把 wg 当参数传进 goroutine 函数，在函数末尾统一 Done，避免作用域混乱
常见坑：wg.Add(1); go func() { defer wg.Done(); ... }() 看似没问题，但如果内部 panic 且没 recover，defer 不执行，wg 就漏减了。
真正难防的不是单个 goroutine 写错，而是多个 goroutine 通过 channel、mutex、context 交叉影响时，退出路径变得隐晦。pprof 的 /debug/pprof/goroutine?debug=2 页面要常看，重点扫那些状态不是 “idle” 或 “runnable” 的长期 sleeping goroutine —— 它们大概率正卡在某次 send、recv、lock 或 sleep 上，而你写的退出逻辑根本没触达那里。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
