beego 本身不内置 workerpool，但可在 main() 中启动轻量协程池并注入全局或依赖容器，避免 init() 或请求中创建；任务需快照上下文数据（如 userid、orm 实例），禁用 stopwait() 改用 context 超时控制，并手动 recover panic、传入独立 logger。
Beego 本身不内置 WorkerPool，但它的高并发底座（goroutine + channel）完全兼容自建协程池；直接在 Beego 的 Controller 或 Service 层集成一个轻量 workerpool 是可行且推荐的，前提是避开框架生命周期管理冲突。
Beego 中启动 WorkerPool 的时机和位置
不能在 init() 或全局变量初始化时就 NewWorkerPool()，因为 Beego 的模块加载顺序不确定，且热重载（如 bee run）会多次执行 init；也不能在每个 HTTP 请求里新建池——那等于没池化。
- 最佳位置是
main.go的main()函数中，在beego.Run()之前启动，并将池实例挂到全局变量或 Beego 的 App 配置里（如beego.AppConfig.Set("worker_pool", wp)） - 若用 Beego v2+（基于模块化设计），更推荐封装为一个
Service，在app.Register()时注入，由依赖容器统一管理生命周期 - 切忌在
Controller的Prepare()或Get()中调用wp.Submit()后立即wp.StopWait()——这会阻塞整个 HTTP handler，失去并发意义
任务函数如何安全访问 Beego 上下文（如 orm、cache、config）
协程池里的 worker 是长期运行的 goroutine，它们没有 Beego 的请求上下文（context.Context 或 controllers.Controller 实例），所以不能直接调用 this.Ctx.Input.IP() 或 this.Data["xsrf_token"] 这类绑定到单次请求的对象。
- 必须把所需数据“快照”后传入任务：比如提取
userID := this.GetString("uid")，再构造Task{UserID: userID, Payload: data} - 数据库操作要显式传入已开启的
orm.Ormer实例（注意不是全局orm.NewOrm()，而是每次请求内o := orm.NewOrm()后传进去），否则可能复用被关闭的连接 - 缓存操作建议用
cache.NewCache("memory", `{"interval":60}`)这类无状态实例，避免依赖 Beego 的beego.BeeApp.Cache（它在热重载时可能被替换）
为什么 gammazero/workerpool 在 Beego 里要慎用 StopWait
gammazero/workerpool 的 StopWait() 会阻塞调用方直到所有已提交任务结束，但它**不支持超时**，也没有 context 取消机制。在 Beego 的 HTTP 场景下，这意味着一个慢任务可能拖垮整个请求超时逻辑（比如你设了 5s 超时，但 StopWait() 卡了 8s）。
- 替代方案是自己实现带 context 的等待：
wp.Submit(func(){ ... })后，用sync.WaitGroup+time.AfterFunc或select等待，超时则记录告警但不阻塞返回 - 更稳妥的做法是彻底放弃同步等待：提交任务后立即返回响应（如
{"status":"accepted","task_id":"xxx"}），另起一个轻量监控 goroutine 异步查结果 - 该包的
Submit()是非阻塞的，但底层 channel 无缓冲时会 panic；务必确认初始化时用了带缓冲的workerpool.New(4, workerpool.Options{QueueSize: 100})
Beego 日志与 panic 捕获怎么透传到 WorkerPool 任务中
Beego 默认日志（beego.Info()）依赖当前 goroutine 的 beego.BeeApp.Log 实例，而 worker goroutine 并不自动继承；同样，worker 内部 panic 不会触发 Beego 的 RecoverPanic 中间件。
- 不要在任务函数里直接调用
beego.Error()；改用传入的 logger 实例，例如初始化池时传入log := beego.GetLogger()，再封装进 task 结构体 - 每个 worker 内部需手动加
defer func(){ if r := recover(); r != nil { log.Error("worker panic:", r) } }()，否则 panic 会静默终止 worker，池子逐渐“残废” - Beego 的
RecoverPanic = true只对 HTTP handler 生效，对池内 goroutine 无效——这是最容易忽略的一点
真正难的不是写一个能跑的 WorkerPool，而是让它的生命周期、错误传播、资源归属和 Beego 的请求模型严丝合缝；多数线上问题都出在“以为池子是独立的，其实它和 Beego 共享着同一套内存、日志、连接和 panic 处理链路”。
