Buffalo错误处理需分场景控制panic暴露、状态码、模板fallback与上下文延续，否则导致白屏500或静默失败；关键点包括预编译模板、严格路径约定、禁用Recovery调试、显式context传递及error模板精准命名与启用。
Buffalo 的错误处理不是靠“加一层 middleware 就完事”，而是要分场景控制 panic 暴露、HTTP 状态码、模板 fallback 和上下文延续——否则你看到的永远是白屏 500 或静默失败。
模板渲染失败时 panic: template not found 怎么提前发现
这是开发期最高频的 panic，本质是 r.HTML() 或 r.Auto() 找不到文件。Buffalo 不会遍历目录，它严格按约定路径查找：r.HTML("admin.dashboard") → templates/admin/dashboard.html（点号 = 目录分隔），不是斜杠。
- 拼写必须全小写，
Dashboard.html≠dashboard.html - 路径必须用点号，
r.HTML("admin/dashboard.html")一定失败，得写成r.HTML("admin.dashboard") - 启动时就校验：在
app.go的App()函数里加app.PrecompileTemplates()，启动失败时直接报template "users/show.html" not found，而不是等用户点进页面才 panic - 若用
buffalo dev启动但没看到报错，说明app.PrecompileTemplates()没生效——检查是否写在return app之前，且没被条件分支跳过
调用第三方接口时 panic 被吞掉，怎么拿到真实堆栈
默认的 middleware.Recovery 会捕获所有 panic 并返回 500，但原始错误（比如 http.Post: context deadline exceeded）完全丢失。
Buffalo框架 1.0.1
下载
Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。
- 开发联调阶段，注释掉
app.Use(middleware.Recovery)（在app.go中） - 改用
go run main.go启动，绕过buffalo dev的日志封装层 - 在 handler 里加兜底 recover：
defer func() { if r := recover(); r != nil { log.Printf("PANIC: %v", r) } }() - 别用
c.Request().Context()构造 HTTP 请求——它不传递 timeout，必须手动context.WithTimeout(context.Background(), 3*time.Second)，且记得defer cancel()，否则 goroutine 泄漏
表单验证失败后重渲染，为什么数据全丢了
这不是模板问题，是上下文没延续。c.Render(200, r.HTML("new.html")) 只渲染模板，原始 POST body 已丢弃。
- 必须显式把绑定后的结构体存入 context：
c.Set("user", &u)（&u是已通过c.Bind(&u)填充的实例） - 结构体字段要有
form:"name"tag，否则模板里{{.user.Name}}取不到值 - 模板中用
{{if .FormErrors}}{{.FormErrors.name}}{{end}}渲染错误，.FormErrors是 Buffalo 自动注入的 map - 漏掉
c.Set()，重渲染就是空表单——用户填半天，提交失败后得重来一遍
自定义 404/500 页面不生效，常见卡点在哪
Buffalo 对错误页路径和命名极其严格，错一个字符就不加载。
- 文件必须放在
templates/error/下，且只能叫404.plush.html和500.plush.html——templates/404.html或templates/error/404.html都无效 - 必须启用
middleware.Renderer，检查app.go是否有app.Use(middleware.Renderer)；API 项目默认不启用，需手动加 - 开发模式下修改后必须重启
buffalo dev，它不会热重载 error 模板——缓存不刷新，浏览器就一直看到旧内容或空白 - 如果用了 Plush 模板，不能混用
{{.}}和 Go 原生{{.Name}}语法，否则编译失败，错误页直接 fallback 到默认白屏
最易被忽略的是 context 透传和模板预编译——前者导致错误被吞、超时不触发；后者让 panic 拖到运行时才暴露。这两点不处理，调试成本会指数级上升。
