<p>使用无缓冲 channel 实现队列时，若生产者与消费者未协同启动（如仅生产无消费，或消费先阻塞等待），所有 goroutine 会因 channel 操作阻塞而休眠，触发“all goroutines are asleep - deadlock”错误。</p>
用 chan 实现队列时，为什么一跑就报 fatal error: all goroutines are asleep - deadlock
这是最常踩的坑：裸用无缓冲 chan 且没配好生产者/消费者节奏。比如只启了生产者往 chan string 写，但没启消费者读，或消费者先启动却等不到数据，goroutine 全卡住，Go 运行时直接 panic。
- 必须确保至少一个 goroutine 在
range或等待读，另一个在 <code> 写（或用 <code>select防死等） - 别用无缓冲 channel 做“队列”——它本质是同步点，不是缓存；要用就选带缓冲的：
messages := make(chan string, 10) - 如果要支持“空队列时等待”，不能只靠
，得用 <code>select+time.After或配合sync.Cond手动管理状态
MessageQueue 结构体封装里，sync.Mutex 不是用来保护 chan 的
Go 的 channel 本身是并发安全的，sync.Mutex 在这里不是必需品。加它的真正目的是为后续扩展留钩子：比如加消息计数器、记录入队时间、统计积压量，或者将来把内存队列换成 Redis 后端时，统一加日志或重试逻辑。
- 当前仅用 channel 时，
Enqueue和Dequeue方法内部无需加锁 - 但如果结构体里加了
len字段来实时统计长度，那每次读写就得用mu.Lock()保护 - 错误做法：给 channel 加锁后还用
len(ch)判断是否满——这不可靠，因为len是瞬时快照，且对 buffered channel 才有意义
用 select 处理超时和非阻塞，比裸写 更健壮
真实场景中，你不能让生产者无限期卡在 messages 上，尤其当消费者处理慢、队列满时。用 <code>select 可明确控制行为边界。
- 非阻塞入队（丢弃策略）：
select { case messages <- "新消息": fmt.Println("入队成功") default: fmt.Println("队列已满，丢弃") } - 带超时入队（降级策略）：
select { case messages <- "新消息": fmt.Println("入队成功") case <-time.After(500 * time.Millisecond): fmt.Println("超时，放弃发送") } - 消费者侧同理：用
select包裹，避免单个 goroutine 挂死导致整条消费链停滞
什么时候该从内存 chan 切到 Redis 或 Kafka
纯内存队列适合开发验证、单机轻量任务（如日志聚合、内部通知）。一旦出现以下任一情况，就得换：
立即学习“go语言免费学习笔记（深入）”；
- 需要消息持久化（进程重启不丢数据）→ 必须上 Redis（
LPUSH/BRPOP）或 Kafka - 消费者数量动态伸缩，或跨机器部署 → 内存
chan无法共享，Redis 或 Kafka 提供中心化分发 - 要求精确一次（exactly-once）语义、死信队列、延时消息 → 内存方案几乎没法可靠实现
- 流量突发远超内存 buffer 容量（比如秒杀场景）→ Redis 的内存+磁盘混合模式或 Kafka 的分区机制更稳
别等到线上崩了才换——只要服务要长期运行、有外部依赖、或用户量破千，就该默认选 Redis 方案，哪怕只是本地 localhost:6379。
