Go Fiber 如何在Recover中间件中自定义panic后的响应消息（避免暴露内部错误）

我来帮你拆解这个问题：你遇到的核心困扰是Fiber内置的Recover中间件默认会把panic的原始内容返回给客户端，而你想自定义这个响应；同时你也疑惑，既然可以自己用defer recover()处理panic，那内置Recover中间件的意义是什么？

为什么你的StackTraceHandler不生效？ #

你在代码里用了StackTraceHandler回调，但这个回调的设计目的只是处理/记录堆栈日志，而非修改响应内容。

看Fiber v2 Recover中间件的源码逻辑：当捕获到panic后，中间件会先把panic内容转换成500状态码的响应发送给客户端，之后才会调用StackTraceHandler。此时响应已经被写入连接，你在回调里调用c.SendString()自然不会有任何效果。

正确解决方案：全局错误处理器 + Recover中间件 #

要实现自定义panic响应，推荐结合全局ErrorHandler和内置Recover中间件的方式，既保留中间件的全局捕获能力，又能统一自定义客户端响应：

package main

import (
	"fmt"
	"github.com/gofiber/fiber/v2"
	"github.com/gofiber/fiber/v2/middleware/recover"
)

func main() {
	// 创建App时配置全局错误处理器
	app := fiber.New(fiber.Config{
		ErrorHandler: func(c *fiber.Ctx, err error) error {
			// 统一处理500内部错误，返回自定义友好提示
			if err.Code == fiber.StatusInternalServerError {
				// 这里可以记录错误详情到日志系统/监控平台
				fmt.Printf("Internal error details: %v\n", err)
				return c.Status(fiber.StatusInternalServerError).SendString("Unexpected error occurred.")
			}
			// 其他状态码的错误保持默认处理逻辑
			return c.Status(err.Code).SendString(err.Message)
		},
	})

	// 全局应用Recover中间件，开启堆栈跟踪功能
	app.Use(recover.New(recover.Config{
		EnableStackTrace: true,
		StackTraceHandler: func(c *fiber.Ctx, e any) {
			// 这里专注处理堆栈日志，比如写入文件、发送到APM系统
			fmt.Printf("Panic stack trace: %v\n", e)
		},
	}))

	app.Get("/", func(c *fiber.Ctx) error {
		panic("test-panic") // 客户端不会看到这个原始panic信息
	})

	_ = app.Listen(":3000")
}

测试这个代码，curl http://localhost:3000会收到Unexpected error occurred.，同时你能在控制台看到panic的堆栈和错误详情，完美实现了“隐藏内部错误+保留日志”的需求。

那Fiber的Recover中间件到底有什么用？ #

你自己写的defer recover()方案是可行的，但内置中间件的核心价值在于全局统一化处理：

1. 避免重复代码：不需要在每个路由处理函数里写defer recover()，一次全局配置，所有请求的panic都会被捕获。
2. 内置堆栈跟踪支持：开启EnableStackTrace后，自动帮你收集panic的堆栈信息，通过StackTraceHandler统一日志处理，不需要自己手动调用debug.Stack()收集堆栈。
3. 标准化错误转换：它会把不同类型的panic（比如字符串、error对象）统一转换成Fiber的标准*fiber.Error，方便后续通过全局ErrorHandler统一自定义响应。
4. 稳定性保障：虽然Go的goroutine panic不会导致整个服务崩溃，但统一捕获panic后，能避免请求的goroutine因为未处理的panic而异常退出，让服务的行为更可控。

什么时候用自己的defer recover()？ #

如果只是局部路由/路由组需要特殊的panic处理逻辑（比如某个API需要返回特定的错误格式），那用自己的defer方案更灵活。但对于全局统一的panic处理，内置Recover中间件 + 全局ErrorHandler是更优雅、可维护的选择。

内容来源于stack exchange