无缓冲 channel 必须发送和接收同时就绪；死锁主因是对 make(chan int) 的误解——它不存数据，仅用于同步，任一方先操作（如只 send 不 recv）即死锁。
无缓冲 channel 必须「发送和接收同时就绪」
死锁最常见原因就是对 make(chan int) 的误解：它不存数据，只做同步。只要有一方先动（比如 c ），而另一方还没走到 <code>，当前 goroutine 就会永远卡住。
- 错误写法：
ch := make(chan int); ch —— 主 goroutine 自己发、自己没接，直接死锁 - 正确写法：必须配对，要么用 goroutine 发 + 主 goroutine 接，要么反过来
- 注意：哪怕你写了
go func() { ch ，如果主 goroutine 紧接着就退出（没等 goroutine 执行完），也可能收不到，这不是死锁，但结果不可靠
range 遍历未关闭的 channel 会永久阻塞
写 for v := range ch 时，Go 会一直等新数据，直到 close(ch) 被调用。没关 channel，循环就永远不会结束。
- 典型场景：生产者 goroutine 发完数据后忘记
close(ch)，消费者卡在range里不动 - 修复方式：生产者完成任务后显式调用
close(ch)；消费者无需额外判断，range自动退出 - 别用
len(ch) == 0判断是否“空了”——这是错的，len只反映缓冲区当前长度，和是否还有后续数据无关
多个 goroutine 相互等待形成环路
比如两个 goroutine 分别向对方的 channel 发数据，但都等着对方先接收——谁也不动，全卡住。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 经典陷阱：
sum(nums, c1)和sum(nums, c2)在 main 中**同步调用**（没加go），导致第一个c1 就阻塞，第二个根本执行不到 - 解决办法之一：加
go启动并发，让发送和接收能交错进行 - 解决办法之二：改用带缓冲的 channel，如
make(chan int, 1)，允许一次“暂存”，打破同步依赖
主 goroutine 等待自己无法触发的操作
看似合理，实则危险：比如在 main 里启动一个 goroutine 往 ch 写，然后自己立刻 —— 如果 goroutine 还没调度到、或写操作被其他逻辑延后，main 就卡死了。
立即学习“go语言免费学习笔记（深入）”；
- 调试技巧：加
fmt.Println或用runtime.Stack()查看 goroutine 状态，确认谁在等谁 - 更健壮的做法：配合
sync.WaitGroup控制生命周期，或用select+default避免无限等待 - 切记：Go 不保证 goroutine 启动后立即执行，也不保证 channel 操作的时序——所有依赖“先发后收”的逻辑，都得显式协调
最容易被忽略的点是：死锁往往不是因为用了 channel，而是因为**没理解它本质是同步原语，不是消息队列**。一旦把无缓冲 channel 当成“可随时发、稍后收”的管道，就踩进坑里了。
