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

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

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

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

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

go 复制代码

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

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

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

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

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

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

go 复制代码

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

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

为什么重要？

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

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

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

go 复制代码

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 复制代码

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

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

go 复制代码

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

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

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

go 复制代码

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 复制代码

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

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

三、5 个致命陷阱

陷阱 1：goroutine 泄漏

go 复制代码

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

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

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

go 复制代码

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 复制代码

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 复制代码

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

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

陷阱 5：select 中忘记 default

go 复制代码

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

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

模式 1：Worker Pool（工作池）

go 复制代码

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 复制代码

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 复制代码

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 复制代码

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 不是队列，是契约。发送方和接收方通过它达成同步，用对了是艺术，用错了是灾难。先想清楚谁发谁收谁关，再写代码。