在 Go 语言的设计哲学中，“Errors are values”并不是一句宣传口号，而是对类型系统与函数调用契约的严格定义。它意味着错误本身也是函数正常返回结果的一部分，和整型、字符串、结构体没有地位上的差别。调用方拿到返回值后，需要自行判断错误值是否为空，从而决定后续逻辑。这种模型把控制流的主动权交还给开发者，而不是由运行时通过栈展开强行跳转。
一、“Errors are values”的底层语义
Go 的错误处理建立在多返回值的语法基础上。一个函数可以返回（结果，error），其中 error 是一个内建的接口类型。只要某个类型实现了 Error() string 方法，它就能作为错误传递。从编译器视角看，error 和 int 一样，都是普通的参数或局部变量，不存在专门的异常寄存器或隐式跳转指令。
这种一致性带来一个直接后果：错误不会自动向上冒泡。你必须把 error 作为值接收，再决定是返回给上层还是就地处理。下面这段代码展示了最基础的写法：
package main
import (
"errors"
"fmt"
)
func divide(a, b float64) (float64, error) {
if b == 0 {
return 0, errors.New("division by zero")
}
return a / b, nil
}
func main() {
result, err := divide(10, 0)
if err != nil {
fmt.Println("error:", err)
return
}
fmt.Println("result:", result)
}
在上面的示例中，err 和 result 都来自同一函数调用。编译器不会在 err 不为空时做任何特殊动作，它只是把你写的 if err != nil 编译成普通的条件分支。这就是“错误即值”最直白的表达：没有魔法，只有显式。
二、与异常模型的逻辑差异
在 Java 或 Python 这类使用异常的语言里，错误会通过 throw 中断当前执行流，并沿着调用栈向上寻找 catch 块。这种方式看似简洁，却引入了隐式控制流：读代码时你无法仅看函数签名就确定它会不会“跳走”。Go 的值模型则把所有可能的退出路径都摊开在返回值里。
我们可以用一张简表对比两种模型在可读性与可预测性上的区别：
| 维度 | 异常模型 | Errors are values |
|---|---|---|
| 控制流可见性 | 需阅读文档或源码才知道可能抛错 | 函数签名已声明，编译期强制检查 |
| 性能开销 | 栈展开代价高 | 仅普通返回值传递，几乎无额外成本 |
| 错误处理位置 | 可跨多层统一捕获 | 通常每层显式传递或转换 |
从逻辑一致性角度看，异常模型在“正常返回”和“错误返回”之间切出了两条平行轨道，而 Go 把两者合并到一条轨道上。这样做虽然让代码多了一些 if err != nil，但换来了调用关系的完全透明。
三、保持逻辑一致性的常见实践
为了让错误值在不同层级间传递时不丢失上下文，Go 1.13 之后引入了错误包装机制。通过 fmt.Errorf 配合 %w 动词，可以把底层错误嵌入新错误中，同时保留可被 errors.Is 和 errors.As 识别的链。这依然遵循“错误是值”的原则，只是这个值内部带了附加信息。
下面是一个包装与解包的例子，展示如何在保持值模型的同时累积上下文：
package main
import (
"errors"
"fmt"
"os"
)
func readFile(path string) ([]byte, error) {
data, err := os.ReadFile(path)
if err != nil {
// 包装原始错误，附加业务语义
return nil, fmt.Errorf("read config failed: %w", err)
}
return data, nil
}
func main() {
_, err := readFile("missing.yaml")
if err != nil {
if errors.Is(err, os.ErrNotExist) {
fmt.Println("文件不存在，使用默认配置")
} else {
fmt.Println("其他错误:", err)
}
}
}
这里没有引入任何异常语法，错误仍然是一个普通值，只是通过 %w 把原始 error 接口嵌进去了。调用方用 errors.Is 做值比较，本质也是在比较“值”。这种写法让每一层函数都维持同样的契约：返回 error，由调用方处理。
四、为什么逻辑一致性很重要
当团队中所有函数都遵守“错误即返回值”的约定，系统的控制流就会呈现高度规则的形状。新接手代码的人不需要猜测某个底层库会不会突然抛错，因为类型签名已经写明了。这种一致性在大型服务里尤其关键，它能减少联调时的认知负担，也让静态分析工具更容易追踪错误传播路径。
反之，如果为了省事在 Go 里模拟 panic-recover 充当异常，就会破坏这种一致性。recover 只能在 defer 中捕获 panic，且一旦使用不当，会让错误脱离返回值链条，变成隐式行为。除非是真正不可恢复的程序级错误，否则应坚持用 error 值传递，守住 Go 语言最朴素也最扎实的设计底线。
五、小结
“Errors are values”的核心不在于写多少行 if err != nil，而在于承认错误和正常数据拥有同等的类型地位。理解了这一点，你就不会再把 Go 的错误处理看成落后的语法，而会把它当作一种强制显式、拒绝隐式跳转的工程纪律。当错误始终是值，代码的逻辑一致性也就有了最基础的保障。
Go错误处理Errors_are_values逻辑一致性修改时间：2026-08-02 19:09:33