Go Channel 详解：并发通信的正确姿势

Go Channel 详解：并发通信的正确姿势

"不要通过共享内存来通信，而要通过通信来共享内存。" ------ Go 并发哲学

Channel 是 Go 并发模型的核心。用对了，代码清晰、安全、优雅；用错了，死锁、panic、内存泄漏。

---

一、Channel 本质：它到底是什么

Channel 是一个有类型的管道，用于在 goroutine 之间传递数据。

go

`ch := make(chan int)      // 无缓冲通道
ch := make(chan int, 5)   // 缓冲通道，容量为5
`

类型	行为	比喻
无缓冲（unbuffered）	发送必须等接收，接收必须等发送	打电话，双方必须同时在线
有缓冲（buffered）	缓冲区未满可发送，缓冲区非空可接收	信箱，塞满之前不用等

核心规则（必须刻进脑子）：

• 发送到已满的缓冲通道 → 阻塞
• 接收已空的缓冲通道 → 阻塞
• 关闭的通道接收 → 返回零值，不阻塞
• 关闭的通道发送 → panic
• 对 nil 通道操作 → 永久阻塞

---

二、5 种核心用法，逐个拆

1. 单向发送 / 单向接收（最容易被忽略）

go

`func producer(ch chan<- int) {  // 只能发送
    ch <- 42
}

func consumer(ch <-chan int) {  // 只能接收
    v := <-ch
}
`

为什么重要？

• 编译器强制检查方向，防止误用
• 明确数据流向，代码自文档化
• 函数签名即约束：chan<- 只能写，<-chan 只能读

最佳实践：函数参数优先使用单向 channel，而非双向。

---

2. select 多路复用（并发调度器的核心）

go

`select {
case msg := <-ch1:
    fmt.Println("收到 ch1:", msg)
case ch2 <- 42:
    fmt.Println("发送到 ch2")
case <-time.After(3 * time.Second):
    fmt.Println("超时了")
default:
    fmt.Println("所有通道都没准备好，立刻返回")
}
`

select 的 4 条铁律：

规则	说明
随机选择	多个 case 同时就绪时，随机选一个执行
阻塞行为	无 default 且无就绪 case → 阻塞直到有一个就绪
default 分支	立即返回，不阻塞
nil 通道	永远不会被选中，直接忽略

经典模式：超时控制

go

`select {
case result := <-ch:
    return result
case <-time.After(5 * time.Second):
    return errors.New("超时")
}
`

---

3. range 遍历通道（优雅消费）

go

`for v := range ch {
    fmt.Println(v)
}
// 等价于：
for {
    v, ok := <-ch
    if !ok { break }  // 通道已关闭
    fmt.Println(v)
}
`

注意：range 循环会在通道关闭后自动退出，不需要手动检测 ok。

---

4. 关闭通道（90% 的人用错了）

go

`// ✅ 正确：发送方关闭
func sender(ch chan int) {
    for i := 0; i < 5; i++ {
        ch <- i
    }
    close(ch)  // 发送方关闭
}

// ❌ 错误：接收方关闭
func receiver(ch chan int) {
    v := <-ch
    close(ch)  // 危险！可能还有其他发送方
}

// ❌ 错误：重复关闭
close(ch)
close(ch)  // panic: close of closed channel
`

黄金法则：谁发送，谁关闭。永远不要在接收方关闭通道。

操作	结果
close(nil)	panic
重复 close()	panic
接收已关闭通道	返回零值，ok=false
发送到已关闭通道	panic

---

5. 单向转双向（类型安全的妥协）

go

`var sendOnly chan<- int = ch     // ✅ 编译通过
var recvOnly <-chan int = ch     // ✅ 编译通过
var both chan int = sendOnly      // ❌ 编译失败
`

这是 Go 类型系统的精妙之处：双向可以赋值给单向，但反过来不行。

---

三、5 个致命陷阱

陷阱 1：goroutine 泄漏

go

`// ❌ 泄漏：发送方退出后，接收方还在阻塞
func leak() {
    ch := make(chan int)
    go func() {
        for v := range ch {  // 永远等下去
            fmt.Println(v)
        }
    }()
    // 没有 close，也没有发送，goroutine 永远不退出
}
`

修复：发送方必须关闭通道，或用 context 取消。

---

陷阱 2：死锁（最常见的 panic）

go

`// ❌ 死锁：两个 goroutine 互相等对方
ch := make(chan int)
go func() { ch <- 1 }()     // 阻塞：没人接收
<-ch                         // 阻塞：没人发送
// fatal error: all goroutines are asleep - deadlock!
`

修复原则：每一个 send，都必须有对应的 recv；每一个 recv，都必须有对应的 send。

---

陷阱 3：向 nil 通道发送

go

`var ch chan int  // nil 通道，不是空通道！
ch <- 1          // 永久阻塞，不会 panic
`

空通道 vs nil 通道：

	make(chan int)	var ch chan int
状态	已初始化，空	nil
接收	阻塞	阻塞
发送	阻塞	阻塞
close	✅ 正常	panic
len/cap	0	0

永远用 make 初始化，不要依赖零值。

---

陷阱 4：缓冲通道当队列用，但忘了容量

go

`ch := make(chan int, 3)
ch <- 1
ch <- 2
ch <- 3
ch <- 4  // 阻塞！容量已满
`

缓冲不是"无限队列"，是"有界队列"。满了就阻塞，这是设计，不是 bug。

---

陷阱 5：select 中忘记 default

go

`select {
case ch <- 1:  // 如果 ch 满了且没人收，这里永久阻塞
}
// 没有 default，没有超时，没有其他 case → 死锁
`

---

四、实战模式：4 个经典并发模式

模式 1：Worker Pool（工作池）

go

`func workerPool(jobs <-chan int, results chan<- int, workers int) {
    var wg sync.WaitGroup
    for i := 0; i < workers; i++ {
        wg.Add(1)
        go func() {
            defer wg.Done()
            for job := range jobs {
                results <- process(job)
            }
        }()
    }
    wg.Wait()
    close(results)
}
`

关键点：

• jobs 是只读通道（<-chan）
• results 是只写通道（chan<-）
• 发送方关闭 jobs，所有 worker 自动退出

---

模式 2：Fan-Out / Fan-In（分散汇聚）

go

`// Fan-Out：一个入口，多个 worker 并行处理
func fanOut(input <-chan int) []<-chan int {
    outs := make([]<-chan int, 3)
    for i := range outs {
        ch := make(chan int)
        outs[i] = ch
        go func(out chan<- int) {
            for v := range input {
                out <- heavyWork(v)
            }
            close(out)
        }(ch)
    }
    return outs
}

// Fan-In：多个入口，汇聚到一个出口
func fanIn(ins ...<-chan int) <-chan int {
    out := make(chan int)
    var wg sync.WaitGroup
    for _, in := range ins {
        wg.Add(1)
        go func(ch <-chan int) {
            defer wg.Done()
            for v := range ch {
                out <- v
            }
        }(in)
    }
    go func() {
        wg.Wait()
        close(out)
    }()
    return out
}
`

---

模式 3：Pipeline（流水线）

go

`func pipeline(input <-chan int) <-chan int {
    // Stage 1: 过滤
    filtered := filter(input, func(x int) bool { return x%2 == 0 })
    // Stage 2: 映射
    mapped := mapFunc(filtered, func(x int) int { return x * 2 })
    return mapped
}
`

每个 stage 是一个 goroutine，通过 channel 串联，天然背压（backpressure）。

---

模式 4：Context + Channel（优雅取消）

go

`func worker(ctx context.Context, jobs <-chan int) {
    for {
        select {
        case job, ok := <-jobs:
            if !ok { return }
            process(job)
        case <-ctx.Done():  // 收到取消信号，立即退出
            fmt.Println("worker 退出:", ctx.Err())
            return
        }
    }
}
`

这是生产环境的标准写法：用 context 控制生命周期，用 channel 传递数据。

---

五、性能对比：Channel vs Mutex

维度	Channel	Mutex
适用场景	goroutine 间通信	同一 goroutine 内共享状态
性能	较慢（~2-3倍）	极快
安全性	编译期类型检查	运行时靠纪律
可读性	数据流向清晰	需要自行推理
调试难度	低（不会忘解锁）	高（忘 unlock 就死锁）

结论：能用 channel 就用 channel，只有在极度性能敏感且不跨 goroutine 时才用 mutex。

---

六、速查表

场景	写法
单向发送	chan<- T
单向接收	<-chan T
关闭通道	close(ch)，发送方操作
判断关闭	v, ok := <-ch，ok=false 表示已关
遍历通道	for v := range ch
超时	select { case v := <-ch: ... case <-time.After(t): ... }
默认非阻塞	select { case ... default: ... }
缓冲容量	make(chan T, n)
nil 检查	永远用 make 初始化

---

一句话总结：Channel 不是队列，是契约。发送方和接收方通过它达成同步，用对了是艺术，用错了是灾难。先想清楚谁发谁收谁关，再写代码。