如何在Golang中实现基于错误级别的处理_Golang错误级别控制与处理方式

go错误无内置级别，需自定义类型或用xErrors/pkg/errors包装，结合errors.Is/As分类；日志分级应由slog.Handler等根据错误类型判断，而非错误自身携带级别字段。

Go 里没有内置的错误级别（如 ERROR/WARN/INFO）

Go 的 error 接口本身只定义了一个 Error() 方法，不携带任何级别、时间、上下文等元信息。所谓“错误级别控制”，必须由开发者自行建模——要么扩展 error 实现，要么用结构体封装，再配合判断逻辑分发处理。

常见误操作是试图给 errors.New("xxx") 或 fmt.Errorf("xxx") “打标签”或“设级别”，这在类型层面完全无效：它们返回的是基础 error，无法区分严重性。

• 真正可用的方式是自定义错误类型，例如实现 type MyError Struct { Level String; Msg string; Err error }
• 更推荐使用已验证的库如 github.com/pkg/errors（虽已归档，但语义清晰）或 golang.org/x/xerrors（官方轻量方案），它们支持带堆栈和简单分类，但依然不提供开箱即用的“级别字段”
• 若需日志分级，应把错误实例传给日志器（如 log/slog），由日志器根据错误类型或包装特征决定输出级别，而非让错误自己“说它是 warn”

用 slog.With 与自定义 error 类型联动做分级处理

Go 1.21+ 的 slog 支持结构化日志，可将错误类型作为属性传入，再结合 slog.Handler 的自定义逻辑做路由。例如：

type LevelError struct { 	Level string 	Msg   string 	Err   error }  func (e *LevelError) Error() string { return e.Msg } func (e *LevelError) Unwrap() error { return e.Err }  // 使用时： slog.Error("db query failed", "err", &LevelError{Level: "ERROR", Msg: "timeout", Err: ctx.Err()})

关键点在于：slog 不会自动识别 LevelError.Level，你需要写一个自定义 slog.Handler，在 Handle() 方法中检查 record.Attrs() 里的 err 是否为 *LevelError，再根据其 Level 字段决定是否写入 stderr、是否上报 sentry 等。

立即学习“go语言免费学习笔记（深入）”；

• 不要依赖 fmt.printf("%+v", err) 来提取级别——它只是字符串展开，不可靠
• 避免在 Error() 方法里拼接级别前缀（如 "[ERROR] " + e.Msg），这会让错误消息变脏，且无法被结构化解析
• 如果用第三方日志库（如 zerolog、zap），它们通常自带 ErrLevel() 或 WithLevel()，但底层仍需你把错误转成对应类型

panic / recover 不等于 ERROR 级别，而是控制流中断

很多开发者误以为 panic 是“最高级别错误”，于是用它处理业务异常（如参数校验失败、http 400）。这是严重误区：panic 本质是终止当前 goroutine 并展开栈，开销大、不可预测，且无法被常规 error 处理链捕获。

• 仅当程序处于不可恢复状态时才用 panic：比如配置加载失败导致服务根本无法启动、全局单例初始化失败
• HTTP handler 中遇到用户输入错误，应返回 400 Bad Request + 普通 error，而不是 panic；否则可能触发整个服务重启或掩盖真实问题
• recover() 只应在顶层中间件或 goroutine 起始处谨慎使用，且恢复后应记录日志并返回明确错误，不能静默吞掉 panic

error wrapping 与 is/as 判断是分级决策的基础

Go 1.13 引入的 errors.Is() 和 errors.As() 是做错误分类的事实标准。比如你想把所有数据库超时统一按 “ERROR” 处理，而连接拒绝按 “WARN” 降级重试：

if errors.Is(err, context.DeadlineExceeded) {     slog.Error("db timeout", "err", err)     return } if errors.As(err, &pqErr) && pqErr.Code == "08006" { // connection refused     slog.Warn("db conn refused, retrying...", "err", err)     return }

这里的关键不是“给错误贴标签”，而是利用 Go 错误生态的两个事实：

• 标准库和主流驱动（database/sql, lib/pq, pgx）都正确实现了 Unwrap() 和类型断言支持
• errors.Is() 会递归检查整个错误链，errors.As() 能精准匹配底层具体类型，这才是可靠分级的依据
• 自己写的错误包装器必须实现 Unwrap() 方法，否则 Is/As 无法穿透

最容易被忽略的是：错误链越深，Unwrap() 实现越容易出错；一旦漏掉某一层的 Unwrap()，整个分级逻辑就失效——这不是配置问题，是代码契约问题。