fiber无默认panic捕获机制，必须显式注册fiber.recover()或自定义errorhandler；前者仅处理panic并默认返回含敏感信息的html，生产环境须禁用堆栈；后者统一处理return的error，两者职责分明、不可替代。
Fiber 没有全局“自动捕获 panic 并转成 HTTP 错误”的默认行为，错误必须显式处理或手动注册错误处理器；不写c.Next()、不调recover()、不注册app.Use(fiber.Recover())，500 错误就直接透出给客户端或导致连接中断。
为什么 fiber.Default() 的 Recover 中间件不能直接复用
fiber.Default() 自带 fiber.Recover()，但它只对 panic 生效，且默认返回 HTML 错误页（含堆栈），**生产环境必须替换**：它会把敏感路径、变量名甚至数据库连接串打在响应里；另外，它不处理业务逻辑中主动 return errors.New("xxx") 这类非 panic 错误。
- 开发阶段可临时用，上线前务必移除或重写
- 若保留，至少禁用堆栈：
fiber.Recover(func(c *fiber.Ctx, err error) { c.Status(500).SendString("Internal Error") }) - 它无法捕获
fasthttp.ErrTimeout等底层错误——那些是函数返回值，不是 panic
如何注册自定义错误处理器（推荐）
Fiber 提供 app.ErrorHandler 钩子，所有中间件/路由中 return err 的错误都会流经这里。这是统一格式、分级日志、拦截敏感信息的核心位置。
- 必须在
app.Get()等路由注册前设置，否则不生效 - 函数签名固定：
func(*fiber.Ctx, error) error，返回的 error 会被再次传入该处理器（可做兜底） - 常见做法：按 error 类型分发，比如
errors.Is(err, ErrValidation)返回 400，errors.As(err, &fasthttp.StatusError{})复用状态码 - 别在 handler 里直接
c.JSON()后 return —— 应统一走c.Status().JSON()并 return，避免被后续中间件覆盖
app.ErrorHandler = func(c *fiber.Ctx, err error) error {
// 区分错误类型
if errors.Is(err, ErrNotFound) {
return c.Status(fiber.StatusNotFound).JSON(fiber.Map{"error": "not found"})
}
if errors.As(err, &fasthttp.StatusError{}) {
return c.Status(fiber.StatusInternalServerError).JSON(fiber.Map{"error": "service unavailable"})
}
// 兜底
log.Printf("unhandled error: %v", err)
return c.Status(fiber.StatusInternalServerError).JSON(fiber.Map{"error": "internal error"})
}
中间件中错误怎么“抛出”才能进 ErrorHandler
只有 return err（且 err != nil）才会触发 app.ErrorHandler；c.Status(401).Send() 是正常响应，不视为错误，也不会进 ErrorHandler。
- 权限校验失败：用
return errors.New("unauthorized")，而不是c.Status(401).Send() - 解析失败：用
return c.BodyParser(&v)，它本身返回 error，可直接 return - 第三方调用失败：封装后显式
return fmt.Errorf("call payment failed: %w", err) - 千万别写
return c.Status(400).JSON(...)—— 这是响应，不是错误，ErrorHandler 收不到
panic 和业务错误必须分开处理
panic 是程序异常崩溃，业务错误是预期中的失败路径。Fiber 要求你明确区分二者：前者靠 fiber.Recover() 拦截，后者靠 app.ErrorHandler 统一格式化。
- panic 可能来自空指针解引用、数组越界等，必须用
Recover防止进程退出 - 业务错误如 “用户不存在”、“参数校验失败”，应主动构造 error 并 return，交由 ErrorHandler 处理
- 两者日志级别不同：panic 记 ERROR + 堆栈，业务错误记 WARN 或 INFO（视严重程度）
- 别在 ErrorHandler 里再 recover —— 它只处理 return 的 error，不处理 panic
最容易被忽略的是：app.ErrorHandler 不处理中间件中未 return 的 error，也不捕获 panic；而 fiber.Recover() 对业务 error 完全无效。两个机制并存且职责分明，漏掉任一环节，错误就会裸奔。
