Buffalo默认不recover panic，需手动注册顶层RecoverPanic中间件：defer recover→重置Status=500→记录堆栈→调c.Error(500, ...)；避免日志或响应副作用，生产禁用堆栈输出。
Buffalo里panic没被捕获，页面直接500或空白
默认情况下，Buffalo不会自动recover HTTP handler里的panic——一旦中间件或handler内部触发panic()，整个请求协程崩溃，返回空响应或500，且无日志。这不是bug，是设计选择：框架把错误处理权交给你，避免掩盖逻辑问题。
必须手动注册全局panic恢复中间件，且要放在所有其他中间件之前（尤其是pop.Transaction、auth.Middleware这类依赖context的），否则panic发生在它们内部时，你注册的recover中间件根本没机会运行。
- 注册位置必须是
app.Use()最顶层，比如app.Use(RecoverPanic)写在app.Use(pop.Transaction(app.DB))之前 - 不要在路由级或Group级注册recover——它必须覆盖全部入口，包括静态文件和健康检查端点
- recover函数里别调
c.Error()或c.Render()以外的副作用（如发告警），因为此时responseWriter可能已写入部分header，再写会panic
RecoverPanic中间件怎么写才不丢上下文和状态码
常见错误是只做recover()却忽略c.Response().Status已被提前设为500，或没把原始panic值记进日志。正确做法是：捕获panic后，显式重置status为500（防止某些中间件误设）、记录panic堆栈、再调用c.Error()走统一错误响应流程。
func RecoverPanic(next buffalo.Handler) buffalo.Handler {
return func(c buffalo.Context) error {
defer func() {
if r := recover(); r != nil {
c.Response().Status = 500
log.Errorw("panic recovered", "panic", r, "stack", debug.Stack())
c.Error(500, errors.New("internal server error"))
}
}()
return next(c)
}
}
- 必须用
defer包裹recover()，且defer要放在next(c)调用前 - 别用
fmt.Printf或log.Println——Buffalo的日志器支持结构化字段，用log.Errorw才能把panic值和堆栈当字段存 - 调
c.Error(500, ...)而不是c.Render(500, ...)，确保走应用定义的错误模板或JSON格式
为什么加了RecoverPanic还是看到白屏或connection reset
两种典型场景：一是panic发生在HTTP server底层（比如TLS握手失败、responseWriter.Write时连接已断），这类panic根本进不到Buffalo handler链；二是recover中间件本身panic了（比如日志器配置错导致log.Errorw panic），形成无限递归。
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
- 检查
app.Serve()外层是否包了http.ListenAndServe的recover——Buffalo不处理这个层级的panic - 临时注释掉recover中间件里的所有业务逻辑（只留
c.Error(500, ...)），确认是否中间件自身出问题 - 如果用
buffalo.New(buffalo.Options{...})启服务，确保Options.Env不是"development"——开发模式下某些panic会被框架强制转成HTML错误页，掩盖真实行为
生产环境要不要打印panic堆栈到响应体
绝对不要。开发时可设app.Options.Env = "development"让Buffalo返回带堆栈的HTML错误页，但生产必须关掉。暴露堆栈等于泄露路径、变量名、依赖版本，给攻击者提供信息。
真正该做的是：把debug.Stack()结果打到日志系统（如Loki+Grafana），并关联request ID；前端收到500时只显示“服务暂时不可用”，不透任何技术细节。
容易被忽略的一点：debug.Stack()在高并发下有性能开销，线上建议用runtime.Stack(buf, false)配小缓冲区，或改用errors.WithStack()（需集成github.com/pkg/errors）做轻量标注。
