goroutine 阻塞主因是 channel 使用不当或 select 缺少 default 分支，导致死锁；无缓冲 channel 发送时若无接收方会永久阻塞，引发“all goroutines are asleep”错误。
goroutine 阻塞通常不是因为“太多 goroutine”，而是 channel 使用不当或 select 缺少默认分支导致的死锁或资源滞留。Go 运行时不会主动回收卡在无缓冲 channel 发送/接收上的 goroutine，必须靠设计规避。
无缓冲 channel 发送时 goroutine 永久阻塞
向无缓冲 channel 发送数据，若没有 goroutine 同时执行接收，发送方会一直阻塞 —— 这是最常见的死锁源头。
常见错误现象：fatal error: all goroutines are asleep - deadlock!
- 避免在主线程（main goroutine）中直接向无缓冲
ch := make(chan int)执行ch ，除非另起 goroutine 接收 - 若必须同步通信，改用带缓冲 channel：
ch := make(chan int, 1)，允许一次未匹配的发送 - 更安全的做法是配合
select+default实现非阻塞尝试
select 中缺少 default 导致 goroutine 卡住
select 在所有 case 都不可达时会阻塞，若没写 default，就等同于“等待任意 channel 就绪”——但若所有 channel 永远不就绪，goroutine 就挂住了。
立即学习“go语言免费学习笔记（深入）”；
使用场景：轮询多个 channel、实现超时、避免单点阻塞
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 需要非阻塞操作时，必须加
default，哪怕只写default: continue - 需要超时控制时，用
time.After或time.NewTimer配合case - 不要在
select里重复读同一 channel 多次（如两个case ），Go 不保证执行顺序，且可能漏消息
select {
case v := <-ch:
fmt.Println("received", v)
default:
fmt.Println("no message, moving on")
}channel 关闭后继续接收或发送引发 panic
向已关闭的 channel 发送会 panic：panic: send on closed channel；从已关闭的 channel 接收会立即返回零值 + false（ok 为 false），但若忽略 ok 判断，逻辑可能出错。
参数差异：v, ok := 中 <code>ok 是关键信号，而 v := 会静默吞掉关闭状态
- 发送前确保 channel 未关闭 —— 通常只由 sender 负责关闭，receiver 不应关
- 接收端务必用
v, ok := 判断是否关闭，尤其在 for 循环中 - for-range 遍历 channel 会在关闭后自动退出，但无法捕获关闭瞬间的边界状态
goroutine 泄漏：忘记 stop signal 或未处理 done channel
长期运行的 goroutine（如监听 loop）若没收到退出信号，会持续占用内存和栈空间，表现为 goroutine 数量随时间增长。
性能影响：泄漏的 goroutine 不仅吃内存，还增加调度器负担，尤其在高并发服务中易被压垮
- 所有长周期 goroutine 必须监听
ctx.Done()或自定义done chan struct{} - 启动 goroutine 时，确保有明确的退出路径，例如：
go func() { defer close(output) for { select { case <-ctx.Done(): return case item := <-input: output <- process(item) } } }() - 测试时可用
runtime.NumGoroutine()快速验证是否存在意外残留
最易被忽略的是：把 channel 当作队列用却忘了容量限制，或在 select 中依赖“某个 case 必然发生”——而实际它可能永远不发生。阻塞不是 Go 的 bug，是并发契约没写清楚的体现。
