无缓冲 channel 一发就卡住是设计使然；需根据是否需要强制双方步调一致来选择有/无缓冲，而非是否阻塞。
选无缓冲还是有缓冲，不看“要不要阻塞”，而要看你是否需要强制双方步调一致。如果漏掉这个判断依据，后面所有配置、调试、压测都可能白忙。
无缓冲 channel 一发就卡住，是设计使然，不是 bug
执行 ch := make(chan int) 后，ch 立即阻塞，直到有 goroutine 同时执行 <code>。这不是延迟，是 runtime 层面的 rendezvous（会合）机制。
- 常见死锁现象：
fatal error: all goroutines are asleep - deadlock!，尤其出现在主 goroutine 先发后收、或只发不收时 - 典型适用场景：启动同步（子 goroutine 初始化完再通知主 goroutine）、done 信号（
done := make(chan struct{})）、暂停/恢复控制流 - 它不占额外内存，但对执行顺序极度敏感——别指望它存数据，它根本没地方存
有缓冲 channel 的阻塞点只在满/空两个边界
执行 ch := make(chan int, 3) 后，前 3 次 ch 都立刻返回；第 4 次才阻塞，直到有人执行 <code> 腾出空间。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 缓冲区是固定大小的环形队列，创建后不可扩容；设为 0 等价于无缓冲，负数会 panic
- 容易误判：以为
cap(ch) == 1就“最多收一次”，其实它允许你连续发 1 次不阻塞，但第 2 次才卡——而接收端哪怕还没动，第一次发送也已完成 - 性能影响：小缓冲（1–16）可平滑突发流量；过大（如 10000）会掩盖背压，让生产者狂写、消费者永远追不上，最终 OOM
关闭 channel 时，缓冲区残留数据必须被显式消费
关闭一个有缓冲的 channel 后， 仍能读出缓冲中剩余数据；读完才返回零值和 <code>false。但这些数据不会自动 GC——底层 hchan 结构仍持有引用。
- 反模式：用
for range ch消费，但接收逻辑提前 return 或 panic，导致缓冲未清空就退出 - 正确做法：确保接收端逻辑覆盖“通道关闭 + 缓冲未清空”情况；不要依赖超时跳过，也不要忽略剩余值
- 关闭权必须唯一：仅由**最后一个生产者**调用
close(ch)；多个 goroutine 同时写且争抢 close，极易引发panic: close of closed channel
缓冲大小不是配置项，是并发契约的一部分——它隐式定义了“最多允许多少工作积压”。设成 100 不代表更稳，只是把 OOM 延后了；得结合平均处理耗时、峰值 QPS 和内存预算反推。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
