无缓冲 channel 的发送和接收必须在不同 goroutine 中成对发生，否则会阻塞导致死锁；它像无存水空间的水管，一端发送时另一端必须立即接收。
channel 是 Go 协程间通信的唯一推荐方式，不是“可以选”，而是“应该用”——它把“谁在读、谁在写、数据何时就绪”这些并发细节全收进语言原语里，比手动加锁安全得多，也比共享变量清晰得多。
无缓冲 channel 怎么发和收？阻塞是它的天性
无缓冲 chan 就像一根没有存水空间的水管：一端开闸（发送），另一端必须立刻接水（接收），否则双方都卡住。这不是 bug，是设计。
常见错误现象：
fatal error: al典型场景：主 goroutine 向无缓冲l goroutines are asleep - deadlock!
ch 发送数据，但没起接收协程，或接收协程还没启动。
- 发送和接收必须成对出现，且发生在不同 goroutine 中（除非用
select+default做非阻塞试探） - 不要在同一个 goroutine 里先
ch 再，这等于自己等自己 - 调试时可用
go tool trace看 goroutine 是否卡在chan send或chan recv上
带缓冲 channel 的容量怎么设？别乱填 1024
make(chan int, N) 的 N 不是越大越好，它是背压缓冲区，本质是“允许发送者比接收者快多少”。
性能影响：缓冲区过大会掩盖处理瓶颈，让内存占用虚高；过小则频繁阻塞，吞吐上不去。
- 若用于任务队列（如 worker pool），
N通常设为预期并发数 × 1.5～2，比如 10 个 worker 就配 15～20 - 若只是做信号通知（如
done chan struct{}），用无缓冲更轻量，make(chan struct{})即可 - 用
len(ch)查当前已存元素数，cap(ch)查最大容量，二者差值就是还能塞几个
关闭 channel 后还能读吗？怎么判断它关了？
close(ch) 只表示“不会再有新数据写入”，但已进队列的数据仍可读完。这是关键区别：关通道 ≠ 清空通道。
常见错误：直接 v := 而不检查是否关闭，导致收到零值（如 0、""、nil）误判为有效数据。
- 用双返回值语法：
v, ok := ，ok == false表示通道已关闭且无剩余数据 - 用
for range ch自动读完并退出，但前提是发送端必须调用close(ch)，否则会死锁 - 切记：对已关闭的
ch再执行ch 会 panic，所以只应在发送端明确知道“发完了”时才关
select 多路监听时，为什么有时收不到数据？
select 不是轮询，而是同步等待任意一个 case 就绪。如果所有 case 都阻塞，且没写 default，就会永远卡住。
典型陷阱：多个 case 中，某个 ch 已关闭但没做 ok 判断，导致该分支持续返回零值，select 认为它“就绪”，反复选中它。
- 每个
case接收时务必用v, ok := 检查状态，关闭后及时把ch设为nil（nil的 channel 在select中永远不就绪） - 超时控制统一用
，别手写计时器 - 避免在
select外层套for却忘了break，容易漏掉退出条件
Go 的 channel 看似简单，但真正难的是理解“阻塞”背后的调度逻辑——它不是线程挂起，而是 goroutine 被从运行队列摘下，等对方就绪再唤醒。这个细节决定了你写的并发程序是健壮还是脆弱。
