模板解析错误不触发panic，recover捕获不到；必须显式检查c.html()等返回的error并调用c.error()注入，由统一错误中间件识别template.execerror类型并日志记录、降级响应。
模板解析错误不会触发 panic，recover() 捕不到
很多人在写 CustomRecovery() 中间件后发现，模板渲染出错（比如 {{ .User.Name }} 但 .User 是 nil）时，defer + recover() 完全没反应——这是因为 html/template 的执行错误是普通 error，不是 panic。它会直接返回给 Gin，但 Gin 默认不拦截、不记录，只悄悄吞掉或返回空响应，连 HTTP 状态码都可能是 200。
c.HTML() 调用必须显式检查返回的 error
所有模板渲染入口点（c.HTML()、c.LoadHTMLFiles() 后的 c.HTML()）都返回 error，但 Gin 不强制你处理。漏掉检查，就等于放弃对模板错误的控制权。
- 正确做法：每次调用后立刻判断
err != nil，并调用c.Error(err)注入错误链 - 错误示例：
c.HTML(200, "user.html", data)后没接if err != nil { ... } - 模板错误类型通常是
*errors.errorString或*template.ExecError，可用errors.Is(err, template.ErrNotExist)做细粒度判断 - 不要用
log.Printf替代c.Error()：只有注入c.Error()，后续统一错误中间件才能捕获并格式化
统一错误中间件需识别 template. 相关错误
业务错误和模板错误要分层处理：日志里要留 stack 和模板名，前端响应则应降级为友好的 500 页面或 JSON 提示，不能暴露模板路径或变量名。
- 在自定义错误处理中间件（如
ErrorResponse()）中，加一层类型断言：if errors.As(err, &templateErr) { log.Error("template exec failed", zap.String("template", templateErr.Name), zap.String("error", err.Error())) } - 生产环境避免返回
templateErr.Error()给前端，它含敏感上下文（如行号、变量名），建议固定返回"页面加载异常，请稍后重试" - 若使用
html/template的FuncMap，函数内 panic 会被模板引擎转为*template.ExecError，仍属“非 panic 错误”，同样需要手动检查
调试阶段可临时启用模板 debug 模式
开发时快速定位模板问题，别靠猜。Go 标准库支持开启 template debug 输出，但 Gin 默认不透出——得自己改。
- 在初始化模板时，用
template.New("name").Funcs(...).Option("missingkey=error")，让缺失 key 直接报错而非静默忽略 - 启动时设置环境变量：
export GIN_MODE=debug，配合自定义日志中间件打印c.Errors，能看到模板错误是否被成功注入 - 注意：
Option("missingkey=error")对nil接口字段无效，它只管 map key 和 struct field 不存在的情况；nil引用仍需靠if .User != nil手动防护
c.HTML() 是否守住了 error 检查这道门——漏一次，就少一次可观测性。
