Go 中 buffered channel 是带固定容量队列的异步通信机制，通过 make(chan T, capacity) 创建，capacity>0 时为 buffered；发送至未满通道不阻塞，接收自非空通道不阻塞，满则发送阻塞，空则接收阻塞。
在 Go 中，buffered channel 是控制数据缓冲和实现异步处理的核心机制之一。它不像 unbuffered channel 那样要求发送与接收必须同步发生，而是提供一个固定容量的队列，让发送方在不阻塞的情况下将数据写入（只要缓冲区未满），接收方则从队列中按顺序读取。合理使用 buffered channel 能有效解耦生产者与消费者、平滑流量峰值、避免 goroutine 泄漏。
理解 buffered channel 的创建与基本行为
通过 make(chan T, capacity) 创建带缓冲的 channel，其中 capacity 必须是非负整数。当 capacity 为 0，即 make(chan T)，就是 unbuffered channel；大于 0 才是 buffered。
关键行为：
- 向未满的 buffered channel 发送数据不会阻塞
- 从非空的 buffered channel 接收数据不会阻塞
- 向已满的 channel 发送会阻塞，直到有 goroutine 接收数据腾出空间
- 从空的 channel 接收会阻塞，直到有 goroutine 发送新数据
例如：ch := make(chan int, 3) 创建一个最多存 3 个 int 的 channel。连续发送 3 次 ch 、ch 、ch 不会阻塞；第 4 次才会挂起，直到有人执行 。
立即学习“go语言免费学习笔记（深入）”；
用 buffered channel 实现异步任务提交与批量处理
常见场景：接收大量请求但不想立即处理，而是攒一批再统一执行（如日志写入、指标上报、数据库批量插入）。
做法是启动一个后台 goroutine 持续从 channel 读取，用切片暂存，达到阈值或超时后批量处理：
ch := make(chan string, 100) // 缓冲 100 条日志go func() { var batch []string ticker := time.NewTicker(1 * time.Second) defer ticker.Stop()
for { select { case msg := <-ch: batch = append(batch, msg) if len(batch) >= 50 { flushLogs(batch) batch = batch[:0] } case <-ticker.C: if len(batch) > 0 { flushLogs(batch) batch = batch[:0] } } }}()
这里
ch的缓冲能力让主流程快速提交日志而不被 I/O 拖慢，后台 goroutine 控制节奏，兼顾实时性与吞吐。避免缓冲区溢出与 goroutine 泄漏的实用技巧
buffered channel 不是万能的“保险箱”，若消费者长期停滞，缓冲区终将填满，导致生产者阻塞甚至死锁。需主动防护：
- 用
select+default实现非阻塞发送：select { case ch - 结合
context设置超时：select { case ch - 监控 channel 当前长度：
len(ch)和容量：cap(ch)，便于调试与告警 - 确保消费者 goroutine 不意外退出，必要时用
recover或sync.WaitGroup管理生命周期
对比 unbuffered vs buffered：何时选哪个？
选择依据不是“性能更好”，而是语义是否匹配：
- 需要严格同步协作（如等待初始化完成、信号通知）→ 用 unbuffered channel
- 要解耦快慢组件、容忍短暂延迟、提升吞吐 → 用 buffered channel
- 不确定负载波动范围 → 先设较小 buffer（如 16 或 64），上线后根据
len(ch)监控动态调优 - 完全无法预估峰值且内存敏感 → 考虑搭配限流器（如
golang.org/x/time/rate）或 ring buffer 库
记住：buffer 太小易频繁阻塞，太大浪费内存且掩盖设计问题。典型经验值在 16–1024 之间，具体看业务吞吐特征。
