这是因channel使用不当导致的死锁：无缓冲channel需收发双方同时就绪，仅生产者写入或仅消费者读取均会阻塞；带缓冲channel才可暂存消息，且需注意关闭时机。
为什么一跑就报 fatal error: all goroutines are asleep - deadlock
这是裸用 chan 做队列时最典型的错误：goroutine 全卡在 channel 操作上，没人读、没人写，或者节奏没对齐。无缓冲 channel 是同步点，不是队列；带缓冲的才可能“存住”消息。
- 只启动生产者往
messages写，但没启消费者读 → 生产者阻塞，程序 panic - 消费者先启动，
for range messages等数据，但生产者还没开始或已结束且未close(messages)→ 消费者永远等下去 - 用
make(chan string)（无缓冲）却想当队列用 → 每次都要等对面 <code>，根本攒不了消息
解决办法很简单：用带缓冲的 make(chan string, N)，且确保至少一个 goroutine 在读、一个在写，或用 select 加兜底逻辑。
怎么选缓冲大小：10 还是 1000？
缓冲大小不是越大越好，它本质是在「内存占用」和「背压暴露」之间做权衡。
-
make(chan string, 10)：适合调试、内部通知类场景；满时立刻暴露消费者处理慢的问题 -
make(chan string, 1000)：看似抗压，实则掩盖瓶颈；若消费者持续落后，内存会涨，且无法感知积压恶化 - 真实服务中，建议从 10–100 起步，配合监控看
len(messages)（仅对 buffered channel 有效），再动态调整
别用 len(ch) 判断是否能写——它只是瞬时快照，且并发下不可靠。要用 select + default 或超时来控制行为边界。
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
如何安全地发送和接收：别裸写
裸写 messages 或 <code>msg := 在生产环境等于埋雷。必须用 <code>select 控制阻塞行为。
- 发送端加超时（防消费者宕机）：
select { case messages <- "msg": fmt.Println("ok") case <-time.After(300 * time.Millisecond): fmt.Println("drop") } - 接收端加
default（防空队列死等）：select { case msg := <-messages: handle(msg) default: fmt.Println("no msg now") } - 关闭 channel 后不能再 send，否则 panic；但可以 continue receive 直到所有已入队消息被取完
记住：close() 是通知“不再有新消息”，不是“立刻停收”。消费者必须用 for range 或循环 + ok 判断来安全退出。
要不要封装成结构体？什么时候加 sync.Mutex？
直接裸用 chan 很快会遇到扩展瓶颈：没法统计长度、没法优雅关闭、没法加日志或重试。封装成结构体是必要一步。
- 把
chan当私有字段藏起来，暴露Send()和Receive()方法，统一处理满/空/关闭逻辑 -
sync.Mutex不是用来保护chan的——channel 本身并发安全；它是为将来留钩子：比如加count int字段统计积压量，这时每次读写都得加锁 - 如果结构体里只有
messages chan Message，那Send和Receive方法里完全不用锁
真正容易被忽略的是：内存 channel 天然不持久、不跨进程、不支持重试和死信。一旦需要这些，就得切到 Redis 或 Kafka——不是优化，而是换范式。
