无缓冲channel不能用作队列，因其本质是同步点，要求发送与接收必须同时就绪；若在main中单侧发送而无并发接收，将立即死锁。
用 chan 实现高并发队列时，死锁几乎总是源于“发送无人收”或“接收无人发”，而不是并发本身。关键不是加锁，而是让 channel 的生命周期和 goroutine 的行为严格对齐。
无缓冲 channel 直接用于队列必然死锁
无缓冲 chan int 本质是同步点，不是队列。它要求发送和接收**同时就绪**，否则任一方都会永久阻塞。
- 在
main中写ch 后不启 goroutine 接收 → 立即触发fatal error: all goroutines are asleep - deadlock! - 用
for range ch遍历但忘了close(ch)→ 接收方永远等下去，主 goroutine 却已退出 - 多个生产者往同一无缓冲 channel 发，但只有一个消费者且处理慢 → 后续发送全部卡住，goroutine 泄漏
带缓冲 channel 是队列的起点，但不是终点
make(chan int, N) 能暂存 N 个值，缓解瞬时压力，但缓冲区满后仍会阻塞发送 —— 这和“队列满该丢弃还是该限流”强相关，不能靠缓冲自己解决。
- 缓冲大小设为 0 等价于无缓冲；设为 1 只能扛一次突发，不等于“安全”
- 若消费者 panic 退出，channel 未被关闭，生产者最终会在第
N+1次发送时阻塞 - 没有超时机制的
ch 在高并发下可能让大量 goroutine 挂起，拖垮内存
真正安全的并发队列必须带退出信号与背压控制
仅靠 chan 无法表达“队列已满”“消费者已退出”“上游应暂停”这些语义。必须组合 select、context 和明确的关闭逻辑。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 用
select包裹发送：select { case ch - 消费者完成工作后主动
close(ch)，且只由发送方（或统一协调者）关闭 —— 遵守“谁创建，谁关闭”原则 - 若需多消费者，用
for range ch，但确保所有生产者都退出后再关闭；或改用sync.WaitGroup等待全部生产者结束
用 sync.Mutex + slice 实现可控队列反而更清晰
当业务需要精确控制入队策略（如丢弃、重试、优先级）、或 channel 语义太重时，带锁的 slice 队列反而更易推理、调试和测试。
- 避免在
Lock()内做耗时操作（如 HTTP 请求），否则阻塞其他 goroutine - 不要在持有
mu.Lock()时调用可能再次加锁的函数（比如另一个封装了锁的方法） - 用
defer mu.Unlock()是基础，但注意：若中间panic且未recover，锁不会释放 —— 更稳妥的是把临界区逻辑拆到独立函数中
最常被忽略的一点：死锁往往不是发生在“代码写错”的瞬间，而是发生在“假设对方会按预期行动”的地方 —— 比如默认消费者一定存活、默认 channel 一定被关闭、默认 context 一定不会 cancel。真正的并发安全，始于对每一个等待动作都设防。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
