无缓冲 channel 一发就卡住是因为它是同步通信：ch := make(chan int) 创建的通道容量为 0，发送操作 ch
无缓冲 channel 为什么一发就卡住？
因为它是同步通信：ch := make(chan int) 创建的通道容量为 0，发送操作 ch 会**立即阻塞**，直到有 goroutine 同时执行 。这不是“延迟”，而是设计上的强制握手——就像两人面对面交文件，没人伸手接，你就不能松手。
- 常见错误现象：主 goroutine 先发后收，或只发不收，程序直接死锁（panic: send on closed channel 或 fatal error: all goroutines are asleep）
- 典型适用场景：任务完成通知（
done := make(chan struct{})）、启动协调（等待子 goroutine 初始化完毕）、信号同步（如暂停/恢复控制流） - 关键提醒：它不占额外内存，但对执行顺序极其敏感；别指望它“暂存数据”，它根本没地方存
有缓冲 channel 的“缓冲”到底缓在哪？
缓冲区是 channel 内部的一块固定大小的队列，由 make(chan int, 3) 中的 3 指定。只要队列没满，ch 就立刻返回；只要队列非空， 也立刻返回。它不是万能队列，而是一道可控的“泄洪闸”。
- 常见错误现象：设了大缓冲（比如
make(chan int, 10000)）却忘了消费，goroutine 不断写入，内存暴涨，最后 OOM - 参数差异：缓冲大小必须是编译期常量或变量，但创建后不可变；设为 0 等价于无缓冲，设为负数会 panic
- 性能影响：小缓冲（如 1–16）可平滑突发流量，几乎无开销；过大则掩盖背压问题，让生产者盲目快跑，消费者永远追不上
怎么选？看通信意图，而不是看“要不要等”
别被“阻塞/不阻塞”带偏——真正该问的是：“我需要双方严格步调一致，还是允许短暂脱节？”
- 选无缓冲：
ch := make(chan bool)用于事件通知；quit := make(chan struct{})用于优雅退出；任何需要“发完立刻知道对方已收”的场景 - 选有缓冲：
jobs := make(chan *Task, 10)做任务队列；logs := make(chan string, 100)收集日志避免主线程卡顿；生产速率偶尔尖峰、消费相对稳定时 - 容易踩的坑：混用两种语义——比如用有缓冲 channel 做同步信号，结果因缓冲未满发送成功，但接收方迟迟未读，逻辑就悄悄错位了
关闭 channel 时，缓冲区里的数据还安全吗？
安全，但行为不同：对已关闭的 channel， 仍能读出缓冲区内剩余数据，读完才返回零值和 false；但继续 ch 会 panic。
立即学习“go语言免费学习笔记（深入）”；
- 正确做法：仅由**唯一生产者**负责
close(ch)；消费者用for val := range ch安全遍历，自动停在缓冲耗尽+关闭那一刻 - 反模式：多个 goroutine 同时往一个 channel 写，又没协调谁关；或关闭后还试图发送——Go 运行时会直接崩溃，不给你留机会
- 注意点：缓冲区大小影响关闭后的可读次数；
make(chan int, 5)关闭前写了 3 个，那range会迭代 3 次，第 4 次就退出
无缓冲 channel 的“同步性”是它的灵魂，不是缺陷；有缓冲 channel 的“异步性”是它的工具属性，不是免责金牌。真正难的从来不是语法，而是判断哪条 goroutine 路上该设红绿灯，哪条该修辅路。
