正确做法是全局统一通过 e.HTTPErrorHandler 处理错误，而非 handler 中直接 c.JSON(500, ...)；必须用 %w 包装 error、自定义错误含 Code/StatusCode 字段、recover 仅防 panic 并转交 HTTPErrorHandler。
为什么不能在 handler 里直接 c.JSON(500, ...)
因为这样会破坏错误传递链，导致中间件无法统一拦截、日志无法结构化、监控指标难以聚合。你写十个 handler，就可能出现十种 500 响应格式；一旦某处漏了 status code，前端可能收到 200 + 错误体，前端逻辑直接错乱。真正的错误出口应该唯一且可控——不是每个 handler 自行决定怎么回，而是由框架层兜底渲染。
e.HTTPErrorHandler 是唯一正确的全局错误入口
它只在 error 未被 handler 主动处理时触发，天然适配 Go 的 error 返回模型。别把它当成“panic 捕获器”，它处理的是 error 类型，包括 *echo.HTTPError 和普通 error。
- 必须在
e := echo.New()后立即设置，否则默认处理器会生效 - 不要在 handler 里调用
panic()再指望它捕获——那是反模式，recover()属于中间件职责 - 若想区分业务错误和系统错误，靠类型断言：
if he, ok := err.(*echo.HTTPError); ok，而不是靠字符串匹配 message - 生产环境对 5xx 错误隐藏原始 message，但务必保留
he.Code和日志中的完整 error chain（用%w包装）
自定义错误类型必须带 Code 和 StatusCode 字段
光实现 Error() 方法没用。前端需要机器可读的错误码做分支，网关需要 StatusCode 做路由重试或熔断，日志系统需要 Code 做聚合告警。硬编码在 Error() 返回值里的文案，只会让日志满屏“invalid email format”，却没法按字段统计或触发钉钉告警。
Echo框架 5.1.0
下载
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
-
Code用 int（如4001），别用字符串，方便下游 switch 或 Prometheus label -
StatusCode对应 HTTP 状态码（400,404,500），和Code分开存，避免语义混淆 - 构造时用
fmt.Errorf("user not found: %w", err)包装底层 error，调用栈不丢 - 在
e.HTTPErrorHandler里根据Code映射前端提示文案，而非从Error()里截取
中间件中 middleware.Recover() 只防崩溃，不处理业务错误
它的作用是捕获空指针、切片越界等 runtime panic，转成 500 响应并记录堆栈。它不会、也不该介入 error 流程。如果你发现 recover 中间件频繁触发，说明有未处理的 panic，不是错误处理逻辑出了问题，而是代码有严重缺陷。
立即学习“go语言免费学习笔记（深入）”；
- 确保
middleware.Recover()在中间件链最外层（通常第一个注册） - recover 捕获后，应把 panic 转为标准
*echo.HTTPError（如echo.NewHTTPError(http.StatusInternalServerError)），再交由e.HTTPErrorHandler渲染 - 不要在 recover 函数里手动调用
c.JSON()，否则绕过全局错误处理器 - 本地开发可开启 debug 模式看原始 panic，但生产环境必须关闭，防止敏感信息泄露
e.HTTPErrorHandler，而是让所有 handler 都遵守“只返回 error，不自行响应”的契约；最容易被忽略的，是忘记用 %w 包装 error，导致日志里只剩最后一层错误，查问题时反复问“这错误到底从哪一层来的”。 
