在Golang项目开发中，错误日志是排查问题、监控系统健康状态的核心依据，但如果没有对错误进行分级，所有错误都混在一起输出，会给问题定位带来极大困扰。比如用户登录时密码错误的普通业务错误，和数据库主库宕机的严重错误如果被同等记录，运维人员很难快速从海量日志中筛选出需要紧急处理的问题。
错误日志分级的核心定义与场景划分
要实现错误日志分级，首先需要明确不同错误级别的定义和对应的触发场景，避免分级标准模糊导致后续使用混乱。通常我们可以将错误分为三个核心级别：普通错误（Info/Error级别中的非致命类）、警告错误（Warn级别）、严重错误（Fatal/Panic级别），其中普通错误和严重错误是最需要明确区分的两类。普通错误的特点是不会影响当前请求的正常返回，也不会导致服务整体不可用，比如接口入参校验不通过、调用第三方服务的非核心接口返回异常、缓存查询未命中这类场景，这类错误的发生频率可能较高，但不需要人工立即介入，只需要记录日志方便后续统计和优化即可。
严重错误则完全不同，这类错误的发生会直接影响服务的核心功能，甚至导致服务崩溃。比如服务启动时读取核心配置文件失败、数据库连接池耗尽且无法恢复、消息队列核心消费者组异常退出、关键业务逻辑中出现空指针导致进程panic等场景，都属于严重错误。这类错误的发生概率通常较低，但一旦发生就需要第一时间触发告警，通知相关人员介入处理，否则会造成业务损失。明确这两类错误的边界是后续实现分级功能的基础，我们可以根据业务特性进一步细化，比如电商系统可以把订单支付失败归为普通错误，把支付通道全部不可用归为严重错误。
除了场景划分，还需要考虑分级后的日志输出规范。普通错误通常只需要输出错误描述、请求上下文（比如请求ID、用户ID、接口路径）即可，不需要额外的告警动作；严重错误除了输出完整的上下文信息，还需要附带堆栈信息，方便快速定位错误发生的代码位置，同时可以触发短信、电话、企业微信等告警渠道。如果分级标准不统一，比如有的开发者把普通参数错误标记为严重错误，就会导致告警风暴，让运维人员对真正的严重错误脱敏，反而失去了分级的意义。
基于自定义错误类型的分级实现方案
在Golang中实现错误分级，最灵活的方式是自定义错误类型，给错误附加级别属性。首先我们可以定义错误级别的常量和错误接口，让自定义错误类型实现标准的error接口，同时携带级别、错误码、上下文信息等字段。比如先定义级别常量：普通错误对应级别1，严重错误对应级别3，中间可以增加警告级别对应级别2，方便后续扩展。然后定义自定义错误结构体，包含级别字段、错误描述字段、错误发生的时间和堆栈信息，堆栈信息可以通过runtime包在错误创建时自动捕获，避免手动传递堆栈的麻烦。
接下来我们可以封装创建不同级别错误的方法，比如NewNormalError用于创建普通错误，NewFatalError用于创建严重错误。这两个方法内部会自动设置错误的级别，并且捕获当前的堆栈信息存储到错误结构体中。当需要返回错误时，直接调用对应的方法即可，不需要在每个返回错误的地方手动标记级别。比如参数校验失败时，调用NewNormalError("参数校验失败: 用户ID不能为空")，数据库查询失败时如果是连接问题则调用NewFatalError("数据库连接失败: " + err.Error())。这种方式的好处是错误本身携带了级别信息，后续日志输出时可以直接从错误对象中提取级别，不需要额外的判断逻辑。
下面是一个简单的自定义错误类型实现示例：
package errs
import (
"fmt"
"runtime/debug"
"time"
)
// 错误级别常量
const (
LevelNormal = 1 // 普通错误
LevelWarn = 2 // 警告错误
LevelFatal = 3 // 严重错误
)
// 自定义错误结构体
type AppError struct {
Level int // 错误级别
Code int // 业务错误码
Message string // 错误描述
Time time.Time // 错误发生时间
StackTrace []byte // 堆栈信息
}
// 实现error接口的Error方法
func (e *AppError) Error() string {
return fmt.Sprintf("level: %d, code: %d, message: %s, time: %s", e.Level, e.Code, e.Message, e.Time.Format("2006-01-02 15:04:05"))
}
// 创建普通错误
func NewNormalError(code int, message string) *AppError {
return &AppError{
Level: LevelNormal,
Code: code,
Message: message,
Time: time.Now(),
StackTrace: debug.Stack(),
}
}
// 创建严重错误
func NewFatalError(code int, message string) *AppError {
return &AppError{
Level: LevelFatal,
Code: code,
Message: message,
Time: time.Now(),
StackTrace: debug.Stack(),
}
}
上面的代码中，debug.Stack()会自动获取当前goroutine的堆栈信息，存储到错误的StackTrace字段中，后续日志输出时如果需要可以打印堆栈。需要注意的是，debug.Stack()会有一定的性能开销，如果普通错误的发生频率非常高，可以考虑只在严重错误中捕获堆栈，普通错误只记录基础信息，避免影响服务性能。
结合日志库实现分级输出与告警
定义好带级别的错误类型后，还需要结合日志库实现分级的输出和告警逻辑。Golang常用的日志库比如zap、logrus都支持自定义日志级别和钩子功能，我们可以基于这些能力做适配。以zap日志库为例，zap本身自带Debug、Info、Warn、Error、DPanic、Panic、Fatal等级别，我们可以将自定义的错误级别和zap的日志级别做映射：普通错误对应zap的Error级别，严重错误对应zap的Fatal或者DPanic级别，这样不需要修改日志库的核心逻辑，只需要做一层映射即可。
我们可以封装一个统一的日志输出方法，接收错误对象和额外的上下文字段，方法内部先判断错误的级别，然后调用对应的zap日志方法输出。如果是严重错误，除了输出日志，还可以调用告警方法，比如发送企业微信消息。下面是一个结合zap的实现示例：
package log
import (
"go.uber.org/zap"
"go.uber.org/zap/zapcore"
"your_project/errs"
)
var logger *zap.Logger
// 初始化日志实例
func InitLogger() {
// 配置日志输出格式，包含时间、级别、消息、堆栈等
config := zap.NewProductionConfig()
config.EncoderConfig.TimeKey = "time"
config.EncoderConfig.LevelKey = "level"
config.EncoderConfig.MessageKey = "message"
config.EncoderConfig.StacktraceKey = "stacktrace"
logger, _ = config.Build()
}
// 输出错误日志，根据错误级别做不同处理
func LogError(err error, fields ...zapcore.Field) {
if appErr, ok := err.(*errs.AppError); ok {
// 是自定义错误，根据级别处理
switch appErr.Level {
case errs.LevelNormal:
// 普通错误，输出Error级别日志，不触发告警
logger.Error(appErr.Message, append(fields, zap.Int("err_code", appErr.Code), zap.String("err_time", appErr.Time.Format("2006-01-02 15:04:05")))...)
case errs.LevelFatal:
// 严重错误，输出Fatal级别日志，同时触发告警
logger.Fatal(appErr.Message, append(fields, zap.Int("err_code", appErr.Code), zap.String("err_time", appErr.Time.Format("2006-01-02 15:04:05")), zap.String("stack", string(appErr.StackTrace)))...)
// 这里可以添加告警逻辑，比如调用企业微信机器人发送消息
// sendAlert(appErr.Message, appErr.Code)
}
} else {
// 非自定义错误，默认按普通错误输出
logger.Error(err.Error(), fields...)
}
}
在实际使用中，当业务代码返回错误时，直接调用log.LogError(err, zap.String("request_id", requestID))即可，方法内部会自动根据错误的级别做对应的处理。如果使用的是logrus日志库，也可以通过添加Hook的方式实现类似的逻辑：给logrus注册一个Hook，在Hook中判断日志级别，如果是严重错误对应的级别，就触发告警动作。这种方式的扩展性很好，后续如果需要增加错误上报到监控系统、错误持久化到数据库等需求，只需要在LogError方法中添加对应的逻辑即可，不需要修改业务代码中的错误返回逻辑。
另外需要注意日志的输出格式统一，所有错误日志最好包含统一的字段，比如请求ID、用户ID、错误级别、错误码、错误描述、发生时间，这样后续做日志检索和分析时会非常方便。如果是微服务架构，还可以把错误级别字段上报到链路追踪系统，方便跨服务排查问题时快速定位严重错误的传播路径。对于严重错误的堆栈信息，建议只在开发环境和测试环境完整输出，生产环境可以根据需要脱敏，避免堆栈信息暴露敏感的业务逻辑。
分级实现的注意事项与优化方向
在实现错误日志分级时，有几个常见的坑需要避免。首先是不要过度分级，有些项目会把错误分成五六级甚至更多，反而增加了使用复杂度，通常普通、警告、严重三级就足够大部分项目使用，过多的级别会让开发者不知道该给错误标哪个级别，最终导致分级形同虚设。其次是不要忽略错误的级别传递，比如A函数调用B函数，B函数返回了一个严重错误，A函数如果捕获后没有重新抛出或者标记级别，直接返回一个新的普通错误，就会导致严重错误的级别丢失，后续日志输出时无法识别。
性能方面也需要考虑，尤其是高并发的服务，如果每次创建错误都捕获堆栈，会增加CPU和内存开销。可以优化为只有严重错误才捕获堆栈，普通错误只记录基础信息，或者在初始化日志的时候配置堆栈捕获的开关，生产环境关闭普通错误的堆栈捕获。另外，错误级别的定义最好做成可配置的，比如通过配置文件修改普通错误和严重错误的判断阈值，不需要修改代码就可以调整分级策略，比如某个业务场景下，原来认为是普通错误的库存不足，在大促期间可以临时调整为警告错误，触发库存预警。
后续还可以结合日志分析系统做更多扩展，比如统计不同级别错误的发生频率，设置严重错误的告警阈值，比如1分钟内出现3次严重错误就触发电话告警，避免单个偶发的严重错误造成不必要的打扰。也可以给不同级别的错误设置不同的日志保留策略，普通错误保留7天，严重错误保留30天甚至更久，方便后续做问题复盘。错误日志分级不是一次性的工作，需要根据业务的发展不断调整优化，才能真正发挥它的价值，让日志成为系统稳定运行的保障。