无缓冲 channel 一发就卡住是因为同步通信：发送操作 ch
无缓冲 channel 为什么一发就卡住？
因为它是同步通信：发送操作 ch 会**立即阻塞**，直到有 goroutine 同时执行 。不是“稍后处理”，而是“必须此刻配对”。这就像两人击掌——手没碰到，动作就不算完成。
- 常见错误现象：
fatal error: all goroutines are asleep - deadlock，尤其在只发不收、或只收不发的单向使用中 - 典型场景：协程启动同步（如
done := make(chan bool)）、任务完成通知、临界区进入/退出信号 - 不要把它当“小缓冲=1”用——
make(chan int)和make(chan int, 1)行为本质不同：前者强制双方就绪；后者允许发送方“甩完就走”，哪怕没人立刻来取
有缓冲 channel 的缓冲大小怎么设才不翻车？
缓冲不是越大越好，它本质是**背压策略的显式表达**。设成 1000 不代表你撑得住 1000 条消息，只代表你把背压延迟了、藏起来了。
- 误用后果：缓冲过大 → 消费端卡住时，生产端仍疯狂写入 → 内存暴涨甚至 OOM；缓冲过小（如设为 1）→ 几乎退化为无缓冲，但失去语义清晰性
- 合理参考值：按「峰值突发量 × 最大容忍延迟」估算。例如：每秒最多突增 50 个任务，消费端最长卡顿 200ms → 缓冲 ≈ 50 × 0.2 = 10，再加点余量设为 16 或 32
- 参数差异：
make(chan int, 0)是非法语法；make(chan int)等价于make(chan int, 0)（但写法上禁止显式写 0），而make(chan int, 1)就是合法最小缓冲
性能对比：有缓冲就一定更快吗？
不一定。快慢取决于你的通信节奏是否匹配 channel 类型。无缓冲在低频信号场景下延迟更低；有缓冲在高吞吐流水线中吞吐更高——但前提是消费端跟得上。
- 真实瓶颈常不在 channel 本身，而在接收端逻辑耗时。比如
ch := make(chan int, 1000)，若每次都要查数据库，缓冲再大也救不了吞吐 - 同步开销差异微乎其微：Go runtime 对两类 channel 的底层调度路径已高度优化，别为“少一次调度”选型
- 关键判断点：问自己——“我需要确保发送那一刻数据已被处理（选无缓冲）”，还是“我只要确保数据不丢、能暂存（选有缓冲）”
关闭 channel 前必须注意的三件事
关闭只应由**唯一生产者**发起，且必须在所有发送完成后。对已关闭的 channel 发送会 panic；接收则返回零值 + false。
立即学习“go语言免费学习笔记（深入）”；
- 常见错误：多个 goroutine 同时向同一 channel 发送并尝试 close → 竞态 + panic
- 安全模式：用
sync.Once包裹 close，或让启动 goroutine 的主逻辑负责关闭 - 接收端别偷懒写
for v := range ch就完事——如果 channel 永远不关，这个循环永不结束；务必配合超时、条件退出或外部信号控制
真正难的不是记住“无缓冲同步、有缓冲异步”，而是每次写 make(chan ...) 时，停下来问一句：我此刻要协调的是时间点，还是数据流？
