Revel框架无原生异步控制器，需手动用AsyncTask封装goroutine+channel实现可控异步；必须在请求生命周期内完成、设超时、显式同步，否则易致竞态、panic或资源泄漏。
Revel 框架本身不提供原生异步控制器，所有 HTTP 请求默认在单个 goroutine 中同步执行；想让耗时操作（如调用第三方 API、生成报表、发送邮件）不阻塞响应，必须手动剥离到独立 goroutine，并配合 channel 或回调机制安全传递结果。
为什么不能直接用 go func() {}() 在控制器里启动协程
直接在控制器方法中起 goroutine 很容易引发竞态和资源泄漏：当前请求上下文（c）、session、数据库连接等对象生命周期只到 return 为止；goroutine 若在响应返回后才执行，c.Session 已失效，c.Render() 不可用，写日志或存 DB 可能 panic。
- goroutine 中访问
c.Session或c.DB是危险的，除非你确保它在请求结束前完成且显式同步 - 没有超时控制时，长任务可能堆积，拖垮整个服务的 goroutine 调度器
- 错误无法被 Revel 的全局 panic 拦截器捕获，Bugsnag 等监控工具收不到上报
用 AsyncTask 封装 goroutine + channel 实现可控异步
参考 Revel 社区常用模式，定义一个轻量级 AsyncTask 结构体，内部用 sync.WaitGroup 管理生命周期，用带缓冲的 chan 传结果，避免 goroutine 永久阻塞。
type AsyncTask struct {
wg sync.WaitGroup
results chan interface{}
errors chan error
}
<p>func NewAsyncTask() *AsyncTask {
return &AsyncTask{
results: make(chan interface{}, 1),
errors: make(chan error, 1),
}
}</p><p>func (t *AsyncTask) Submit(f func() (interface{}, error)) {
t.wg.Add(1)
go func() {
defer t.wg.Done()
result, err := f()
if err != nil {
t.errors </p>
-
Submit()启动 goroutine，但不阻塞主线程；后续用select配合超时读取结果 - channel 缓冲为 1，防止 goroutine 写入时永久挂起（尤其当主线程未读取）
- 务必在控制器返回前调用
t.wg.Wait()或显式关闭 channel，否则可能内存泄漏
在控制器中安全等待异步结果并渲染
不要在 goroutine 里调用 c.Render()；正确做法是主线程发起异步任务，用 select 等待结果或超时，再统一响应。
func (c ProductController) Show() revel.Result {
task := utils.NewAsyncTask()
<pre class="brush:php;toolbar:false;">// 提交耗时操作
task.Submit(func() (interface{}, error) {
return models.GetProduct(c.Params.Get("id")), nil
})
// 主线程 select 等待，带 2s 超时
select {
case result := <p>}
</p>
- 超时必须设——否则用户卡住，服务端 goroutine 积压，T99 延迟飙升
- 错误 channel 和 result channel 必须分别接收，不能共用一个
interface{}类型 channel，否则类型断言易出错 - 若任务无需返回值（如发邮件），可改用
chan struct{}简化通信
真正难的不是起 goroutine，而是厘清“谁负责清理、谁持有上下文、超时后怎么兜底”；Revel 的请求生命周期极短，任何脱离该生命周期的操作都得自己管资源、自己设边界。别依赖框架自动回收，它不会替你等后台任务。
