Fiber 的 405 响应不能被中间件捕获，因其由路由层直接返回，不经过中间件链；必须通过显式注册 app.All() 路由并手动校验方法，或使用 MethodGuard 中间件主动守卫。
Fiber 是 Go 语言的轻量级 Web 框架（基于 fasthttp），它没有内置的、类似 Spring Boot 的拦截器机制，也不通过“注册拦截器 + 路径匹配”来统一处理 HTTP 方法错误。它的 405 响应由路由层直接控制——当请求方法不匹配任何已注册的 handler 时，Fiber 默认返回 405 Method Not Allowed，且不经过中间件链。
所以，你无法用“拦截器”方式捕获 405；但可以在路由定义阶段主动覆盖默认行为，实现自定义响应。
Fiber 中 405 响应为什么不能被中间件捕获
-
Fiber的中间件（app.Use()）只对成功匹配到路由的请求生效； - 如果一个请求的
method + path在整个路由树中找不到对应 handler（比如发了个POST /api/user，但只注册了GET /api/user），Fiber会跳过所有中间件，直接进入 fallback 流程，返回硬编码的 405； - 这个 fallback 不走
app.All()或app.Use()，也无法被app.SetErrorHandler()拦截（该函数只处理 handler 内部 panic 或显式ctx.Status().SendString()类错误）。
如何真正自定义 405 响应内容
必须显式注册所有可能的方法组合，用 app.All() 或按方法逐个注册，再在 handler 中判断是否允许：
app.Get("/api/user", getUser)
app.Post("/api/user", createUser)
app.Put("/api/user", updateUser)
// 捕获所有其他方法对该路径的访问
app.All("/api/user", func(c *fiber.Ctx) error {
if c.Method() != "GET" && c.Method() != "POST" && c.Method() != "PUT" {
return c.Status(fiber.StatusMethodNotAllowed).
JSON(fiber.Map{"code": "METHOD_NOT_ALLOWED", "message": "该资源不支持此 HTTP 方法"})
}
return nil // 让后续 handler 继续处理（实际不会走到这里，因为 method 已过滤）
})-
app.All()是关键：它注册一个兜底 handler，覆盖所有 HTTP 方法； - 必须放在具体
Get/Post/Put注册之后，否则会提前拦截； - 里面手动检查
c.Method()，只放行已支持的方法，其余统一返回自定义 JSON。
更健壮的做法：封装成可复用的“方法守卫”
避免每个路由都写重复判断，可以抽象为中间件风格的函数：
func MethodGuard(allowed ...string) fiber.Handler {
allowedSet := make(map[string]bool)
for _, m := range allowed {
allowedSet[m] = true
}
return func(c *fiber.Ctx) error {
if !allowedSet[c.Method()] {
return c.Status(fiber.StatusMethodNotAllowed).
JSON(fiber.Map{
"code": "METHOD_NOT_ALLOWED",
"message": "不支持的请求方法：" + c.Method(),
"allowed": allowed,
})
}
return c.Next()
}
}
// 使用
app.Get("/api/order", MethodGuard("GET"), getOrder)
app.Post("/api/order", MethodGuard("POST"), createOrder)
// 注意：这里不能用 app.All，因为 MethodGuard 是中间件，需配合具体 method 注册⚠️ 注意：这个方式要求你每个路径都显式注册支持的方法，而不是依赖 fallback。它把“是否允许”逻辑前移到了中间件，而非靠框架自动判断缺失 handler。
容易踩的坑
- 直接在
app.Use()中检查c.Method()并返回 405 —— 无效，因为 405 请求根本不会进Use()； - 用
app.SetErrorHandler()试图捕获 405 —— 不生效，它只处理 handler 执行期错误； - 把
app.All("/path", ...)放在app.Get("/path", ...)之前 —— 会导致所有请求都被All拦截，Get永远不执行； - 忘记在自定义响应里设置
Content-Type: application/json——Fiber默认不设，前端可能解析失败。
405 是路由层最底层的语义错误，Fiber 的设计让它绕过常规处理流程。想控制它，就得放弃“拦截”思路，转为“主动声明+守卫”。真正难的不是写代码，而是意识到：这不是异常，是设计决策的一部分。
