error 类型不能直接做全局错误分类，因其仅为字符串封装，缺乏状态码、堆栈等元信息，导致日志和HTTP响应无法精准区分错误类型；需自定义错误类型并嵌入标准 error，添加 Code、Message、Detail、Stack 等字段。
为什么
类型不能直接做全局错误分类？
Go 的
是接口，底层通常只是字符串封装（如
），没有
状态码
、层级、堆栈或上下文。直接用它做全局统一处理，会导致日志看不出是数据库超时还是参数校验失败，HTTP 返回也难区分 400 还是 500。
真正可行的做法是：自定义错误类型，嵌入标准
，再加字段。常见组合包括：
（
或
，用于映射 HTTP 状态码或业务码）
（面向用户/
前端
的简明提示）
（面向开发者的调试信息，含参数、SQL 片段等）
（可选，用
或第三方库如
捕获）
如何让中间件捕获所有 handler 中的 panic 和 error？
HTTP handler 内部 panic 会终止请求；显式返回
则需手动检查。两者都该由统一中间件兜底，避免每个 handler 写重复逻辑。
推荐结构：
+
两层协作：
立即学习
“
go语言免费学习笔记（深入）
”；
Recovery 捕获 panic，转成带
的自定义错误，并记录完整堆栈
ErrorHandler 接收
中注入的
（比如通过
或更稳妥的
），根据
决定 HTTP 状态码和响应体
务必在
中调用
后清空 panic 状态，否则后续中间件可能失效
怎样把数据库错误、RPC 错误自动转成统一错误类型？
不同依赖库抛出的错误格式差异大：
是预定义变量，
有
字段，
需调用
才得 Go error —— 不能靠
或
一招通吃。
Git
程序猿必备版本控制工具
下载
实操建议：
对每个外部依赖，写一个薄封装函数，例如
，内部判断
→
，
→
避免在 DAO 层直接返回原始
，一律过一遍包装函数
对 gRPC 客户端，用
提取
和
，再映射到你的
日志、监控、告警怎么和错误类型联动？
只定义错误类型没用，关键在消费端是否识别。比如 Sentry 上报时若只传
，就丢失了
和
；Prometheus 计数器若按
分组，会导致相同错误因参数不同被拆成几十个指标。
必须做到：
日志库（如
）写日志时，显式添加
、
Prometheus counter 标签用
而非完整错误文本：
Sentry 的
前，用
注入
和
作为 extra context
最容易被忽略的是：HTTP handler 中返回错误后，仍要主动调用日志记录 —— 中间件里的 ErrorHandler 只负责响应，不负责打点；否则错误进了监控但没留痕，排查时找不到原始上下文。
errorerrorerrors.NewerrorCodeintstringMessageDetailStackdebug.Stack()github.com/pkg/errorserrorfunc Recovery(next http.Handler) http.Handlerfunc ErrorHandler(next http.Handler) http.HandlerCode=500context.Contexterrorctx.Value("err")middleware.ErrorKeyCodeRecoveryrecover()sql.ErrNoRowspgx.PgErrorCodegrpc.Status.Err()errors.Iserrors.AsWrapDBError(err error) *AppErrorerrors.Is(err, sql.ErrNoRows)Code=404strings.Contains(err.Error(), "timeout")Code=503errorstatus.Convert(err)Code()Message()AppError.Codeerr.Error()CodeDetailerr.Error()zerolog.Int("code", err.Code).Str("detail", err.Detail)codeerrorsTotal.WithLabelValues(strconv.Itoa(err.Code))sentry.CaptureException()sentry.WithScope()CodeDetail