缓冲大小为0和1的行为本质不同：0是严格同步，发送必须等待接收就绪；1是单槽暂存，允许一次非阻塞发送，但不解决持续背压，仅缓解瞬时延迟。
channel 缓冲大小设为 0 和 1 的行为差异
零缓冲 channel（make(chan int)）是同步的，每次 send 都必须有对应的 recv 在等待，否则发送方阻塞；而缓冲为 1 的 channel（make(chan int, 1)）允许一次“暂存”，发送方在缓冲未满时可立即返回。这不是性能优化，而是控制**耦合时机**：缓冲为 0 强制生产者和消费者严格交替；缓冲为 1 允许生产者多推一个任务，避免因消费者短暂延迟导致整个流水线停顿。
常见错误是以为 make(chan T, 1) 能“缓解压力”，其实它只撑住**一个额外任务**。一旦消费者卡住，第二个 send 仍会阻塞——它不是队列，只是单槽暂存器。
- 测试时用
len(ch)查看当前缓冲中元素数，cap(ch)查看容量，二者在缓冲 channel 中才有意义 - 不要对零缓冲 channel 做
select+default试图“非阻塞发送”，那只是掩盖了同步契约被破坏的问题 - 若需真正异步积压，缓冲大小必须大于 1，且要配合超时或丢弃逻辑，否则只是把阻塞点后移
如何安全地动态调整 channel 缓冲策略
Go 的 channel 缓冲大小在创建后不可更改，所谓“动态调整”只能通过重建 channel + 迁移数据实现，代价高、易出错，一般不推荐。真实场景中更可行的做法是：启动时根据负载特征预估缓冲容量，并用配置项驱动初始化。
例如，若消费者处理耗时稳定在 100ms，生产者峰值速率为 50 QPS，则理论积压上限为 5 个任务（0.1s × 50），此时 make(chan Job, 8) 比 make(chan Job, 1) 更稳妥——留 3 个余量防抖动。
- 避免用
make(chan T, math.MaxInt)或大常量（如 10000）假装“无限缓冲”，内存占用不可控，且无法反映真实背压 - 若业务要求“过载丢弃”，应在生产者侧做判断：
select { case ch - 迁移旧 channel 数据时，必须确保无 goroutine 正在读/写原 channel，否则竞态；建议用
close()+ 循环recv清空，再新建
使用 buffered channel 时容易被忽略的关闭陷阱
关闭一个带缓冲的 channel 后，已入缓存但未被读取的元素仍可被接收，但不能再发送。这导致两个典型问题：一是消费者误以为关闭 = 所有任务已处理完，实际还有残留；二是关闭后继续向缓冲 channel 发送会 panic：panic: send on closed channel。
正确做法是：由生产者负责关闭，且必须在所有 send 完成后关闭；消费者应持续 recv 直到 ok == false，而非依赖计数。
- 不要用
len(ch) == 0 && closed判断是否结束——len()是快照值，不可靠 - 若需精确控制任务总数，改用
sync.WaitGroup或额外信号 channel，而不是依赖缓冲 channel 的长度 - 关闭前确保所有生产 goroutine 已退出，否则存在 race：一个 goroutine 关闭，另一个还在 send
为什么不要用 channel 缓冲替代真正的任务队列
channel 缓冲本质是内存中的固定大小 FIFO，没有持久化、无重试、无优先级、无监控指标。当消费者崩溃或网络分区时，缓冲里的任务直接丢失；当生产速率长期高于消费速率，缓冲满后所有生产者阻塞，系统僵死。
如果你需要：任务不丢、失败可重试、支持扩缩容、能查积压量——那就该用 Redis List + worker pool，或 Kafka + consumer group，而不是加大 make(chan T, N) 的 N。
channel 缓冲只适合：进程内、短时、低延迟、可控规模的协作，比如 parser → validator → serializer 这类纯内存流水线。
