error 类型不能直接做全局错误分类，因其仅为字符串封装，缺乏状态码、堆栈等元信息，导致日志和HTTP响应无法精准区分错误类型；需自定义错误类型并嵌入标准 error，添加 Code、Message、Detail、Stack 等字段。
为什么 error 类型不能直接做全局错误分类？
Go 的 error 是接口，底层通常只是字符串封装（如 errors.New），没有状态码、层级、堆栈或上下文。直接用它做全局统一处理，会导致日志看不出是数据库超时还是参数校验失败，HTTP 返回也难区分 400 还是 500。
真正可行的做法是：自定义错误类型，嵌入标准 error，再加字段。常见组合包括：
-
Code（int或string，用于映射 HTTP 状态码或业务码） -
Message（面向用户/前端的简明提示） -
Detail（面向开发者的调试信息，含参数、SQL 片段等） -
Stack（可选，用debug.Stack()或第三方库如github.com/pkg/errors捕获）
如何让中间件捕获所有 handler 中的 panic 和 error？
HTTP handler 内部 panic 会终止请求；显式返回 error 则需手动检查。两者都该由统一中间件兜底，避免每个 handler 写重复逻辑。
推荐结构：func Recovery(next http.Handler) http.Handler + func ErrorHandler(next http.Handler) http.Handler 两层协作：
- Recovery 捕获 panic，转成带
Code=500的自定义错误，并记录完整堆栈 - ErrorHandler 接收
context.Context中注入的error（比如通过ctx.Value("err")或更稳妥的middleware.ErrorKey），根据Code决定 HTTP 状态码和响应体 - 务必在
Recovery中调用recover()后清空 panic 状态，否则后续中间件可能失效
怎样把数据库错误、RPC 错误自动转成统一错误类型？
不同依赖库抛出的错误格式差异大：sql.ErrNoRows 是预定义变量，pgx.PgError 有 Code 字段，grpc.Status 需调用 .Err() 才得 Go error —— 不能靠 errors.Is 或 errors.As 一招通吃。
