Revel高并发优化需开启控制器复用、异步I/O和Filter限流：设revel.controller.reuse=true启用对象池，耗时操作移出Controller并用channel或异步处理，通过Filter实现超时控制与并发限流。
Revel 默认是同步阻塞式处理请求的，单个请求卡住就会拖慢整个并发吞吐——这不是框架不行，而是默认配置没打开异步能力。真要撑住高并发，得从控制器生命周期、I/O 调度和外部协作三个层面动手。
revel.controller.reuse = true 必须开启
每个请求创建新控制器实例在高并发下会快速触发 GC 和内存抖动。Revel 内置对象池但默认关闭。
-
revel.controller.reuse设为true，控制器处理完后会被重置并归还池中，而非销毁 -
revel.controller.stack控制空闲对象保底数（建议设为50） -
revel.controller.maxstack控制池上限（建议500，避免内存无节制增长） - 不配这个，1000 QPS 下 GC 次数可能翻 4 倍，
runtime.GC成为性能瓶颈
耗时 I/O 操作必须移出 Controller 方法
像 models.GetProduct() 或 api.GetLogisticsInfo() 这类同步调用，哪怕只花 200ms，也会让整个 goroutine 阻塞——Revel 的 ActionInvoker 是串行调度的，无法靠 goroutine 并发掩盖。
- 把耗时逻辑拆成独立函数，用
go func() { ... }()启动，但注意：不能直接在c.Result中引用未完成的变量 - 更稳妥的做法是改用 channel + select 等待，或提前返回
revel.RenderJson告知前端“已接收，稍后推送”，再走 WebSocket / SSE / 轮询补全数据 - 千万别在
Controller方法里用time.Sleep或http.Get——这等于给所有排队请求加锁
用 Filter 实现请求分流与超时控制
Revel 的 Filter 链在 Action 执行前就介入，适合做并发限流和兜底熔断。
- 在
app/init.go的init()函数里往revel.InterceptFunc或自定义Filter中插入逻辑 - 用
sync.Pool或带容量的chan struct{}实现简单计数限流，比如只允许最多100个活跃请求 - 对特定路径（如
/api/report）加context.WithTimeout(c.Request.Context(), 3*time.Second)，超时直接c.Result = revel.Status(408) - 注意：Filter 中修改
c.Result会跳过后续 Filter 和 Action，务必确认这是你想要的行为
真正难的不是“怎么开 goroutine”，而是确保状态不逃逸、结果可预期、错误能收敛。Revel 的 Filter 链和控制器复用机制已经提供了足够杠杆，但默认关着——打开它，比换框架快得多。
