应优先使用 channel 而非共享内存加锁，因 Go 哲学主张“通过通信共享内存”；unbuffered channel 天然阻塞同步，适用于等待完成或请求-响应场景。
l 天然阻塞同步，适用于等待完成或请求-响应场景。在 Go 语言中，协程（goroutine）间的数据传递应**优先使用 channel**，而非共享内存加锁。这是 Go 的设计哲学——“不要通过共享内存来通信，而应通过通信来共享内存”。channel 天然支持同步、阻塞、缓冲控制和类型安全，是实现 goroutine 安全协作的核心机制。
用 unbuffered channel 实现同步协作
无缓冲 channel 在发送和接收操作上必须配对阻塞，天然适合“等待完成”或“请求-响应”场景。
- 发送方会阻塞，直到有 goroutine 准备好接收；接收方同理
- 适合主协程等待子任务结果，例如启动一个 goroutine 计算并返回值
示例：
go func(ch chan int) {result := heavyComputation()
ch }(ch)
val :=
用 buffered channel 控制并发与解耦生产/消费
带缓冲的 channel 允许发送端在缓冲未满时不阻塞，接收端在缓冲非空时不阻塞，适用于异步处理、任务队列、背压控制等场景。
- 缓冲大小决定最大待处理任务数，可防止内存无限增长
- 常配合
range配合close()实现消费者循环
示例：
jobs := make(chan int, 10)results := make(chan int, 10)
// 启动多个 worker
for i := 0; i go worker(jobs, results)
}
// 发送任务（不阻塞，直到缓冲满）
for j := 0; j jobs }
close(jobs) // 告知 workers 不再有新任务
避免常见陷阱：死锁与泄漏
channel 使用不当极易引发死锁（fatal error: all goroutines are asleep）或 goroutine 泄漏。
- 永远不要在单个 goroutine 中对 unbuffered channel 同时读写——必然死锁
- 向已关闭的 channel 发送数据会 panic；从已关闭且无数据的 channel 接收会立即返回零值
- 记得关闭 channel（仅由发送方关闭），并在消费者中用
for v := range ch或ok判断是否关闭
安全接收写法：
if val, ok := fmt.Println("received:", val)} else {
fmt.Println("channel closed")
}
替代方案对比：为什么不用 mutex + 全局变量？
虽然用 sync.Mutex 保护共享变量也能实现数据传递，但会带来明显问题：
- 需手动管理锁粒度、加锁顺序，易出现竞态、死锁或遗忘解锁
- 无法自然表达“等待数据就绪”的语义，往往要搭配条件变量或轮询，代码复杂
- 难以追踪数据流向，调试困难；channel 则把通信逻辑显式暴露在代码流中
channel 是 Go 对 CSP（Communicating Sequential Processes）模型的实践，它让并发逻辑更清晰、更健壮、更易测试。
