Go错误处理新提案：错误值与错误检查机制解读

如果说Go语言中最容易引发“血案”的特性是什么，错误处理绝对榜上有名。从早期教科书式的 `if err != nil`，到后来 `fmt.Errorf` 与 `%w` 的引入，围绕错误处理的讨论几乎贯穿了Go 2的整个演进而程。最近，一份被社区频繁提及的新提案再度把两个核心概念推向台前——错误值（error values）与错误检查机制（error checking）。这并非全新的发明，但它的落地思路，或许能让大家重新审视Go错误处理的未来。

错误值：让错误真正地“可结构化”

过去大部分Go代码中的错误，本质上是一个带着一串字符串的 `error` 接口。字符串固然便于阅读，却难以被程序逻辑识别和归类。于是我们有了 `errors.Is` 和 `errors.As`，它们通过递归拆解 `Unwrap`，让错误之间具备了比较和类型转换的能力。但这份能力依然有限：想要附加字段、堆栈、上下文甚至结构化日志信息，仍然缺乏“标准姿势”。

新提案的“错误值”部分，试图把一个错误从一张“纸条”变成一个真正有“结构”的值。它不要求推翻 `error` 接口，而是在其上鼓励使用一种更丰富的错误类型，比如：

type structuredError struct {
    code     int
    kind     string
    location string
    cause    error
    payload  map[string]any
}

于是，错误在传播过程中，可以携带用户关心的元数据。比如网络超时、存储故障、参数校验失败，这些并不是不同种类的错误，而是同一个错误在不同上下文中表现出来的不同侧面。提案中的关键变化在于：错误不再强迫你把所有信息都粉饰进一条字符串，而是用一套标准接口，让错误既能容纳丰富语义，又能保持与既有 `errors.Is` / `errors.As` 的兼容。

这种改进的价值非常直观。当OOM、面板报错、监控系统在追踪一个失败请求时，看到的会是一条带完整路径的“错误链”，而不是几行蹩脚的拼接文本。**错误值增强的终极目标，是让错误检查变得不仅仅依赖人的经验，也让机器可理解。**

错误检查机制：语法糖还是思维转变？

有了更丰富的错误值，还需要一种更省心的检查方式，否则样板代码依旧让人眼睛发酸。提案中设想的“错误检查机制”，核心思路是引入一种在函数内部可复用的错误处理流程，例如 `check`与`handle`。理想状态下，代码可以这样写：

handle err {
    if errors.Is(err, ErrNotFound) {
        return zero, err
    }
    return zero, fmt.Errorf("handle user: %w", err)
}

data := check sensitiveCall()   // 出错则跳转到上面的handle块
log.Println(data)

这显然比连续手写三个 `if err != nil` 要干净。并且它不是Go里常见的全局异常，而是把错误导向一个局部处理块。这个设计保留了“显式错误传播”的直觉——调用处依然能看见出错的可能性，只是用关键字把“分支是否收缩”的重复工作交给了语言。

但作为一种控制流，它同时也引入一个新的认知成本：`check`之后如果出错，程序会去哪里？如果函数有多个 `handle`，错误会与哪一块匹配？在这些机制缺失设计细节的情况下，很容易造成阅读时的跳跃感。因此，回顾Go人过往对 `check/handle` 的争论就会发现：压倒性的反对意见，并不是因为它“做错了”，而是因为它并未显著简化复杂场景，反而给简单场景增加了额外的规则。

新提案的正确姿势：保守与增量的平衡

综合来看，错误值部分的演进是业界共识，甚至可以说已经“在路上”。相较之下，错误检查机制仍需要更多探索。我认为未来真正能被采用的，大概率不是激进的新关键字，而是基于现有语法、只做局部增强的