go语言错误分级需自定义leveledError类型封装level字段，提供ErrDebug/ErrWarn/ErrError/ErrFatal等构造函数，统一在入口处按Level分发处理，确保级别由错误产生方决定。
Go 语言本身没有内置的“错误级别”（如 debug/warn/error/fatal）概念，error 接口只关心“是否出错”，不区分轻重。但实际工程中，我们常需按严重程度分类处理错误——比如日志记录、告警触发、降级策略或用户提示。要实现错误分级，核心思路是：在 error 值中携带级别信息，并配套统一的错误构造、检查和处理机制。
定义错误级别枚举与带级别的错误类型
用自定义类型封装 error，并嵌入 level 字段。推荐使用 iota 定义清晰的级别常量：
type Level int const ( LevelDebug Level = iota LevelInfo LevelWarn LevelError LevelFatal ) type leveledError struct { err error level Level msg string } func (e *leveledError) Error() string { if e.msg != "" { return e.msg } return e.err.Error() } func (e *leveledError) Unwrap() error { return e.err } func (e *leveledError) Level() Level { return e.level }
这样既兼容 errors.Is/As，又可通过 Level() 方法获取级别。
提供语义化错误构造函数
避免直接 new(leveledError)，而是封装一组工厂函数，让调用方意图明确：
-
ErrDebug(err, msg)：用于诊断性错误，通常不暴露给用户 -
ErrWarn(err, msg)：异常但可恢复，如缓存失效、重试成功 -
ErrError(err, msg)：标准业务/系统错误，需记录并通知 -
ErrFatal(err, msg)：不可恢复，应中止当前流程（如初始化失败）
示例：
func ErrWarn(err error, msg string) error { return &leveledError{err: err, level: LevelWarn, msg: msg} } // 使用 if val, ok := cache.Get(key); !ok { return ErrWarn(ErrCacheMiss, "cache key not found, falling back to DB") }
统一错误处理与分发逻辑
在入口（如 http handler、CLI 命令执行、goroutine 主循环）做一次集中处理：
- 用 errors.As 提取 leveledError
- 按 Level 调用不同日志器（zap.With().Warn()/Error()）
- LevelFatal 触发 os.Exit(1) 或 panic（谨慎）
- LevelWarn 可跳过用户错误提示，仅记日志
- LevelError 返回给前端时，可映射为特定 HTTP 状态码或错误码
关键不是“捕获所有错误”，而是“识别关键级别并响应”。不要在每层都判断 level，只在决策点（如 API 层、任务调度层）做一次分发。
与标准库和生态工具协同
保持与 errors 包兼容：
- 支持
errors.Is(err, someErr)（通过 Unwrap） - 支持
errors.As(err, &target)（target 是 *leveledError） - 日志库（如 zap）可写一个
leveledErrorHook自动提取 level 写入字段 - 监控系统（如 prometheus）可基于 level 标签统计错误率
不建议包装 context.DeadlineExceeded 等底层错误——它们已有明确语义，强行升级 level 反而失真。分级应聚焦在业务逻辑层的错误归因上。
基本上就这些。Go 的错误分级不是加个字段就完事，关键是建立从构造 → 传递 → 判断 → 响应的闭环。不复杂但容易忽略的是：**级别必须由产生错误的一方决定，而非下游随意 reinterpret**。