用 make(chan T, N) 是标准做法，因 Go 原生无有界阻塞队列，而带缓冲的 chan 就是线程安全的有界阻塞队列；无缓冲 chan 是同步点，无暂存能力，易导致死锁。
用 make(chan T, N) 就是标准做法
Go 原生不提供「有界阻塞队列」类型，但 chan 本身在有缓冲时就是天然的、线程安全的有界阻塞队列。容量为 N 的缓冲通道，写入第 N+1 个值时会阻塞，直到有人读；读空时也会阻塞，直到有新值写入。不需要额外封装、锁或第三方库。
为什么不能直接用 chan T（无缓冲）？
无缓冲 channel 是同步点，每次 send 都必须配一个正在等待的 receive，完全不具备「暂存」能力——它不是队列，是握手信号。常见误用是想靠它做“缓冲”，结果协程卡死或 panic。
- 错误现象：
fatal error: all goroutines are asleep - deadlock - 典型场景：生产者发太快、消费者处理慢，又没缓冲，一写就卡住
- 参数差异：
make(chan int)容量为 0；make(chan int, 10)才真正能存 10 个待处理项
len(ch) 和 cap(ch) 怎么看当前状态？
len(ch) 返回当前已缓存元素个数（非阻塞读取），cap(ch) 返回缓冲区总容量。这两个值都是快照，不能用于条件判断是否可写/可读——因为并发下瞬间就变。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 错误写法：
if len(ch) → 竞态风险，可能写失败并 panic - 正确做法：直接
ch ，让 channel 自己阻塞或成功；或用 <code>select+default做非阻塞尝试 - 性能影响：频繁调用
len/cap无开销，但依赖它们做逻辑分支反而引入 bug
什么时候该考虑封装成结构体？
只在需要额外语义时才封装，比如要支持关闭后仍允许读完剩余项、带超时写入、统计入队/出队数、或统一错误处理。单纯「固定容量 + 阻塞」，裸 channel 更轻量、更符合 Go 惯例。
立即学习“go语言免费学习笔记（深入）”；
- 容易踩的坑：自己加 mutex 包一层
[]T+sync.Cond，结果比chan更慢、更容易死锁 - 兼容性注意：所有 Go 版本都支持缓冲 channel，无版本陷阱
- 示例：启动 3 个 worker 从
jobs := make(chan int, 100)拿任务，生产者往里塞，自然限流
缓冲 channel 的边界行为很确定：满则阻塞写，空则阻塞读。复杂点在于你是否真需要绕过这个行为——比如想丢弃旧任务、或改用非阻塞策略。这时候才该动封装念头，而不是一上来就造轮子。
