不会 panic，但会阻塞；当缓冲区已满且无接收者时，发送操作将阻塞，直到有 goroutine 接收数据腾出空间。
channel 缓冲区满了会阻塞还是 panic？
不会 panic，但会阻塞——这是最常被误读的一点。只要 make(chan int, 5) 指定了缓冲容量，往里发数据时，只有当缓冲区已满（len == cap）且没有 goroutine 在另一端接收，ch 就会挂起当前 goroutine，直到有空间或被关闭。
常见错误现象：fatal error: all goroutines are asleep - deadlock，本质就是所有 sender 都卡在满缓冲 channel 上，又没人接收。
- 只在明确知道生产/消费节奏可控时才用带缓冲 channel；盲目加大
cap只是把问题延后 - 如果消费者处理慢、生产快，缓冲区只是“临时水池”，溢出风险没消失，只是延迟暴露
- 调试时可用
len(ch)和cap(ch)实时观察填充率，但别在热路径频繁调用（有锁开销）
如何安全地向带缓冲 channel 发送而不阻塞？
用 select + default 实现非阻塞发送，这是唯一标准做法。别试图用 len(ch) 判断——它不原子，判断完可能立刻被其他 goroutine 填满。
使用场景：日志上报、指标采集等允许丢弃的异步写入。
立即学习“go语言免费学习笔记（深入）”；
select {
case ch <- v:
// 成功写入
default:
// 缓冲区满，跳过或降级处理（如打 warn 日志）
}-
default分支必须存在，否则 select 等同于阻塞 send - 不要在
default里重试或 sleep，这容易掩盖背压问题 - 若业务不能丢数据，就该换方案：比如用带限流的 worker pool，而不是靠增大 buffer 硬扛
缓冲大小设成 1、64 还是 1024？性能差异在哪？
缓冲大小对性能影响远小于「是否匹配实际并发模型」。小缓冲（如 1）接近无缓冲语义，适合强同步场景；大缓冲（如 1024）能平滑突发流量，但内存占用和 GC 压力会上升，且延迟不可控。
参数差异的关键点：
-
make(chan T, 0)：完全同步，sender 和 receiver 必须同时就绪 -
make(chan T, 1)：允许一个“等待中的”值，适合信号通知类场景（如 done channel） -
make(chan T, N)：N 越大，channel 内部 ring buffer 占用内存越多，GC 扫描成本略增 - 实测中，从 64 到 1024，吞吐提升往往不到 5%，但 OOM 风险显著上升
关闭已满的带缓冲 channel 会发生什么？
可以正常关闭，已存入缓冲区的数据仍可被接收，但之后再 send 会 panic：panic: send on closed channel。接收方不会感知“满”这个状态，只看 channel 是否 closed + 缓冲是否为空。
容易踩的坑：
- 关闭前没确认所有 sender 已退出，导致部分 goroutine 还在往 closed channel 发数据
- 误以为
close(ch)会清空缓冲区——它不会，len(ch)仍返回原值，直到被 receiver 取完 - 在多 sender 场景下，用 close 标记“结束”必须配合 sync.Once 或显式计数，不能靠缓冲区满来触发
复杂点在于：缓冲区本身不参与 backpressure 传播，它只是个中间暂存。真正决定系统是否健康的是 sender/receiver 的速率差，以及你有没有在满时做正确决策——丢、等、退、限流。这点很容易被忽略。
