必须检查t.Execute返回的error而非依赖panic，错误信息含原始模板行号；启用dev模式、禁用template.caching、清空tmp/目录确保定位准确。
Revel 模板渲染错误默认藏在堆栈深处，不显式捕获就只能看到 template.go:123 这类无意义行号——你得主动拦截执行结果，而不是等 panic。
检查 t.Execute 返回的 error 而不是依赖 panic
Revel 底层用的是 Go 原生 html/template，Execute 方法**一定返回 error**，但 Revel 的控制器封装里默认不暴露它。你必须在自定义渲染逻辑中手动介入：
- 不要直接调用
c.Render()后就认为万事大吉；如果想精准捕获，应改用c.RenderTemplate("path/to.html", data)并检查其返回值（需自行包装） - 更直接的做法：在控制器 Action 中绕过
c.Render，用revel.BEFORE或自定义函数提前编译并执行模板，例如：buf := &bytes.Buffer{}<br>err := revel.MainTemplate.Execute(buf, data)<br>if err != nil {<br> revel.ERROR.Printf("render fail: %v", err)<br> // 此时 err 是形如 "user.html:42:21: executing \"body\" at <.user.name>: can't evaluate field Name"<br>}</.user.name> - 错误信息里的行号是原始模板文件的物理行号，不是编译后 Go 代码的行号——查错时直接打开
app/views/User/show.html跳转到对应行即可
启用 dev 模式 + 清空 tmp/ 才能看见真实模板位置
即使你拿到了 error 字符串，若没开对模式或缓存污染，行号仍可能指向旧版本模板。
- 确认
conf/app.conf中run.mode = dev且未被其他区块覆盖（比如[prod]下又写了同名配置） - 每次修改模板后，必须执行
revel clean或手动删掉项目根目录下的tmp/目录——否则 Revel 会复用旧的template_user_show_html.go编译产物，导致行号映射失效 - dev 模式下触发错误时，浏览器会显示带高亮源码的错误页，左侧是
views/User/show.html内容，右侧调用栈里会出现app/views/User/show.html:42这种可点击跳转的链接
禁用模板缓存避免“改了却没生效”的假问题
Revel 默认开启模板缓存，你改完 HTML 保存，刷新页面还是旧逻辑——这不是渲染错误，而是缓存让你误判。
- 在
conf/app.conf中添加配置：template.caching = false（注意等号前后有空格） - 该配置仅影响模板解析阶段，不影响 Go 代码编译缓存；重启应用后立即生效
- 生产环境务必关掉这个选项，否则每次请求都重新 parse 模板，性能损耗明显
用 {{print .Field}} 和日志双通道验证数据流
很多“渲染错误”其实不是语法问题，而是传进模板的结构体字段为 nil 或类型不匹配，Execute 报的错看起来像语法错，实则是运行时字段访问失败。
- 在模板顶部插入
{{print .User}}，看输出是否为 - 在控制器中加日志：
revel.WARN.Printf("to template: %+v", user)，确认传入前数据状态 - 如果字段确实为
nil，模板里必须用{{with .User}}{{.Name}}{{else}}游客{{end}}包裹，不能直写{{.User.Name}} - 避免在模板中调用可能 panic 的自定义函数；若必须用，函数签名应为
func(x interface{}) (string, error)，并在模板中用{{with $r, $e := .MyFunc .X}}{{if $e}}[ERR]{{else}}{{$r}}{{end}}{{end}}
真正难定位的永远不是报错本身，而是错误发生时你手头的数据和模板版本是否跟调试器里看到的一致——tmp/ 不清、template.caching 不关、run.mode 没切对，三者任一出问题，所有错误信息都会失真。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
