channel是go语言中goroutine间通信的唯一正统方案，它将数据传递与同步控制统一，通过阻塞机制天然规避竞态，比全局变量加mutex更安全、可推理且表达力更强。
Go 里进程内通信（准确说是 goroutine 间通信）基本就靠 channel，没有别的“标准方案”可选。它不是备选之一，而是语言层面强制推荐的唯一正统路径。
为什么不能直接用全局变量或 mutex 共享数据
共享内存本身不带同步语义，mutex 只解决临界区互斥，但不表达“谁该等谁”“数据何时就绪”这类协作逻辑。容易漏锁、死锁、或写出看似正确实则竞态的代码。而 channel 把通信和同步绑在一起：一次发送必然对应一次接收（无缓冲时），天然规避了“数据写完但没人读”或“读了但还没写”的错序问题。
- 全局变量 +
sync.Mutex：你得自己维护读写顺序、生命周期、唤醒时机，出错概率高 -
channel：发送阻塞直到有人接收（无缓冲），或缓冲满才阻塞（有缓冲），行为确定、可推理 - 实际项目中，90% 的 goroutine 协作场景（如任务分发、结果收集、信号通知）用
channel表达更直白，也更难写错
无缓冲 channel 和有缓冲 channel 怎么选
关键看是否需要“解耦发送与接收的时间点”：
- 用
make(chan int)（即容量为 0）：适合强同步场景，比如“必须等 A 完成后 B 才能开始”。发送方会卡在ch 直到另一端执行 <code>，二者手递手交接 - 用
make(chan int, N)（N > 0）：适合削峰填谷，比如日志收集器批量攒够 10 条再刷盘。发送方只要缓冲没满就不会阻塞；但注意：缓冲区满后仍会阻塞，不是完全异步 - 别迷信“有缓冲就一定不卡”——如果接收方长期不消费，缓冲迟早满，发送最终还是会挂住
常见 panic 和怎么避开
最常踩的三个坑都跟 nil、关闭、类型有关：
-
send on nil channel：声明了var ch chan int没make就直接ch 。永远先 <code>ch := make(chan T)再用 -
send on closed channel：对已关闭的ch执行ch 。只有 sender 能关，且关完就别再发；receiver 侧用 <code>v, ok := 判断是否已关 invalid operation: ：同第一个，本质还是未初始化。注意函数参数传入的 <code>chan也要检查是否为nil（虽然通常由调用方保证）
select + default 是防卡死的刚需写法
单独写 或 <code>ch 在对方 goroutine 已退出或逻辑异常时，会永久阻塞。生产代码里几乎都要加保护：
- 非阻塞探测：
select { case v := ，避免空转忙等 - 带超时接收：
select { case v := ，防止某条路径彻底失联 - 多 channel 监听：
select随机挑一个就绪分支，不会按代码顺序执行；若需优先级，得靠嵌套select或重试逻辑
真正难的不是语法，而是设计时想清楚：哪些 goroutine 必须严格串行？哪些可以并行但需限流？哪边是唯一 sender？哪边负责关闭？这些决策一旦定错，channel 反而会把死锁藏得更深。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
