1. 错误码设计哲学：为什么需要错误码、错误码与异常的区别、Go语言错误处理哲学

1.1 为什么需要错误码

在软件系统中，错误码是错误信息的结构化载体。它用预定义的数值或短标识符，将运行时发生的故障映射为可枚举、可传递、可处理的信号。错误码的存在并非偶然，而是工程实践对以下核心需求的回应：

• 可枚举性：所有已知错误类型被显式定义，避免“魔法字符串”或未文档化的错误传播。
• 可传递性：错误码可以在不同层（网络、进程、模块）之间无损传递，不受语言或序列化格式限制。
• 可处理性：调用方通过检查错误码，能够做出确定性决策（重试、降级、告警、终止）。
• 可观测性：日志、监控、告警系统依赖错误码进行聚合、统计与根因分析。

1.2 错误码与异常的区别

错误码与异常是两种截然不同的错误传播机制。下表从多个维度对比其本质差异：

1.3 Go语言错误处理哲学

Go语言的设计者明确选择了错误码范式，而非异常机制。其核心哲学可以概括为以下三点：

1. 错误是值（Errors are values）：错误与普通返回值地位相同，没有特殊的语法结构。函数通过返回 error 接口类型来表达失败。
2. 显式处理优于隐式传播：调用方必须检查错误，不能“假装错误不存在”。这种设计迫使开发者直面错误，减少未处理异常导致的隐蔽故障。
3. 错误信息应包含上下文：Go鼓励通过 fmt.Errorf("operation %s failed: %w", name, err) 包装错误，形成错误链，保留根因的同时附加当前层信息。

以下代码展示了Go中典型的错误处理模式：

// 打开文件，如果失败则返回包装后的错误
func ReadConfig(path string) ([]byte, error) {
    f, err := os.Open(path)
    if err != nil {
        // 包装错误，附加上下文
        return nil, fmt.Errorf("read config: %w", err)
    }
    defer f.Close()

    data, err := io.ReadAll(f)
    if err != nil {
        return nil, fmt.Errorf("read config content: %w", err)
    }
    return data, nil
}

// 调用方必须检查错误
data, err := ReadConfig("/etc/app.conf")
if err != nil {
    // 显式处理：记录日志、返回上层、或重试
    log.Printf("failed to load config: %v", err)
    return
}
// 正常使用 data

下图展示了Go错误处理哲学中“错误作为值”与“显式处理”的流程关系：

1.4 错误码在Go中的落地形态

Go标准库和社区实践形成了三种主要的错误码表达方式：