17370845950

无缓冲 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。

• 正确做法：仅由**唯一生产者**负责 close(ch)；消费者用 for val := range ch 安全遍历，自动停在缓冲耗尽+关闭那一刻
• 反模式：多个 goroutine 同时往一个 channel 写，又没协调谁关；或关闭后还试图发送——Go 运行时会直接崩溃，不给你留机会
• 注意点：缓冲区大小影响关闭后的可读次数；make(chan int, 5) 关闭前写了 3 个，那 range 会迭代 3 次，第 4 次就退出

无缓冲 channel 的“同步性”是它的灵魂，不是缺陷；有缓冲 channel 的“异步性”是它的工具属性，不是免责金牌。真正难的从来不是语法，而是判断哪条 goroutine 路上该设红绿灯，哪条该修辅路。