Gin框架需分别处理404、405和500错误：NoRoute/NoMethod注册路由级错误，CustomRecovery捕获panic，业务error需手动c.Error()注入并用中间件统一响应。
Buffalo 框架没有叫 Buffalo 的官方框架——你大概率是把名字记混了。Go 生态里主流 Web 框架是 Gin、Echo、Chi，而 Buffalo 是一个早已停止维护（2021 年归档）的全栈 Ruby 风格框架，和 Go 无关；InsightFace 里倒是有 buffalo_l 模型，但那是模型名，不是 Web 框架。
所以你真正想问的，极可能是以下之一：
- ✅ 用
Gin怎么配置自定义错误处理 - ✅ 用
Echo怎么统一捕获并格式化错误 - ❌ 不是 Buffalo（Go 没有 Buffalo 框架，Ruby 的 Buffalo 不适用于当前上下文）
我们按最可能的场景——Gin——来展开。
为什么 Gin 的 error handler 容易配错
很多人直接在 gin.Default() 后加 engine.Use() 中间件，却发现 404 或 panic 错误根本没走自定义逻辑。这是因为 Gin 的错误分三类：路由未匹配（404）、中间件 panic、业务逻辑返回的 error，它们触发路径不同，必须分别处理。
Gin 中 404 和 500 错误必须分开注册
Gin 不像 Echo 提供统一的 HTTPErrorHandler 接口，它靠两个独立注册点：
Buffalo框架 1.0.1
下载
Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。
-
engine.NoRoute()：只捕获所有未匹配路由的请求（即 404），必须放在所有GET/POST注册之后 -
engine.NoMethod()：捕获方法不支持（如对 POST 路由发 GET），常和NoRoute一起注册 -
gin.Recovery()中间件默认只打印 panic 日志，不返回结构化响应——你需要自己重写它
示例：
engine := gin.Default()
// 必须放最后！否则会被前面的路由覆盖
engine.NoRoute(func(c *gin.Context) {
c.JSON(404, gin.H{"error": "not found"})
})
engine.NoMethod(func(c *gin.Context) {
c.JSON(405, gin.H{"error": "method not allowed"})
})
// 替换默认 Recovery，捕获 panic 并返回 JSON
engine.Use(gin.CustomRecovery(func(c *gin.Context, err interface{}) {
c.JSON(500, gin.H{"error": "internal server error"})
}))
业务 error 怎么透传到统一 handler
Gin 本身不拦截函数返回的 error，你要手动调用 c.Error() 把 error 注入上下文，再在后续中间件里统一读取、响应：
- 在 handler 里别只写
return err，而是c.Error(err) - 写一个中间件，在
c.Errors.ByType(gin.ErrorTypeAny)里取第一个 error 并渲染 - 注意：这个中间件必须在所有业务 handler 之后注册（即
Use()放在GET/POST之后）
常见坑：c.Error() 不会自动中断执行，你得手动 return，否则后续代码仍会运行。
真正容易被忽略的一点
如果你用 gin.BasicAuth() 或 jwt-go 类中间件，它们内部 panic 时不会进你写的 CustomRecovery，除非你把 recovery 放在 auth 中间件外层——顺序错了，整个错误链就断了。调试时建议先关掉所有第三方中间件，确认基础 error flow 走通再逐个加回。
