buffalo框架默认不捕获panic，需用app.use注册最外层defer-recover中间件，手动返回500并记录堆栈与请求上下文，避免误吞buffalo.error，且须通过真实http请求验证生效。
Buffalo 框架默认不会自动捕获未处理的 panic，一旦发生 panic 且未被拦截，就会导致 HTTP 请求返回 500 并打印堆栈到日志——但前端通常只看到空响应或超时，排查困难。
使用 app.Use 注册全局 panic 捕获中间件
Buffalo 的中间件链在请求进入时执行，panic 可以被 recover() 拦截，但必须放在最外层中间件（即最早注册、最晚执行的位置）。常见错误是把 recover 放在业务 handler 内部，或注册顺序靠后导致无法覆盖底层 panic。
- 必须用
app.Use注册，不能用app.Middleware（后者仅作用于路由匹配后的中间件） - 中间件函数需包含
defer+recover()，且要手动写入 response（Buffalo 不会帮你渲染） - 建议在
app.go中紧贴app = buffalo.New(buffalo.Options{...})后立即注册
app.Use(func(next buffalo.Handler) buffalo.Handler {
return func(c buffalo.Context) error {
defer func() {
if r := recover(); r != nil {
c.Error(500, fmt.Errorf("panic recovered: %v", r))
}
}()
return next(c)
}
})
区分 panic 和业务错误：避免误吞 buffalo.Error
Buffalo 内部用 buffalo.Error 表示预期中的业务异常（如参数校验失败），这类错误本身不是 panic，recover() 捕不到，也不该被 recover 捕。如果在中间件里统一返回 500，反而会掩盖本该返回 400 的合法错误。
Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。
-
buffalo.Error是正常控制流，由框架自动转为对应 HTTP 状态码和 JSON/HTML 响应 - 真正需要
recover()拦截的，只有未预期的 panic（如 nil pointer dereference、map 写入未初始化、第三方库崩溃） - 可在 recover 分支中加判断：
if _, ok := r.(buffalo.Error); !ok { ... }，避免干扰业务错误路径
结合 log.Logger 记录 panic 上下文
单纯返回 500 不够，线上必须记录 panic 的完整堆栈和请求上下文（如 path、method、IP），否则无法定位问题。Buffalo 的 c.Log() 默认不输出 panic 详情，需手动调用 log.Printf 或集成结构化日志。
- 在
recover()分支中，用debug.PrintStack()输出堆栈到 stderr，或写入文件 - 推荐用
c.Request().URL.Path、c.Request().Method、c.Request().RemoteAddr补充上下文 - 注意：不要在 panic 恢复后继续执行原 handler，response writer 可能已写入部分数据，二次写入会 panic
测试 panic 捕获是否生效
最容易忽略的是：本地开发时 panic 被 IDE 或 buffalo dev 的热重载机制吞掉，看起来“没触发”。必须用真实 HTTP 请求验证。
- 写一个测试 handler：
func PanicHandler(c buffalo.Context) error { panic("test panic") }，挂到路由上 - 用
curl -v http://localhost:3000/test-panic观察是否返回 500 且日志有堆栈 - 若返回空白或 connection reset，说明中间件注册失败或顺序错误
真正难调试的不是怎么写 recover，而是 panic 发生在 goroutine 里（比如异步任务、定时器回调）——那种 panic 根本进不了 HTTP 中间件，得靠 http.Server.ErrorLog 或全局 signal.Notify 配合 runtime.Stack 单独兜底。
