带缓冲通道声明必须用make(chan t, n)且n为大于0的编译期常量；cap(ch)>0可确认为带缓冲通道；缓冲容量需权衡内存与背压，典型值为16–256，不可动态修改。
声明带缓冲的通道变量的语法结构
Go 语言中，带缓冲的通道必须显式指定缓冲区容量，不能像无缓冲通道那样只写 chan T。核心区别在于 make 调用的第三个参数：它必须是编译期常量整数，且大于 0。
常见错误是写成 var ch chan int = make(chan int, 0)（这其实是无缓冲通道）或 make(chan int, -1)（运行时报 panic），又或者用变量而非常量做容量（编译失败）。
-
ch := make(chan int, 10)—— 正确：容量为 10 的 int 类型带缓冲通道 -
var ch chan string = make(chan string, 5)—— 正确：显式类型 + 常量容量 -
n := 3; ch := make(chan bool, n)—— 错误：容量必须是常量，此处 n 是变量，编译不通过 -
ch := make(chan struct{}, 1)—— 合理：适合仅需信号通知、不传数据的场景
缓冲容量设多少才合适？
缓冲容量不是越大越好，它直接影响内存占用和行为语义。设得太小（如 1）接近无缓冲通道；设得太大（如 10000）可能掩盖背压问题，甚至引发 OOM。
典型参考值：
- 用于解耦生产/消费速率差异：设为平均单次批量大小的 2–3 倍（例如日志批量写入，平均一批 100 条，可设缓冲为 256）
- 用于限流信号通道（如令牌桶）：常设为 1，配合
select非阻塞尝试 - 纯异步通知（无数据内容）：
chan struct{}+ 容量 1 最省空间 - 不确定负载时，优先从 16 或 64 开始压测，再根据
len(ch)和cap(ch)监控调整
声明后怎么判断是不是带缓冲通道？
Go 运行时无法直接反射出“是否带缓冲”，但可通过行为和属性间接确认：
- 调用
cap(ch)返回非零值 → 一定是带缓冲通道（无缓冲通道的cap恒为 0） - 对空通道执行
len(ch)返回 0，但能成功发送（不阻塞）→ 很可能带缓冲（前提是没其他 goroutine 在接收） - 注意：
reflect.TypeOf(ch).Kind() == reflect.Chan无法区分有无缓冲，二者底层类型相同
所以最可靠的方式始终是：看声明时 make 是否传了大于 0 的第三个参数，并在代码中保留该信息（比如用命名常量 const logChanCap = 128）。
带缓冲通道的常见误用陷阱
缓冲通道容易让人误以为“永远不会阻塞”，其实只是延迟了阻塞时机。真正危险的是忽略缓冲耗尽后的表现。
- 往已满缓冲通道发数据 → 当前 goroutine 阻塞，直到有接收者腾出空间；若无人接收，程序可能死锁
- 从空缓冲通道收数据 → 阻塞，同上
- 用
close(ch)关闭带缓冲通道后，仍可读取剩余未取完的数据，但再写会 panic：send on closed channel - 在 select 中使用带缓冲通道时，如果多个 case 都就绪，仍按伪随机顺序选择，缓冲状态不影响公平性
最易被忽略的一点：缓冲通道的容量在创建后不可变，且 cap(ch) 返回的是初始容量，不是当前可用空间 —— 可用空间得用 cap(ch) - len(ch) 算出来。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
