go并发模型基于csp，核心是goroutine+channel通信而非加锁；常见问题包括goroutine泄漏（缺退出机制）、channel阻塞/死锁（无缓冲需同步收发、缓冲满则阻塞）及数据丢失（忽略ok导致panic或死锁）。
Go 语言的并发模型不是靠加锁和线程调度，而是靠 goroutine + channel 构建的 CSP 模型——这意味着你写并发代码时，重点不是“怎么避免竞争”，而是“怎么设计通信”。直接上 go func() {}() 很容易出问题，关键在控制生命周期、协调退出、传递错误。
goroutine 泄漏：为什么你的程序内存持续上涨
最常见问题是启动了 goroutine 却没给它退出路径。比如在循环里无条件启一个 goroutine 去处理网络请求，但没加超时或取消机制，一旦后端响应慢或失败，goroutine 就卡在 read 或 select 上永远不返回。
- 永远不要在 for 循环中裸写
go doWork()，除非doWork是纯同步、有明确结束点的函数 - 用
context.Context控制生命周期：go doWork(ctx)，并在函数内定期检查ctx.Done() - 启动前确认 channel 是否已关闭；从 channel 读取时别忽略
ok返回值，否则可能 panic 或死锁
channel 使用不当：阻塞、死锁与数据丢失
channel 不是队列，它是同步原语。无缓冲 channel 的发送/接收必须成对出现，否则必阻塞；有缓冲 channel 虽能暂存数据，但缓冲区满后仍会阻塞发送者。
- 发送到已关闭的 channel 会 panic，接收已关闭的 channel 会立即返回零值 +
false（val, ok := ） - 用
select处理多个 channel 时，如果所有 case 都不可达且没有default，当前 goroutine 会永久阻塞 - 不要用 channel 传大量数据（如 []byte），而是传指针或 ID，避免拷贝开销和 GC 压力
sync.WaitGroup 与 context.WithCancel 配合控制批量 goroutine
想等一批 goroutine 全部完成？sync.WaitGroup 是基础，但它不处理中途取消。真实场景往往需要“任意一个失败就全部停止”。
立即学习“go语言免费学习笔记（深入）”；
- 先用
ctx, cancel := context.WithCancel(context.Background())创建可取消上下文 - 每个 goroutine 启动时都接收该
ctx，并在关键位置调用if ctx.Err() != nil { return } - 主 goroutine 在
wg.Wait()前或出错时调用cancel()，通知所有子 goroutine 退出 - 注意：
WaitGroup.Add()必须在go之前调用，不能放在 goroutine 内部
真正难的不是启动并发，而是定义清楚“谁负责关闭 channel”“谁决定取消”“错误如何透出”。这些边界一旦模糊，goroutine 就会变成黑盒里的幽灵——跑着，但没人知道它还在不在，有没有卡住，有没有漏掉结果。
