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语言免费学习笔记（深入）”；
仅从仓库的暂存文件生成 Git 提交消息。当用户要求 Codex 根据暂存更改、缓存差异、Git 索引或已通过 `git add` 添加的文件来编写、起草、创建或建议提交消息时使用；切勿代表用户执行提交操作。
- 不要依赖
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()，整个分级逻辑就失效——这不是配置问题，是代码契约问题。
