在 Go 语言并发编程里，通道（channel）承担着 goroutine 之间数据传递的职责。当我们需要明确知道通道中只会有有限数量的数据，并且发送方会在结束后关闭通道时，消费端的处理逻辑和持续监听的无限流场景并不相同。如果沿用错误的接收方式，不仅会造成资源浪费，还可能引发程序死锁或协程无法退出。
有限数据量通道的典型特征
有限数据量的通道通常指那些在业务逻辑上数据条数可知、发送方明确调用 close 关闭的通道。例如批量任务分发，主协程生成一百个任务写入通道，然后关闭通道通知所有 worker 结束。这种场景下，消费者不需要担心“后面还有没有数据”的不确定性，只需把已有数据消费完即可。
与之相对的是无限数据流，比如网络消息推送，通道可能长期不关闭。两类通道如果混用消费模式，就容易出现问题。很多初学者在有限数据场景里写了死循环去读通道，又没有正确处理关闭信号，导致接收端一直阻塞。理解数据量边界，是选对消费方式的前提。
使用 for-range 自动退出
Go 为通道提供了非常简洁的 for-range 语法。当通道被发送方关闭后，range 会在读取完剩余数据后自动结束循环，对应的 goroutine 也能自然退出。这是处理有限数据量通道最推荐的做法，既不容易出错，也无需手动判断 ok 值。
下面示例展示一个发送固定三个字符串并关闭通道，消费者用 range 接收的过程：
package main
import "fmt"
func main() {
ch := make(chan string, 3)
// 发送方写入有限数据
go func() {
ch <- "task1"
ch <- "task2"
ch <- "task3"
close(ch) // 发送完毕关闭通道
}()
// 消费方使用 range 自动退出
for v := range ch {
fmt.Println("received:", v)
}
fmt.Println("channel closed, consumer done")
}
上述代码中，发送协程在写入三个值后调用 close，主协程的 range 在拿到这三个值且发现通道关闭后，跳出循环并打印结束语句。整个过程没有多余的判断，也不会泄漏 goroutine。
需要注意，close 只能由发送方调用。如果在接收端关闭通道，或者多次关闭同一个通道，运行时会触发 panic。因此在有限数据模型中，要明确职责边界。
带缓冲与无缓冲的差异
有限数据通道可以选择带缓冲或无缓冲。带缓冲通道如 make(chan int, 10) 允许发送方在接收方未就绪时先放入数据，只要不超过容量就不会阻塞；无缓冲通道则要求发送和接收同时就绪，否则一方阻塞。在有限数据量较小且已知的场景，带缓冲能降低协程调度开销。
但如果缓冲容量小于数据总量，发送方在缓冲满时仍会阻塞，直到被消费。下面用表格对比二者在有限数据消费中的表现：
| 类型 | 发送阻塞条件 | 适用有限数据场景 |
|---|---|---|
| 无缓冲通道 | 接收方未就绪即阻塞 | 需要严格同步、数据量极少 |
| 带缓冲通道 | 缓冲满且无人接收 | 批量已知数据、降低耦合 |
从表中可以看出，若我们已经预知数据条数，直接把缓冲设为数据量大小，发送方就能一口气写完并关闭，消费者再用 range 收尾，逻辑十分清晰。
常见误用与避坑
第一种误用是在有限数据场景使用 select 加 default 空转。例如下面这段代码：
for {
select {
case v, ok := <-ch:
if !ok {
return
}
fmt.Println(v)
default:
// 空转，浪费 CPU
}
}
这种写法在通道暂时没数据时不断循环，占用大量 CPU。有限数据消费并不需要这样的轮询，直接用 range 或阻塞接收就好。
第二种误用是接收端关闭通道。有些开发者在消费者发现一段时间没收到数据就主动 close，这会造成其他接收者读取到已关闭通道而 panic。通道关闭权应固定在数据生产侧。
多消费者场景的退出信号
当有限数据需要多个 worker 并发消费时，可以借助 sync.WaitGroup 等待所有 worker 结束。每个 worker 用 range 读同一个通道，发送方发完关闭通道，worker 自行退出，WaitGroup 在全部退出后放行主流程。
package main
import (
"fmt"
"sync"
)
func main() {
ch := make(chan int, 5)
var wg sync.WaitGroup
for i := 0; i < 3; i++ {
wg.Add(1)
go func(id int) {
defer wg.Done()
for v := range ch {
fmt.Printf("worker %d got %dn", id, v)
}
}(i)
}
for i := 0; i < 5; i++ {
ch <- i
}
close(ch)
wg.Wait()
fmt.Println("all workers done")
}
该模型在有限数据下非常稳健：通道关闭后，三个 worker 的 range 均自然结束，WaitGroup 等待它们全部完成，主函数才退出。没有残留协程，也没有复杂的退出通知逻辑。
总结来说，面对有限数据量的通道，核心原则是发送方负责关闭、接收方用 for-range 或阻塞接收、不轮询不抢关。把握这几点，就能写出清晰且不泄漏资源的 Go 并发代码。