httperrorhandler无法捕获中间件panic，因其仅处理handler显式返回的error，不处理任何panic；真正捕获panic的是e.use(middleware.recover())，且必须作为首个中间件注册。
为什么 HTTPErrorHandler 无法捕获中间件 panic？
Echo 默认的 HTTPErrorHandler 只处理路由处理器（handler）内显式调用 c.Error() 或返回非 nil error 的情况，**不处理中间件或 handler 中发生的 panic**。一旦中间件里发生 panic（比如空指针、类型断言失败），Echo 会直接崩溃或返回 500，且错误堆栈不会进日志——这是分布式系统中最隐蔽的故障盲区。
真正起作用的是 e.Use(middleware.Recover())，它必须放在所有自定义中间件之前（尤其是鉴权、日志等可能 panic 的中间件），否则 panic 会在到达 Recover 前就中断请求链。
-
middleware.Recover()是唯一能拦截 panic 并转为 HTTP 响应的标准方案 - 若自行用
defer/recover包裹 handler，需手动设置c.Response().Status和写 body，易遗漏 header 或状态码 - 在微服务间通过 gRPC 或消息队列通信时，panic 若未被捕获，会导致上游超时而非明确错误，排查成本陡增
如何让 Recover 返回结构化错误并透传 traceID？
默认 middleware.Recover() 返回纯文本 500 响应，不带 traceID、不兼容前端 JSON 错误协议。你需要用 middleware.RecoverWithConfig() 自定义恢复逻辑：
e.Use(middleware.RecoverWithConfig(middleware.RecoverConfig{
DisableStackAll: false,
StackTraceHandler: func(c echo.Context, err interface{}) {
// 从 context 提取 traceID（假设已由 jaeger/otel 中间件注入）
traceID := c.Get("trace_id")
log.Error().
Interface("error", err).
Str("trace_id", fmt.Sprintf("%v", traceID)).
Stack().Send()
// 统一 JSON 错误响应
c.JSON(http.StatusInternalServerError, map[string]interface{}{
"code": "INTERNAL_ERROR",
"message": "服务内部异常",
"trace_id": traceID,
})
},
}))
-
DisableStackAll: false才能触发StackTraceHandler，设为 true 会跳过堆栈收集 - 务必检查 traceID 是否真实存在（
c.Get("trace_id") != nil），否则fmt.Sprintf("%v", nil)会输出 "" 字符串 - 不要在
StackTraceHandler里调用c.String()或c.JSON()以外的方法（如c.Redirect()），Echo 此时已进入 recover 状态，部分上下文字段不可用
第三方中间件（如 JWT、CORS）引发 panic 怎么办？
JWT 验证中间件常见 panic 场景：token 为空时直接 token.Claims["user_id"] 断言 string，未判空；CORS 中间件在某些旧版 Echo（
解决核心是「前置防御 + 后置兜底」：
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 所有第三方中间件前加
e.Use(middleware.RecoverWithConfig(...))，确保 panic 不逃逸 - JWT 中间件自己做防御：用
token.Claims.(jwt.MapClaims)断言后，再检查claims["user_id"] != nil - 升级 Echo 到 v4.10+，老版本
middleware.CORS()在无 origin 头时会 panic，新版本已修复 - 若使用自研中间件，统一用
echo.HTTPError替代 panic，例如return echo.NewHTTPError(http.StatusUnauthorized, "missing auth header")
分布式链路下，错误日志为何总丢失上下文？
单机日志能打 traceID，但跨服务调用时，如果下游服务没从 X-Trace-ID 或 traceparent header 解析并注入 context，recover 日志里的 traceID 就是空的——这不是 Echo 的问题，而是链路透传断裂。
关键动作只有两个：
- 入口中间件必须解析并绑定 traceID：
c.Set("trace_id", c.Request().Header.Get("X-Trace-ID"))（或用 OpenTelemetry SDK 自动注入） -
StackTraceHandler中不要用c.Request().Context()取 traceID，要用c.Get("trace_id")，因为 panic 后 request context 可能已被 cancel - 日志库（如 zerolog）要开启
With().Str("trace_id", ...).Logger()，而不是全局 logger，否则并发请求会污染字段
真正难的不是捕获 panic，而是保证从网关到每个服务实例，traceID 的注入、透传、消费三个环节全链路一致。少一个环节，错误就变成无头案。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
