错误处理的核心理念与目标
在复杂系统中的设计目标
在应用规模不断扩展的场景中，错误清晰传递、可观测性提升、以及故障隔离与快速定位成为错误处理的三大核心目标。本节从设计层面解读如何围绕这些目标组织代码结构、错误类型以及日志策略，以便在上线后仍然具备可维护性与可观测性。
通过在错误传导链中保持一致的语义和上下文，可以让上游业务逻辑在面对失败时做出更合适的应对。一致的错误语义将极大地降低排错时的认知成本，提升开发与运维的协作效率。
使用 errors 包实现错误包装与检测
创建与包装错误
Go 的 errors 包提供了错误创建、包装与判断的能力。通过 包装上下文，可以在返回错误时附加可追溯的信息，同时保持对底层错误的识别能力。
常用模式是定义一个基准错误作为信号，然后在上层用 fmt.Errorf("%w", err) 或其他包装方式注入上下文。这样的设计让后续通过 errors.Is 或 errors.As 进行错误聚合与类型断言成为可能。
package inventoryimport ("errors""fmt"
)var ErrNotFound = errors.New("item not found")type NotFoundError struct{ Item string }func (e *NotFoundError) Error() string { return fmt.Sprintf("not found: %s", e.Item) }func getItem(id string) (string, error) {// 假设查询边界情况if id == "" {return "", ErrNotFound}// 正常返回return "Item-" + id, nil
}func main() {if _, err := getItem(""); err != nil {// 使用包装保持上下文wrapped := fmt.Errorf("inventory.getItem failed: %w", err)// 在日志阶段或返回层传递包装后的错误_ = wrapped}
}
错误对比与断言（Is/As）
借助 errors.Is 可以判断一个错误是否等同于目标错误，errors.As 则可将错误转换为特定的实现类型。这种能力对于统一错误处理策略和对不同异常进行分支处理尤为重要。
package inventoryimport ("errors""fmt"
)func process(id string) error {// 假设调用链中返回了一个包装错误var notFound *NotFoundErrorif errors.As(err, ¬Found) {// 针对 NotFoundError 做特定处理return fmt.Errorf("process: item missing: %s", notFound.Item)}if errors.Is(err, ErrNotFound) {// 统一的外层错误处理return fmt.Errorf("process: not found: %w", err)}return err
}
日志在高效排错中的角色
结构化日志的价值
结构化日志通过键值对的方式承载上下文信息，使机器可解析、人工可读的排错过程变得高效。结构化字段可以让运维系统建立聚合指标、查询错误趋势，快速定位问题点。
在高并发场景中，统一的日志字段规范是实现跨服务、跨语言系统可观测性的基石。通过统一的字段，可对错误来源、影响范围和时间点进行精准分析。
日志与错误上下文结合
把错误信息与上下文日志结合，是提升排错效率的关键。通过在发生错误时附带请求ID、用户ID、操作名等字段，可以在后续排错中快速重建事件轨迹。
package loggerimport ("github.com/sirupsen/logrus"
)var log = logrus.New()func init() {log.Formatter = &logrus.JSONFormatter{}log.Level = logrus.InfoLevel
}func ErrorWithContext(err error, fields logrus.Fields) {entry := log.WithFields(fields)entry.WithError(err).Error("operation failed")
}
将 errors 与日志结合的可观测性方案
日志字段设计
可观测性要求对错误进行量化：错误等级、错误计数、错误分布（来源、服务、实例）。在日志中为每次失败打上唯一的请求ID，并附加上下文字段，确保跨服务追踪的一致性。
除了错误对象本身，日志还应包含 请求路径、参数摘要、耗时、调用栈（必要时）等信息，以帮助定位是业务错误、参数错误还是系统故障。
// 使用 zap 进行结构化日志
package observabilityimport ("go.uber.org/zap"
)var logger, _ = zap.NewProduction()func LogError(ctx map[string]interface{}, err error) {ctx["error"] = err.Error()logger.Error("operation failed", zap.Any("ctx", ctx), zap.String("stack", "%+v"))
}
错误级别、计数、指标
将错误的统计暴露为指标，可以结合 Prometheus 等工具实现可观测性提升。通过对不同错误类型设定计数器、错误率和 Latency 指标，能够及时感知异常趋势。
在代码层面，可以将错误包装与计数器增设绑定：当捕获到特定类型的错误时，记一次计数，并在日志中打上类型标签，便于后续聚合分析。
package metricsimport ("errors""net/http""go.uber.org/zap"
)var (ErrNotFound = errors.New("not found")
)func ObserveError(err error, path string) {if errors.Is(err, ErrNotFound) {// 增加特定错误的监控指标}// 记录日志并暴露指标log.With(zap.String("path", path), zap.String("error", err.Error())).Error("http error")
}
实战演练：一个简单的数据库查询错误处理案例
场景分析
在实际应用中，数据库操作常常返回多种错误，如连接超时、查询无结果、权限不足等。这时需要通过 错误包装与日志上下文来实现高效排错与可观测性提升。
统一的错误语义、清晰的上下文和 结构化日志 将极大缩短故障定位时间，提升系统可维护性。
代码实现
下面的示例展示了一个简单的数据库操作流程，结合 errors 包的包装与日志的结构化输出。
package dbimport ("database/sql""errors""fmt"_ "github.com/go-sql-driver/mysql""github.com/sirupsen/logrus"
)var ErrDBConn = errors.New("db: connection failed")type User struct {ID intName string
}func fetchUserByID(db *sql.DB, id int) (*User, error) {row := db.QueryRow("SELECT id, name FROM users WHERE id = ?", id)var u Userif err := row.Scan(&u.ID, &u.Name); err != nil {if errors.Is(err, sql.ErrNoRows) {return nil, fmt.Errorf("not found: user_id=%d: %w", id, ErrDBConn)}return nil, fmt.Errorf("scan failed: %w", err)}return &u, nil
}func GetUser(db *sql.DB, id int) (*User, error) {u, err := fetchUserByID(db, id)if err != nil {// 放入可观测的日志上下文logrus.WithFields(logrus.Fields{"operation": "GetUser","user_id": id,}).WithError(err).Error("database operation failed")// 继续包装以供上层统一处理return nil, fmt.Errorf("GetUser failed: %w", err)}return u, nil
}
