直接用 chan int 易卡死因无缓冲需同步收发：生产者发送时消费者未启动即阻塞，导致死锁；须用 make(chan int, N) 设缓冲、go 启动双端、生产者 close() 后消费者用 range 安全退出。
为什么直接用 chan int 做生产者消费者容易卡死
因为 Go 的 channel 默认是无缓冲的，send 和 recv 必须同步配对：没人接收时发送会阻塞，没人发送时接收也会阻塞。生产者一发就停，消费者还没启动，程序直接挂住。
常见错误现象：fatal error: all goroutines are asleep - deadlock
- 必须显式指定缓冲区大小，比如
make(chan int, 10)，让生产者能先存几条再等消费 - 消费者和生产者都得用
go启动，否则串行执行失去并发意义 - 如果生产者结束过早（比如循环完就退出），而消费者还在等，channel 关闭前的剩余数据可能被丢弃
如何安全关闭 channel 并通知消费者退出
不能靠「消费者从 closed channel 读到零值」来判断结束——因为 0 可能是合法数据。正确做法是用 close() + range 或 ok 检查，且只由生产者关闭（谁创建谁关闭）。
- 生产者循环结束后调用
close(ch) - 消费者用
for v := range ch自动退出，或用for { v, ok := - 切勿在多个 goroutine 中调用
close()，会 panic：panic: close of closed channel - 如果需要多消费者协作退出，可额外加一个
done chan struct{}作信号通道
带缓冲 channel 和无缓冲 channel 在生产者消费者中的实际差异
缓冲大小不是越大越好。它本质是内存换时间：大 buffer 减少阻塞，但增加内存占用和数据延迟；小 buffer 或无 buffer 能更快暴露背压问题，但要求消费者及时跟上。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
-
make(chan int)（无缓冲）：适合强实时场景，比如信号通知、步进同步，但生产者消费者速率稍不匹配就卡死 -
make(chan int, 1)：最简背压控制，生产者最多多产 1 个，适合任务队列中“拿一个干一个”的模型 -
make(chan int, 100)：常见于批处理，允许短暂积压，但若消费者长期慢于生产者，buffer 会满，发送再次阻塞 - 注意：buffer 大小不影响 channel 类型，
cap(ch)只对带缓冲 channel 有定义，无缓冲的返回 0
一个可运行的最小完整示例（含错误处理和退出信号）
下面代码启动 2 个生产者、3 个消费者，用带缓冲 channel 传递数字，并通过 sync.WaitGroup 确保主 goroutine 等待全部完成：
func main() {
ch := make(chan int, 5)
var wg sync.WaitGroup
<pre class="brush:php;toolbar:false;">// 启动消费者
for i := 0; i < 3; i++ {
wg.Add(1)
go func(id int) {
defer wg.Done()
for v := range ch {
fmt.Printf("consumer %d got %d\n", id, v)
time.Sleep(100 * time.Millisecond) // 模拟处理耗时
}
}(i)
}
// 启动生产者
for i := 0; i < 2; i++ {
wg.Add(1)
go func(id int) {
defer wg.Done()
for j := 0; j < 4; j++ {
ch <- id*10 + j
fmt.Printf("producer %d sent %d\n", id, id*10+j)
time.Sleep(50 * time.Millisecond)
}
}(i)
}
// 所有生产者结束后关闭 channel
go func() {
wg.Wait()
close(ch)
}()
// 等待所有 goroutine（包括关闭协程）结束
wg.Wait()}
关键点：关闭操作本身也得用 goroutine 异步触发，否则会卡在 wg.Wait()；消费者用 range 自动响应关闭；time.Sleep 是为了看清执行顺序，真实场景应替换为实际业务逻辑。
最容易被忽略的是：关闭 channel 的时机必须严格在所有生产者退出之后，且只能发生一次。漏关会导致消费者永远等待，多关会 panic——这两类错误在线上环境往往表现为偶发 hang 或崩溃，排查成本远高于写的时候多加两行检查。
