Go 中 error 接口不带错误码，需用结构体封装并实现 Error() 和 Unwrap() 方法以支持 errors.Is/As；Code 应用常量定义，HTTP 响应和日志需统一处理错误码与原始错误。
Go 中 error 接口本身不带错误码，必须自己封装
Go 标准库的 error 是个只含 Error() string 方法的接口，天然不支持错误码。想结合错误码（如 400、5001、ErrUserNotFound），就得定义自己的错误类型——通常用结构体实现 error 接口，并嵌入码字段。
常见错误是直接用 fmt.Errorf("code=400: %w", err) 拼字符串，导致无法程序化判断码值、无法提取原始错误、也无法加额外上下文（如 trace ID）。这类错误在 HTTP handler 或 RPC 返回时尤其难处理。
- 推荐用结构体封装：
type AppError struct { Code int; Msg string; Err error } -
Code字段建议用常量定义（如const ErrInvalidParam = 4001），避免魔法数字散落各处 - 实现
Error()方法时，优先返回用户友好的Msg，而非拼接底层Err.Error()（除非调试需要） - 如果需保留原始错误链，用
Unwrap()方法返回e.Err，以便errors.Is()和errors.As()正常工作
如何让自定义 error 支持 errors.Is / errors.As
Go 1.13 引入的 errors.Is 和 errors.As 依赖错误链的 Unwrap() 方法。若你的 AppError 不实现它，或实现错误（比如返回 nil 而非底层 Err），上层就无法用 errors.Is(err, ErrInvalidParam) 判断，只能靠字符串匹配或类型断言，极不可靠。
type AppError struct {
Code int
Msg string
Err error
}
func (e *AppError) Error() string { return e.Msg }
func (e *AppError) Unwrap() error { return e.Err }
注意：Unwrap() 必须返回 error 类型，不能是 *AppError 或其他非 error 值；如果 e.Err 为 nil，应返回 nil，否则 errors.Is 可能 panic。
立即学习“go语言免费学习笔记（深入）”；
- 使用
errors.As(err, &target)提取自定义 error 时，target必须是指针（如*AppError） - 多个嵌套
AppError时，Unwrap()应逐层返回，不要跳过中间层 - 不要在
Unwrap()里做日志、panic 或修改状态——它只负责“解包”
HTTP handler 中如何统一返回带码 error
Web 服务中，错误码最终要映射为 HTTP 状态码和 JSON 响应体。直接在每个 handler 里写 if err != nil { w.WriteHeader(400); json.NewEncoder(w).Encode(...) } 会重复且易漏。更可靠的做法是：用中间件捕获 panic 和返回的 error，再根据其是否实现了 StatusCode() int 或类似方法来决定响应码。
- 给
AppError加个方法：func (e *AppError) StatusCode() int { return e.Code }（注意：这不是标准接口，只是约定） - 中间件中用
errors.As(err, &appErr)尝试转换，成功则调用appErr.StatusCode()，失败则默认用500 - 避免把数据库错误（如
sql.ErrNoRows）直接透传给前端——应转成语义明确的业务错误码，比如ErrUserNotFound = 40401 - 日志记录时，同时打
err.Code和err.Error()，方便 ELK 搜索和监控告警
error 包装时别丢掉原始错误码
用 fmt.Errorf("failed to parse config: %w", err) 包装错误很常见，但如果 err 是 *AppError，这样包装后，新 error 就丢失了 Code 字段——因为 %w 只保留 Unwrap() 链，不复制自定义字段。
正确做法是显式构造新 *AppError，并把原 Code 传递下去：
if errors.As(err, &appErr) {
return &AppError{
Code: appErr.Code, // 保留原码
Msg: "config load failed: " + appErr.Msg,
Err: err,
}
}
- 不要依赖
fmt.Errorf(... %w)自动继承码值——它做不到 - 如果原错误没有码（比如标准库 error），新 error 的
Code应设为通用码（如50000）并加注释说明原因 - 在单元测试中，务必验证包装后的 error 是否仍可通过
errors.Is匹配原始码常量
最常被忽略的是：错误码的语义一致性。同一个业务含义（如“用户不存在”）在不同模块里用了不同码值，或者一个码被复用于多个含义，后期排查和前端处理都会混乱。定义码时最好配上简短注释，并集中放在一个 errors.go 文件里。
