Revel性能优化需四层缓存：模板编译、路由解析、控制器对象池、模板函数调用。必须启用template.caching=true、预热路由、设置revel.controller.reuse=true及合理stack值，并避免模板中IO或复杂逻辑。
模板编译结果必须缓存，否则每次请求都重编译
Revel 默认启用模板缓存，但很多人改完 views/User/index.html 后没效果，就误以为“缓存没起作用”——其实是旧编译版本还在用。模板首次加载时会被编译成 Go 代码（如 template_user_index_html.go），存在 app/tmp/templates/ 下，后续请求直接 import 这个文件。不缓存等于每次请求都走 parse → compile → load 流程，高并发下 CPU 瞬间拉满。
确认是否生效：检查 conf/app.conf 中是否有这一行：
template.caching = true
别手抖写成 template.cache = true 或漏掉 =；大小写、空格、等号缺一不可。线上环境务必保持为 true，开发阶段可临时关掉便于调试。
路由解析结果也得缓存，否则每请求都做字符串匹配
Revel 的路由匹配不是靠正则逐条试，而是先将 routes 文件解析成 *ActionPathData 结构，再用 actionPathCacheMap 做 key 查找。这个 map 是全局的、带锁的，但如果你在 app.Init() 之后动态 reload 路由（比如热更新插件），旧缓存不会自动清，可能导致 404 或错路到别的 controller。
- 不要手动修改
actionPathCacheMap—— 它是私有变量，没有导出接口 - 确保
routes文件内容稳定；频繁变更路由配置时，重启服务比硬编码清理更可靠 - 高并发压测前，用
wget -qO- http://localhost:9000/@test触发一次任意路由，让缓存预热
控制器对象池必须开，不然模板渲染前就卡在 new Controller
模板渲染本身不慢，但它的上下文依赖 *revel.Controller 实例。默认每请求新建一个，GC 压力大、内存分配多、初始化耗时长。开启复用后，Controller 对象被 reset 并放回池中，避免反复 malloc/free。
在 conf/app.conf 中补全这三行：
revel.controller.reuse = true<br>revel.controller.stack = 50<br>revel.controller.maxstack = 500
注意：revel.controller.reuse 是开关，不设或设为 false，后面两个参数无效；stack 是常驻空闲数，maxstack 是上限，建议按 QPS × 平均处理时长（秒）粗估，比如 1000 QPS × 0.1s ≈ 100，设为 500 留余量。
别在模板里调用未缓存的函数或嵌套复杂 pipeline
Revel 模板支持 {{call .MyFunc "arg"}} 和自定义 funcmap，但这些函数执行是同步阻塞的。如果 .MyFunc 里做了 HTTP 请求、DB 查询或没加锁的 sync.Map.Load，模板渲染就会拖慢整个请求。
- 所有传入模板的函数必须是纯计算型，无 IO、无锁竞争、无副作用
- 避免
{{range $i, $v := .Items}}{{if eq $v.Status "active"}}{{end}}{{end}}这类嵌套判断——它在模板层展开，不如提前在 Controller 里过滤好c.RenderArgs["ActiveItems"] = filter(items) - 禁止在
funcmap里 new 大对象或启动 goroutine；模板执行期间没有 context 可 cancel，泄漏风险极高
Revel 的模板优化关键不在语法层面，而在生命周期控制：编译结果、路由映射、Controller 实例、函数调用，四层缓存缺一不可。最容易被忽略的是控制器对象池——它不显式报错，但不开的话，哪怕模板编译再快，你也在每请求创建和销毁对象上白耗 8–12ms。
