beego/queue 是基于 channel 和 waitgroup 的内存级任务缓冲区，不支持自动重试、持久化、redis 后端或任务状态查询，仅适用于低延迟、非关键路径的内部异步操作。
Beego 自带的 beego/queue 包确实能快速搭起一个轻量队列，但它不是开箱即用的“任务队列引擎”——它更像一个带简单调度能力的内存通道封装。如果你期望它自动重试、持久化、支持 Redis 后端、或提供任务状态查询接口，会发现这些功能默认不存在。
beego/queue 的真实定位：内存级任务缓冲区
它本质是基于 chan + sync.WaitGroup 的 goroutine 池封装，不依赖外部存储，所有任务生命周期绑定于进程。适合场景非常明确：
- 内部通知类任务（如发邮件前触发审计日志写入）
- 低延迟、非关键路径的异步清理（如 session 过期后异步删缓存）
- 开发调试阶段模拟异步行为，避免阻塞 HTTP handler
它不处理以下问题：panic 后任务丢失、worker 崩溃无恢复、任务超时无感知、无法查询某 ID 任务是否完成。这些不是 bug，而是设计取舍。
如何正确初始化并控制并发水位
默认配置下，beego/queue 使用无缓冲 channel 和动态 worker 数量，极易导致 goroutine 泛滥或生产者阻塞。必须显式覆盖：
- 用
queue.New({Buffer: 100, Workers: 4})初始化，Buffer决定队列积压上限，Workers是固定数量的常驻 goroutine - 避免在
process函数里直接调用可能长时间阻塞的 I/O（如未设 timeout 的 HTTP 请求），否则整个 worker 会被卡住 - 若需失败重试，必须在
process内手动捕获 error 并调用queue.Push()回插，框架不自动重投
Redis 支持？别被文档误导
官方文档提到 “支持 Redis”，但实际源码中 beego/queue 的 Redis 实现仅存在于早期 v1.x 分支的实验性代码里，当前稳定版（v2.0+）已移除。你看到的 import 路径如 beego/queue/redis 在 go.mod 中根本无法 resolve。如果硬要加 Redis，得自己实现 queue.Queue 接口，并替换默认的内存实现——这不是配置开关，而是重写存储层。
什么时候该放弃 beego/queue，换 Beeclaw 或 bee-queue
只要出现以下任一信号，就该切换：
- 需要任务成功/失败状态可查（比如前端轮询导出进度）→
Beeclaw提供GetJob(id)和状态机 - 部署多实例且任务不能重复执行 →
bee-queue基于 Redis 的原子 pop 保证唯一消费 - 任务执行中可能被主动取消 →
Beeclaw显式暴露Cancel()方法，利用 context 取消底层 goroutine - 要求失败后按指数退避重试 →
bee-queue的maxRetryDelay配置直接生效，beego/queue得自己写计时器
beego/queue 的价值不在功能完整，而在「零依赖启动」。一旦业务越过那个临界点，强行扩展它只会让逻辑散落在各处，不如早切。
