Go消息队列选型应按需分层：单进程用带缓冲channel（如jobs := make(chan string, 100)），本地跨进程用Redis（RPush/BLPop+JSON序列化），生产级才上RabbitMQ（需确认服务、端口、权限），轻量离线场景可选go-queue文件队列。
Go 环境下配消息队列，不一定要装 RabbitMQ 或 Kafka 才算“配好”——很多场景下，用原生 channel 或本地 Redis 就够了，强行上重型中间件反而拖慢开发节奏、掩盖设计问题。
用 channel 快速验证逻辑，零依赖起步
说明：适合单进程内解耦（如日志异步刷盘、事件通知）、单元测试、原型验证。它不是“真 MQ”，但能跑通生产/消费模型，帮你聚焦业务逻辑而非运维配置。
- 常见错误现象：
fatal error: all goroutines are asleep - deadlock，通常是因为没开 goroutine 消费，或缓冲区满后生产者阻塞且无超时控制 - 使用场景：Web 请求返回后触发轻量后台任务（如发邮件通知、更新缓存）
- 实操建议：
- 声明带缓冲的
chan，比如jobs := make(chan string, 100)，避免主流程卡死 - 消费者必须用
go func() { ... }()启动，否则会同步阻塞 - 加
context.WithTimeout控制消费超时，防止 goroutine 泄漏
- 声明带缓冲的
jobs := make(chan string, 100)
go func() {
for job := range jobs {
fmt.Println("处理:", job)
}
}()
jobs <- "send_email:user123"
本地连 Redis 实现持久化队列
说明：比 channel 多一层可靠性，重启不丢消息，跨进程可用，且无需额外部署复杂服务（redis-server 一行命令就能起）。
- 参数差异：
RPush入队，BLPop阻塞出队；注意BLPop第二个参数是超时秒数（设为0表示无限等待，慎用） - 容易踩的坑：
- 没序列化直接塞 struct →
redis: nil错误，务必用json.Marshal - 消费者没做 ACK 机制，崩溃导致消息丢失 → 建议先
RPop取出，处理成功再DEL或用LPush到 done 队列 - 本地 Redis 默认绑定
127.0.0.1，Docker 运行 Go 程序时需改用host.docker.internal
- 没序列化直接塞 struct →
对接 RabbitMQ 前必须确认的三件事
说明：不是“装完就能用”。很多 amqp.Dial 失败、QueueDeclare 报错，都源于基础连通性或权限没理清。
立即学习“go语言免费学习笔记（深入）”；
- 必须检查：
- 性能影响：开启
durable: true会写磁盘，吞吐下降 30%~50%，但宕机不丢消息；开发阶段可先设false加快迭代。
go-queue 这类轻量库值得上吗？
说明：它用文件系统存消息，不依赖任何服务，适合离线环境或嵌入式场景。但要注意它不是通用替代品。
- 适用边界很明确：
- 消息量不大（单文件不宜超 10MB），且不需要高并发随机读取
- 你愿意接受“文件锁 + JSON 序列化”带来的 IO 开销，而不是用 mmap 或 WAL
- 团队不想维护 Redis/RabbitMQ，又不愿手写 channel 管理逻辑
- 容易被忽略的点：它的
RetryDelay是指数退避，但默认不持久化失败记录 —— 若程序崩溃，重试状态就丢了。需要自己 wrap 一层落盘逻辑。
真正的难点不在“怎么连上”，而在于选型时是否看清了消息语义需求：要不要持久化？要不要顺序？要不要跨机器？要不要死信？把这些问题列出来，方案自然就浮现了。
