revel模板性能瓶颈主因是缓存未启用、对象复用关闭及nil/作用域误判；启用控制器复用（revel.controller.reuse=true）、开启模板缓存（template.caching=true）并规范range判空与变量命名，可显著降gc压力与解析开销。
Revel模板默认性能不差，但未经调优时在高并发下容易暴露GC压力大、重复编译、路由解析开销高等问题——关键不是模板引擎本身慢，而是缓存未启用、对象复用关闭、模板结构没做防御性处理。
启用控制器对象池复用能直接压降70% GC压力
Revel默认每个请求新建一个控制器实例，高频请求下会频繁触发内存分配和回收。必须显式开启复用机制：
- 在
conf/app.conf中设置revel.controller.reuse=true - 调整池容量：
revel.controller.stack=50（空闲保底数），revel.controller.maxstack=500（上限） - 注意：对象复用生效的前提是控制器方法不持有长生命周期引用（如未关闭的
*sql.DB或未重置的map字段），否则会出现数据污染
模板缓存必须禁用开发模式下的自动清理
dev模式下template.caching=false是调试友好，但上线后必须改回true，否则每次请求都重新解析+编译HTML，性能损失显著：
- 模板首次加载时编译为
app/tmp/templates/template_xxx.go，后续直接执行编译后代码 - 若
template.caching=false，即使内容未变，也会跳过缓存走全量编译路径 - 线上环境务必确认
conf/app.conf中该配置为true，且app/tmp目录可写
range迭代切片时避免nil panic和上下文覆盖
模板里写{{range .Items}}看着简洁，但.Items为nil时会直接panic，且$变量未声明易被子模板覆盖：
- 必须前置判空：
{{if .Items}}{{range $i, $item := .Items}} - 传参给子模板时，显式用
$i或$item，别依赖.——因为{{template "sub.html" .}}会把当前$item作为.传入，而{{template "sub.html" $i}}才能传索引 - 嵌套
range时，外层$i在内层作用域仍有效，但若内层也用$i会覆盖，应改用$outerI等命名
路由缓存失效会导致每请求多1–2ms解析开销
Revel用actionPathCacheMap缓存URL到Action的映射，但某些配置变更（如动态加载模块、运行时修改routes文件）可能未触发自动清理：
- 观察日志中是否频繁出现
Router: parsing route类信息，这是缓存未命中信号 - 确保
conf/routes文件未被程序运行时写入或替换，否则缓存不会自动刷新 - 极端场景下可手动调用
revel.BuiltinController.ReloadRoutes()强制重建缓存，但需配合锁防止并发冲突
真正卡顿的点往往不在模板语法本身，而在对象生命周期管理、缓存开关状态、以及对nil和作用域的误判——这些地方改几行配置或加两个判断，比换模板引擎见效快得多。
