channel是Go最轻量的消息队列实现，但仅适用于进程内异步学习；生产环境需MQ保障持久化、跨机分发与失败重试。
channel 是 Go 里最轻量、最直接的消息队列实现方式，但**它不是生产环境用的 MQ，而是学习异步模型的起点**。真正理解 goroutine + channel 的协作逻辑，比照搬 RabbitMQ 示例更有价值。
为什么用 chan Task 而不是 chan string？
消息本质是结构化数据，不是字符串拼接。硬塞 string 或 []byte 会导致序列化/反序列化混乱、类型丢失、无法携带元信息（如重试次数、超时时间）。
-
Task结构体明确封装了业务意图，比如：type Task struct { ID string Payload map[string]interface{} Timestamp time.Time Retry int } - 消费者能直接访问字段，不用反复
json.Unmarshal；生产者也能按需设置Retry控制重试行为 - 如果后续要加中间件（如日志、限流），结构体比原始字节更易扩展
make(chan Task, 100) 的缓冲区大小怎么定？
缓冲区不是并发数，是「瞬时积压容量」。设太大容易掩盖背压问题，太小又让生产者频繁阻塞。
- 先观察单次请求平均生成多少任务：比如一个订单创建触发 3 个下游动作（发邮件、扣库存、写日志），那峰值可能达 3×QPS
- 结合处理延迟估算积压：若 worker 平均耗时 200ms，每秒最多处理 5 条，那 100 容量 ≈ 支撑 20 秒突发流量
- 上线后用
len(taskCh)打点监控，持续高于 80% 就说明需要扩容或优化 worker 性能
worker panic 会导致整个队列“卡死”吗？
会。goroutine 崩溃后不会自动重启，for range taskCh 仍在运行，但没人消费新消息——表面正常，实际已半瘫痪。
- 必须在每个 worker 内部加
defer func() { if r := recover(); r != nil { log.Printf("worker panic: %v", r) } }() - panic 后建议补发任务到 dead letter channel，而不是丢弃
- 别依赖全局
recover，它捕获不到其他 goroutine 的 panic
什么时候该放弃 channel，换真实 MQ？
当出现以下任一情况时，channel 就该退场了：
立即学习“go语言免费学习笔记（深入）”；
- 进程重启后未处理完的任务丢失（
channel是内存态） - 需要跨机器分发任务（
channel不能跨进程） - 消费者处理失败后要求自动重试 + 延迟重投（
channel没有内置重试机制） - 多个服务共用同一类任务，但部署独立（
channel无法共享）
这时候再引入 RabbitMQ 或 Redis Streams，不是因为它们“高级”，而是因为 channel 的边界已经清晰可见——它只负责协程间通信，不负责可靠性、持久化和分布式协调。
