一、Go 的错误处理哲学

Go 的设计哲学鼓励明确的、显式的错误处理方式。它不像 Java 或 Python 使用异常机制，而是采用了返回值 error 的方式，让错误成为程序流程的一部分。

Go 的错误处理核心理念是： 错误是值（Errors are values），而非异常。

---

二、error 接口：第一类错误处理机制

1. 定义与本质

type error interface {Error() string
}

任何实现了 Error() string 方法的类型，都可以被当作 error 使用。

2. 使用场景

• 绝大多数业务逻辑错误

• IO 错误、网络错误、输入校验失败

3. 自定义错误

type MyError struct {Code intMsg  string
}func (e MyError) Error() string {return fmt.Sprintf("code=%d, msg=%s", e.Code, e.Msg)
}

支持更丰富的上下文与分层错误处理。

4. errors.New vs fmt.Errorf vs %w

errors.New("something wrong")
fmt.Errorf("wrap error: %w", err) // 支持错误包装

Go 1.13 引入的 %w 和 errors.Is / errors.As 组合，增强了错误链追踪能力。

---

三、panic/recover：第二类错误处理机制

1. panic 的语义

panic 会立即中止当前函数的执行流程，逐层向上回溯调用栈，直到：

• 有 recover 捕获它；

• 或者程序崩溃。

2. 使用场景

Panic 不是常规的错误处理方式，只在不可恢复的场景下使用：

• 数组越界（runtime panic）

• 空指针解引用

• 编程逻辑错误（bug）

• 必须中止程序的严重错误（如配置无法加载）

func mustLoadConfig() {data, err := ioutil.ReadFile("conf.yaml")if err != nil {panic(fmt.Sprintf("failed to load config: %v", err))}
}

3. recover 的使用

func safeRun() {defer func() {if r := recover(); r != nil {fmt.Println("Recovered from panic:", r)}}()dangerousOperation()
}

注意事项：

• 只有在 defer 中调用 recover 才能生效；

• 一般不推荐滥用 recover 做正常流程控制。

---

四、错误处理模式对比

特性	error	panic/recover
用途	常规错误，用户/IO层错误	编程错误、极端情况
表现	显式处理流程	类似异常传播
推荐使用频率	高频	低频（只用于不可恢复错误）
控制方式	if err != nil	defer + recover
是否安全	可控、可组合	易误用、控制流不清晰

---

五、工程实践建议

✅ 使用 error 的最佳实践

1. 明确错误语义（定义自定义错误类型或用 errors.Join / %w 包装）

2. 尽量不要忽略 err（使用 linters，如 errcheck）

3. 错误链 + 错误码设计：可提升服务诊断能力

4. 输出详细上下文：fmt.Errorf("failed to open file %s: %w", filename, err)

❌ panic 的反面案例

func getValue(index int) int {if index >= len(arr) {panic("index out of range")}return arr[index]
}

建议改为返回错误，除非你在做库或底层组件。

---

六、错误处理模式进阶：error + panic 的融合技巧

1. panic 捕获封装为 error 返回

func SafeCall(f func()) (err error) {defer func() {if r := recover(); r != nil {err = fmt.Errorf("panic recovered: %v", r)}}()f()return nil
}

适合用于中间件、调度器、插件等运行用户代码但不能让其崩溃的场景。

2. Recover 后重新 panic？

慎用。除非你希望某些 panic 上报后仍让程序退出。

---

七、小结

问题类型	处理方式
业务层错误	使用 error
程序 bug / 不可恢复错误	使用 panic
避免程序崩溃	defer + recover 包裹，日志记录并降级处理

---

附录：你应该知道的陷阱

• panic 不一定来自你手动触发，有些来自 runtime（如 nil deref）

• 多层 recover 只能捕获当前 goroutine 的 panic

• 在并发场景中 panic 会导致整个 goroutine 崩溃