无缓冲channel一用就死锁，因为其本质是同步通信：发送操作必须与接收操作同时就绪，若在单个Goroutine中先后执行发送和接收，发送会永久阻塞等待不存在的接收者，导致所有Goroutine休眠而触发死锁。
无缓冲 channel 为什么一用就死锁？
因为无缓冲 channel 是同步通信：ch 必须等到有 goroutine 在另一端执行 <code> 才能继续，反之亦然。如果 sender 和 receiver 没有“同时就位”，就会互相等待，触发 runtime panic: <code>fatal error: all goroutines are asleep - deadlock!。
- 常见错误：main goroutine 启动一个 goroutine 发送数据，但自己没写接收逻辑，或接收写在发送之后
- 正确做法：要么用 goroutine 包裹接收端（如
go func() { ），要么确保 main 中先启动接收再启动发送 - 调试技巧：加
fmt.Println("before send")和fmt.Println("after send")，如果后者不打印，基本就是卡在发送上了
带缓冲 channel 的容量设多少才合适？
缓冲大小不是越大越好，它本质是内存 + 行为语义的权衡：设为 0（等价于无缓冲）强调严格同步；设为 N 允许最多 N 次“非阻塞发送”，但接收端一旦滞后，数据就会堆积在内存里。
- 典型场景：
make(chan Task, 10)适合生产者快、消费者慢但可容忍短暂积压的任务队列 - 反例：设成
10000又不及时消费，可能引发 OOM 或掩盖背压问题 - 经验法则：从
1或cap = 生产者并发数 × 平均每轮产出数起步，上线后根据len(ch)监控值调优
关闭 channel 前必须确认哪些条件？
关闭 channel 是单向、不可逆操作，只应由“数据发送方”在确认**不会再有新数据发出**时调用 close(ch)。误关或重复关闭都会 panic。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 禁止对 nil channel 调用
close（panic: close of nil channel） - 禁止对已关闭 channel 再次
close（panic: close of closed channel） - 接收端不能靠
close判断“所有数据收完”——必须配合for range ch或v, ok := 检查 <code>ok == false - 多个生产者时，不能由任意一个 producer 关闭 channel；需用
sync.WaitGroup等待全部 producer 结束后，由主 goroutine 统一关闭
如何安全地从多个 channel 中取数据？
直接写 或 <code> 是阻塞且单点的，真正需要的是“谁就绪读谁”，这时必须用 <code>select。
立即学习“go语言免费学习笔记（深入）”；
-
select会随机选择一个就绪的 case 执行，没有优先级；若多个就绪，结果不确定 - 加
default可实现非阻塞尝试，但要注意它会立即执行，不等任何 channel 就绪 - 超时控制必须配
time.After，例如：case - 切忌在
select外层套无限 for 循环却不 break —— 容易忽略 channel 已关闭，导致空转消耗 CPU
channel 不是队列 API，也不是线程安全的共享变量替代品；它的核心价值在于通过阻塞行为强制你显式建模“协作时序”。哪怕只是临时传一个 int，也要想清楚：谁发、谁收、谁关、超时怎么处理——漏掉任一环，程序就停在那儿了。
