缓冲 channel 是固定容量队列，用 make(chan t, cap) 创建，cap≥0；cap=0 等价于无缓冲 channel；写满或读空时阻塞；核心用途是解耦收发时机，非提速；关闭后可读尽剩余数据，再读返回零值和 false。
缓冲 channel 的创建和基本行为
缓冲 channel 不是“带缓存的管道”，而是有固定容量的队列——写入不阻塞，直到队列满；读取不阻塞，直到队列空。它解决的是生产者和消费者节奏不一致时的临时暂存问题，不是性能优化银弹。
- 用
make(chan T, cap)创建，cap必须是整数，不能为负或运行时动态改 - 容量为 0 就是无缓冲 channel，等价于
make(chan T)，别误以为make(chan T, 0)是“空缓冲”——它就是同步 channel - 向已满的缓冲 channel 写入会阻塞当前 goroutine，直到有其他 goroutine 从中读取；同理，从空 channel 读也会阻塞
- 注意：缓冲 channel 的长度（当前元素个数）用
len(ch)获取，容量用cap(ch)，两者常被混淆
什么时候该用缓冲 channel，而不是无缓冲
核心判断标准只有一条：你是否明确需要「解耦发送与接收时机」。不是“为了快”，而是“必须容忍短暂延迟”。
- 日志采集：日志 producer 可以快速写入
logCh := make(chan string, 1000)，后台 goroutine 慢慢刷盘，避免主线程因 I/O 卡住 - 限流场景：配合
time.Ticker做令牌桶，用缓冲 channel 存几枚“预发放”的令牌，避免每次请求都等 ticker 触发 - 避免死锁：两个 goroutine 直接用无缓冲 channel 通信，若双方都先写后读，必死锁；加缓冲（哪怕 cap=1）可打破严格顺序依赖
- 反例：HTTP handler 中把请求丢进缓冲 channel 然后立刻返回，却不保证后续有人消费——channel 会积压、OOM，这不是解耦，是甩锅
关闭缓冲 channel 后的读取行为
关闭后仍可读取剩余数据，但读完就永远返回零值 + false。这点和无缓冲 channel 完全一致，但更容易出错，因为“还有数据没读完”这个状态更隐蔽。
Go语言（Golang）1.26.0
下载
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
- 关闭前请确保没有 goroutine 在往里写，否则 panic：
send on closed channel - 用
for v, ok := 循环读取最安全，<code>ok为false表示 channel 关闭且无剩余数据 - 不要依赖
len(ch) == 0判断是否该退出读取——可能刚读完一个，另一个 goroutine 又写入了一个，len瞬间非零 - 如果多个 goroutine 并发写入，应由写方统一关闭（比如用
sync.WaitGroup计数），而非读方猜着关
常见陷阱：缓冲大小设多少才合适
没有通用答案。设太大等于放任内存堆积，设太小等于没解决问题。关键看你的业务容忍的“最大积压量”和“最长等待时间”。
-
cap=1能破掉很多同步死锁，但仅此而已；它不提供任何“缓冲余量”，只是让写操作有机会“抢在读之前完成一次” - 别用
math.MaxInt64或超大常量假装“无限缓冲”——这会让 GC 压力陡增，且掩盖了背压缺失的设计缺陷 - 真实服务中，建议从
cap=16或cap=64起步，上线后观察len(ch)的 P99 值，持续接近cap就说明要么消费者太慢，要么容量真不够 - 注意：channel 的缓冲区是堆上分配的数组，
make(chan struct{}, N)比make(chan int, N)内存开销小得多，结构体越小越好
缓冲 channel 的真正复杂点不在语法，而在对数据流节奏的预判——你得清楚谁快、谁慢、慢到什么程度会出事，以及出事时你希望系统降级还是报错。这些没法靠 cap 数字自动解决。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
