echo的recover中间件默认不启用，echo.new()创建的实例必须显式调用e.use(echo.recover())才能捕获panic，且须置于中间件链最前端；它仅捕获当前http请求goroutine的panic，不处理启动期、后台goroutine或信号触发的panic。
Recover中间件默认是否捕获panic
默认不捕获。Echo的echo.New()创建的实例**不会自动启用Recover中间件**，即使你写了defer recover()也无效——这是常见误解。Recover中间件必须显式注册，且必须在其他可能触发panic的中间件或路由处理器之前注册，否则panic会直接向上抛出到HTTP服务器层，返回500且无日志。
如何正确注册Recover中间件
调用e.Use(echo.MiddlewareFunc(recover))是错的；Echo提供的是封装好的echo.Recover()函数，不是原始recover()。它内部做了panic捕获、错误日志记录和500响应设置，但**不终止请求链**（即不会自动c.Abort()），所以后续中间件仍会执行——这点容易被忽略。
- 正确写法：
e.Use(echo.Recover()) - 位置关键：必须放在
e.Use(...)链的最前面，比如在Logger()之后、BodyLimit()之前 - 若自定义错误处理逻辑（如上报 Sentry），需在
echo.Recover()后注册另一个中间件，通过c.Get("echo.recover.error")取到panic值
Recover中间件对错误日志和响应的影响
默认行为是：打印panic堆栈到标准错误（stderr），并返回500 Internal Server Error和空响应体。但实际生产中常需定制：
- 关闭默认日志：传入
echo.RecoverWithConfig(echo.RecoverConfig{DisableStackAll: true}) - 自定义响应体：设置
RecoverConfig.HTTPErrorHandler，例如返回JSON格式错误 - 注意：如果在panic发生前已写入部分响应头（如
c.Response().Header().Set("X-Trace-ID", ...)），Recover中间件无法撤回这些头，可能导致客户端收到不一致响应
哪些panic不会被Recover捕获
Recover中间件只捕获当前HTTP请求goroutine中的panic。以下情况它无能为力：
- 启动阶段panic（如
echo.New()后立即panic） - 后台goroutine中的panic（如
go func() { panic("oops") }()） - 信号处理中触发的panic（如
os.Interrupthandler） - 使用
os.Exit()或syscall.Exit()——它们不经过defer链，Recover完全无效
这类问题需要配合全局signal.Notify监听、后台goroutine的recover包裹、以及进程级监控来覆盖。
