缓冲通道容量非零不等于不阻塞：缓存满时发送仍阻塞；无缓冲通道要求收发同步；死锁常因满缓冲无接收者；缓冲大小应匹配生产消费节奏而非盲目增大；select+default仅瞬时探测，不可靠；range遍历未关闭通道会永久阻塞；关闭责任在最后发送方，向已关闭通道发送会panic。
channel 创建时指定缓冲区大小，不等于“不阻塞”
缓冲容量为 0 的 chan int 是无缓冲 channel，发送和接收必须同步配对，任一方未就绪就会立即阻塞。缓冲容量为 n 的 channel，最多可缓存 n 个值；但一旦缓存满，send 操作仍会阻塞，直到有 goroutine 执行 receive。
常见错误现象：fatal error: all goroutines are asleep - deadlock，往往是因为往已满的缓冲 channel 发送，且没有其他 goroutine 在读 —— 这和无缓冲 channel 的死锁表现一样，只是触发时机晚一点。
- 判断是否该用缓冲：不是“怕阻塞”就加缓冲，而是看是否需要解耦发送/接收节奏（比如生产者快、消费者慢，且允许短暂积压）
- 缓冲大小不是越大越好：
make(chan int, 1000)看似安全，但若消费者长期卡住，内存会持续增长，且掩盖了背压缺失的问题 - 无缓冲 channel 是同步信号的理想载体（如等待初始化完成），缓冲 channel 更适合数据流暂存
select + default 无法可靠检测 channel 是否“可发送”
select 中带 default 分支看似能非阻塞尝试发送，但实际只反映「此刻」是否能成功：如果 channel 缓冲未满或有接收方在等，就走 send；否则立刻走 default。它不保证后续操作的安全性，也不等于 channel “空闲”或“健康”。
使用场景受限：适合做尽力而为的投递（如日志上报，丢了也不致命），不适合控制关键流程（如任务分发必须确保送达）。
立即学习“go语言免费学习笔记（深入）”；
-
default不是超时，也不是轮询机制，它不引入任何等待，纯属即时快照 - 无法区分“缓冲已满”和“接收方 goroutine 被调度延迟”，两者都会导致走
default - 若真需要探测状态，应由 sender 主动管理背压（如用额外的
donechannel 或计数器），而非依赖select的瞬时行为
range 遍历关闭的 channel 会自动退出，但未关闭的 channel 会永久阻塞
for v := range ch 的行为完全取决于 channel 是否被关闭。一旦 close(ch)，循环会在读完剩余缓冲数据后自然结束；如果没人关，且后续再无发送，这个 for 就永远卡在 recv 上 —— 即使缓冲已空。
典型坑：goroutine 启动一个 range 消费 channel，但忘记在所有生产者退出后调用 close，结果 goroutine 泄漏。
- 关闭 channel 的责任通常在**最后的发送方**，不是接收方；多个 sender 时需用 sync.WaitGroup 或其他协调机制确保只 close 一次
- 向已关闭的 channel 发送会 panic：
panic: send on closed channel，所以 sender 必须自己掌握生命周期 - 接收方可用
v, ok := 判断是否关闭，但 <code>range内部已做了这事，无需额外检查
buffered channel 的 len 和 cap 不代表“使用率”或“压力指标”
len(ch) 返回当前缓冲中元素个数，cap(ch) 返回创建时指定的缓冲容量。它们只是快照值，读取瞬间之后就可能变化；而且它们不反映阻塞风险 —— 一个 len=0 的 channel，只要没 receiver，下一次 send 仍可能阻塞（无缓冲）或成功（有缓冲）。
性能影响：频繁调用 len / cap 没有意义，它们不提供调度提示，也不参与 runtime 的阻塞决策。
- 不要用
len(ch) == cap(ch)当作“队列满”的告警依据，因为这条件可能只存在纳秒级，且无法原子地触发响应动作 - 真正需要监控背压时，应结合 context 超时、receiver 处理耗时统计、或外部信号（如 prometheus counter）
- channel 的内部状态对用户不可见，runtime 只保证通信语义，不暴露队列实现细节
channel 的阻塞不是 bug，是 Go 并发模型的基石设计。想绕过它，往往意味着你该换结构 —— 比如用 worker pool 控制并发数，而不是靠增大缓冲来吞掉压力。
