必须显式设置 revel.controller.reuse=true 才能启用控制器复用，否则对象池无效；revel.controller.stack 和 maxstack 配置仅在此前提下生效，且控制器需无跨请求状态并正确实现 Reset()。
revel.controller.reuse=true 必须显式开启
默认情况下，Revel 每次请求都新建控制器实例，高并发时 GC 压力陡增、内存分配频繁。不手动启用复用，对象池形同虚设。
在 conf/app.conf 中必须明确设置：
revel.controller.reuse = true
否则即使 revel.controller.stack 和 revel.controller.maxstack 配了也没用——框架根本不会把控制器放回池里。
-
revel.controller.stack控制空闲对象保底数量（默认 10），太小会导致频繁重建；建议压测后设为 20–50 -
revel.controller.maxstack是池上限（默认 200），超限后新对象直接 new，不入池；若日均峰值请求 >5k，建议调至 300+ - 控制器类型需满足：无跨请求状态、
Reset()方法能彻底清空字段（Revel 自动生成的 reset 逻辑只清空指针和 map/slice，自定义字段需手动置零）
actionPathCacheMap 路由缓存失效的隐蔽原因
路由解析走的是字符串匹配 + 正则编译，actionPathCacheMap 缓存命中率低，往往不是配置问题，而是路径动态性导致的。
常见触发缓存失效的场景：
- URL 中含未声明的 query 参数（如
/user?id=123&debug=1，而路由定义是/user/:id），Revel 会认为这是不同 actionPath - 使用了
*.*通配路由且未加Filter排除静态资源，导致大量/static/xxx.js?v=20261103类路径涌入缓存 - 热重载开发时修改了
routes文件但没触发完整 reload，旧 cache 未清理，新旧路由混存
验证是否生效：启动时观察日志是否有 Loaded routes from conf/routes，之后再发请求，看 router.go 中 actionPathCacheMap 的 len() 是否稳定增长而非持续重置。
别忽略 revel.interceptor 的执行开销
拦截器（Interceptor）看似轻量，但每个请求都会顺序执行全部注册的拦截器。一旦在 BEGIN 或 FINISH 阶段做了同步 I/O（比如查 Redis、调远程 API），性能会断崖下跌。
典型踩坑点：
- 把鉴权逻辑写在
BEGIN里，却对静态资源（/public/）也全量校验——应加路径前缀判断提前 return - 在
FINISH中统一打日志，但用了fmt.Sprintf拼接大结构体，GC 分配压力翻倍 - 多个拦截器重复解析同一份
req.Header，比如都调req.Header.Get("X-Trace-ID")，不如提取到Controller字段一次缓存
建议用 revel.BEFORE 替代 BEGIN 处理真正需要前置的动作，避免无差别拦截。
GC 压力大的真实瓶颈常不在业务代码
压测时看到 GC 频繁、堆增长快，第一反应常是“查自己写的 struct”，但 Revel 的底层对象池行为才是关键变量。
几个容易被跳过的检查点：
- 确认
runtime.ReadMemStats中的PauseNs主要来自controller.Reset()后的 slice 扩容（比如日志字段 append 导致底层数组反复 realloc） - 禁用
revel.controller.reuse时，pprof 显示大量newControllerEmpty调用栈；启用后若仍有高频 alloc，说明有控制器字段未被Reset()清理（如自定义 sync.Pool 字段未 Release） - HTTP body 读取未用
ioutil.ReadAll以外的方式（如直接io.Copy(ioutil.Discard, req.Body)），导致req.Body被多次读取并触发内部 buffer 复制
最有效的定位方式：用 go tool pprof -http=:8080 http://localhost:9000/debug/pprof/heap 对比启用/禁用复用时的 heap profile，重点看 top3 alloc_objects 来源是否从 controller.* 切换到了你自己的类型。
