1. 错误码设计哲学：Go语言中错误码与错误类型的区别，为什么需要领域边界断言
1.1 错误码 vs 错误类型：两种不同的错误表达范式
在 Go 语言中，错误处理的核心机制是 error 接口。然而，在实际工程中，我们常常混淆“错误码”与“错误类型”这两个概念。它们虽然都用于表达错误，但在设计哲学、使用场景和断言方式上存在本质区别。
| 对比维度 | 错误码 (Error Code) | 错误类型 (Error Type) |
|---|---|---|
| 本质 | 预定义的整型或字符串常量，代表特定错误语义 | 实现了 error 接口的自定义结构体，可携带额外上下文 |
| 断言方式 | 通过值比较（==）或 switch 匹配 |
通过类型断言（errors.As）或类型 switch |
| 可扩展性 | 弱：新增错误码需修改全局常量定义 | 强：可嵌套、可包装、可携带字段 |
| 序列化友好度 | 高：适合跨服务传递（HTTP/gRPC） | 低：跨边界传递时需额外序列化逻辑 |
| Go 惯用风格 | 标准库 io.EOF、syscall.Errno |
自定义业务错误，如 *os.PathError |
核心区别总结：错误码是“值语义”，适合在系统边界（如 API 网关、RPC 调用）做精确匹配；错误类型是“类型语义”，适合在模块内部传递结构化错误信息。
1.2 为什么需要领域边界断言
在大型 Go 项目中，错误会跨越多个层级：存储层 → 业务层 → 接口层。每一层对错误的关注点不同：
- 存储层：关心“数据库连接失败”还是“记录不存在”。
- 业务层：关心“用户余额不足”还是“订单已取消”。
- 接口层：关心“返回 HTTP 400”还是“返回 HTTP 500”。
如果整个系统只使用一种错误表达方式，会导致两个问题：
- 耦合过紧：业务层直接依赖存储层的错误类型，存储层变更（如从 MySQL 换为 Redis）会波及上层。
- 断言混乱：调用方无法确定应该用
==比较还是用errors.As断言。
领域边界断言的核心思想是：在每一层边界处，将错误从一种形式转换为另一种形式，并只暴露该层约定的错误断言方式。
实践原则：在模块内部使用错误类型（类型断言），在模块边界使用错误码（值断言）。边界断言是解耦的关键。
1.3 错误断言方式对比
| 断言方式 | 适用场景 | 代码示例 | 风险 |
|---|---|---|---|
== 值比较 |
哨兵错误（sentinel error） | if err == io.EOF |
无法携带上下文 |
errors.Is |
包装后的哨兵错误 | if errors.Is(err, io.EOF) |
需定义全局哨兵 |
errors.As |
自定义错误类型 | var e *MyError; errors.As(err, &e) |
类型暴露给调用方 |
switch 类型断言 |
多分支错误处理 | switch e := err.(type) |
需知道所有子类型 |
1.4 错误码与错误类型的边界转换模型
下图展示了在典型的三层架构中，错误码与错误类型如何在不同边界处转换：
1.5 代码示例：边界断言实战
以下代码展示了在存储层与业务层边界处，如何将错误类型转换为错误码：
// 存储层：定义错误类型
type DBError struct {
Op string
Err error
}
func (e *DBError) Error() string {
return e.Op + ": " + e.Err.Error()
}
// 业务层：定义错误码
const (
ErrUserNotFound = "USER_NOT_FOUND"
ErrDBConnection = "DB_CONNECTION_FAILED"
)
// 边界断言函数：存储层 → 业务层
func mapDBError(err error) error {
var dbErr *DBError
if errors.As(err, &dbErr) {
switch dbErr.Op {
case "findUser":
return ErrUserNotFound
case "connect":
return ErrDBConnection
}
}
return err // 未知错误透传
}
// 业务层使用
func GetUser(id string) (*User, error) {
user, err := db.FindUser(id)
if err != nil {
return nil, mapDBError(err) // 边界断言
}
return user, nil
}
// 调用方断言
user, err := GetUser("123")
if errors.Is(err, ErrUserNotFound) {
// 精确处理用户不存在
}
常见陷阱：不要在业务层直接断言存储层的错误类型（如
errors.As(err, &*DBError{})），这会导致业务层与存储层强耦合。始终通过边界断言函数进行转换。
1.6 错误码设计原则
- 扁平化：错误码使用常量字符串，避免层级过深。
- 可读性：错误码名称应自描述，如
ErrOrderExpired优于ErrCode1001。 - 唯一性：全局唯一，避免不同模块定义相同值的错误码。
- 可枚举：所有错误码集中定义，便于文档生成和测试覆盖。
- 不可包装：错误码本身不携带动态上下文，上下文通过日志或额外字段传递。