无缓冲channel本质是同步通信载体，非控制工具；其核心作用是强制收发双方同时就绪以实现精确同步，常用于信号通知、任务完成等待等场景，但误用会导致死锁或阻塞。
直接说结论：channel 本身不是“控制工具”，而是数据流转与同步的载体；真正起控制作用的是你如何设计发送/接收时机、缓冲策略、关闭逻辑和 select 分支。框架里用 channel，关键不是套模板，而是把每个 channel 的语义想清楚——它到底代表什么：是任务、结果、信号，还是限流令牌？
无缓冲 channel 为什么常被误用为“等待完成”
很多人写 done := make(chan bool) 然后在 goroutine 里 done ，主协程 <code> 等待。这看似可行，但隐藏两个问题：
- 如果 goroutine panic 或提前 return，
done 永远不执行，主协程永久阻塞 - 多个 goroutine 共用一个无缓冲 channel 发送完成信号时，只有一个能成功，其余会卡死（因为没人接收）
更稳妥的做法是配合 sync.WaitGroup：先 wg.Add(1)，goroutine 结尾 defer wg.Done()，主协程调用 wg.Wait()。channel 只在需要传递具体结果或错误时才介入。
带缓冲 channel 用作任务队列时的常见陷阱
比如 jobs := make(chan int, 100) 分发任务，worker 从里面读取并处理。容易踩的坑有：
- 缓冲大小设为 100 不等于“最多并发 100 个任务”——它只表示最多积压 100 个未处理任务，worker 数量仍可能远超这个数
- 主协程发完所有任务后，必须显式
close(jobs)，否则 worker 的for job := range jobs永远不会退出 - worker 内部若发生 panic，没 recover 就会静默退出，导致部分任务丢失，且
range无法感知该 worker 已死
建议 worker 加一层 wrapper：go func() { defer func() { if r := recover(); r != nil { log.Printf("worker panic: %v", r) } }(); processJob(job) }()
select + timeout 是防止 channel 卡死的刚需手段
任何从 channel 接收的操作，只要不能 100% 确保对方一定会发，就必须加超时。比如调用第三方 API 后往 resultCh 写结果，但 API 可能 hang 住：
select {
case res := <p>注意：<code>time.After</code> 在循环里反复调用会泄漏 timer，应改用 <code>time.NewTimer</code> 并在每次使用后 <code>Reset</code>；也不要在一个 <code>select</code> 里重复监听同一个已关闭的 channel，会导致分支永远就绪、忙等。</p><h3>关闭 channel 的时机比你想的更敏感</h3><p>channel 只能由发送方关闭，且只能关一次。但在多生产者场景下（比如多个 worker 往同一个 <code>results</code> channel 写），谁来关？什么时候关？</p>
- 不能由任意一个 worker 关——会 panic
- 不能等所有 worker 都退出后再关——主协程不知道它们啥时候退完
- 正确做法是用
sync.WaitGroup管理 worker 生命周期，主协程wg.Wait()完再close(results)
接收方必须用 v, ok := 判断是否关闭，尤其在 <code>for range 中——range 自动检测关闭，但若中间有其他 channel 要监听，就得手动检查 ok，否则可能漏掉最后一批数据或提前退出。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
