Go不推荐直接用全局变量或mutex通信，因易致死锁、逻辑耦合强；channel显式编码生产/消费关系与类型安全，单向chan强化数据流约束，缓冲chan仅缓解阻塞而非消除竞态。
为什么 Go 不推荐直接用全局变量或 mutex 做 goroutine 间通信
因为 Go 的设计哲学是「不要通过共享内存来通信，而要通过通信来共享内存」。直接用 sync.Mutex 保护全局变量，容易漏锁、死锁、或在错误 goroutine 中解锁；更隐蔽的问题是：逻辑耦合强、难以追踪数据流向、并发意图不明确。channel 把“谁生产”“谁消费”“数据类型”“缓冲策略”都显式编码在类型和调用中，编译器能检查、运行时能阻塞/唤醒、pprof 能观测。
chan int 和 chan / 的区别直接影响安全边界
的区别直接影响安全边界单向 channel 类型是 Go 编译期强制的数据流约束。函数参数声明为 ，调用方就无法往里写；声明为 chan，就无法读。这比注释或文档可靠得多——它让「谁该发」「谁该收」在类型层面不可篡改：
func worker(in ：worker 只读输入、只写输出，不可能误操作反向 channel- 传入
make(chan int, 10)时，接收方若只声明，即使底层是双向 channel，也无法意外写入 - 避免多个 goroutine 同时写同一 channel 导致 panic：
send on closed channel
buffered channel 不等于“线程安全队列”，用错照样出问题
带缓冲的 chan int（如 make(chan int, 100)）只是缓解了发送方阻塞，并未消除竞态风险。常见误区：
- 把 channel 当作可随机访问的 slice：不能
c[5]，也不能遍历（除非用for range消费全部） - 关闭后继续 send → panic；关闭后 continue receive → 得到零值 +
false，但若没检查 ok，会静默丢数据 - 多个 goroutine 同时 close 同一个 channel → panic；必须确保仅由 sender 关闭
- 缓冲区满时 send 阻塞，但若 receiver 永远不启动，整个 goroutine 泄漏，
go tool trace里能看到 blocked send
替代方案对比：mutex + slice vs channel vs sync.Map
真要共享状态，选型要看场景：
立即学习“go语言免费学习笔记（深入）”；
- 需要严格顺序处理事件（如日志聚合、命令序列）→ 用
chan struct{}或带类型的 channel，天然有序、背压可控 - 高频读多写少的键值缓存 →
sync.Map比map + RWMutex更轻量，但不支持遍历、无原子 CAS - 必须原地修改某结构体字段 → 才用
sync.Mutex，且锁粒度越小越好（比如只锁字段所在 struct，而非全局） - 别用 channel 模拟锁：比如
sem := make(chan struct{}, 1)然后sem ，这比mutex.Lock()开销大、语义模糊、易忘
实际并发安全的关键不在“用了 channel”，而在是否让数据流动路径清晰、所有权转移明确、关闭时机可控。很多 bug 出现在 channel 生命周期管理上——比如 defer close 忘了判断是否已关闭，或者 select 里没加 default 导致 goroutine 永久阻塞。
