可恢复错误应通过 Error 返回，不可恢复错误（如配置加载失败）才使用 panic；2. 避免冗余检查，可使用 must 开头的辅助函数封装初始化错误，或通过 errors.is 和 errors.as 精准判断错误类型；3. 仅在顶层控制流（如 http 中间件、goroutine 入口）使用 defer+recover 捕获 panic，防止程序崩溃；4. 不应忽略错误，但可在明确场景下省略非关键错误处理并添加注释说明；5. 使用 fmt.errorf 的 %w 包装错误以保留原始调用链，便于后续追溯；6. goroutine 中需通过 defer+recover 捕获 panic，并通过 channel 将 error 传递回主协程处理；总之，go 错误处理应分清错误性质，合理封装，避免滥用 panic，提升代码健壮性与可读性。
在 Go 语言开发中，错误处理是程序健壮性的核心部分。Go 没有异常机制，而是通过返回 error 类型显式处理错误。这种设计鼓励开发者正视错误，但也容易导致代码中充斥着大量错误检查，影响可读性。以下是关于 golang 错误处理的最佳实践，重点在于避免过度检查和合理使用 panic。
1. 明确错误边界：区分可恢复错误与不可恢复错误
Go 的错误处理应围绕“错误是否可恢复”来设计。
- 可恢复错误：如文件不存在、网络超时、数据库查询失败等，这类错误应通过
error
返回并由调用方处理。
- 不可恢复错误：如程序逻辑错误、空指针解引用、数组越界等，这些属于程序 bug，应使用
panic
触发，通常在程序启动阶段或严重不一致状态时使用。
✅ 原则：只在程序无法继续运行时使用 panic，比如配置加载失败、依赖服务未初始化等。
// 合理的 panic 使用场景 if err := loadConfig(); err != nil { panic("failed to load config: " + err.Error()) }
❌ 避免在普通业务逻辑中使用 panic 处理可恢复错误：
立即学习“go语言免费学习笔记（深入）”；
// 错误示例：网络请求失败不是程序崩溃的理由 resp, err := http.Get(url) if err != nil { panic(err) // 不推荐 }
2. 避免冗余错误检查：使用辅助函数和错误包装
频繁的
if err != nil
会降低代码可读性。可以通过以下方式减少重复：
使用辅助函数封装常见错误处理
func mustOpen(file string) *os.File { f, err := os.Open(file) if err != nil { panic("failed to open file: " + err.Error()) } return f }
这类函数通常以
must
开头，用于测试或初始化阶段，明确表示“出错就崩”。
利用
errors.Is
errors.Is
和
errors.As
进行精准错误判断
Go 1.13+ 提供了错误包装和判断机制，避免字符串比较错误信息：
if errors.Is(err, os.ErrNotExist) { // 处理文件不存在 }
var pathErr *os.PathError if errors.As(err, &pathErr) { log.Println("Path error:", pathErr.Path) }
这比
strings.Contains(err.Error(), "no such file")
更安全、更语义化。
3. 合理使用 defer + recover 控制 panic 范围
panic
会中断正常流程，但可通过
recover
在
defer
中捕获，防止程序崩溃。适用于中间件、rpc 服务入口等需要容错的场景。
func safeHandler(fn http.HandlerFunc) http.HandlerFunc { return func(w http.ResponseWriter, r *http.Request) { defer func() { if r := recover(); r != nil { log.Printf("panic recovered: %v", r) http.Error(w, "Internal Server Error", 500) } }() fn(w, r) } }
✅ 原则：仅在顶层控制流（如 HTTP 中间件、goroutine 入口）使用 recover，不用于日常错误处理。
4. 不要忽略错误，也不要过度检查
❌ 错误被忽略
json.Unmarshal(data, &v) // 错误被丢弃
应始终处理返回的 error：
if err := json.Unmarshal(data, &v); err != nil { return fmt.Errorf("invalid json: %w", err) }
✅ 合理省略错误检查的场景
某些情况下，错误可安全忽略，但需明确注释：
_, _ = fmt.Fprintln(w, "status: ok") // 忽略写入错误，仅用于日志输出
或使用命名忽略：
_, err := writer.Write(data) if err != nil { // 实际上无法处理，但需记录 log.Printf("write failed: %v", err) // 继续执行，不中断 }
5. 使用错误包装（%w）传递上下文
Go 1.13+ 支持通过
%w
包装错误，保留原始错误链：
if err != nil { return fmt.Errorf("failed to process user %d: %w", userID, err) }
这样调用方可以使用
errors.Is
或
errors.As
追溯原始错误，便于诊断。
6. 在 goroutine 中正确处理 panic 和 error
goroutine 中的 panic 会终止整个程序，除非被捕获：
go func() { defer func() { if r := recover(); r != nil { log.Println("goroutine panic:", r) } }() // 可能 panic 的操作 }()
同时，goroutine 的 error 应通过 channel 返回：
errCh := make(chan error, 1) go func() { errCh <- doWork() }() // 主协程等待 select { case err := <-errCh: if err != nil { log.Fatal(err) } }
总结要点
- error 用于可恢复错误，panic 用于不可恢复错误
- 避免在业务逻辑中使用 panic，不要用 panic 替代错误返回
- 使用
errors.Is
和
errors.As
而非字符串比较
- 通过
%w
包装错误，保留调用链
- 在顶层（如 HTTP handler、goroutine）使用 defer+recover 防止崩溃
- 不忽略错误，但可有选择地省略非关键错误处理
- 封装重复的错误处理逻辑，提升代码可读性
基本上就这些。Go 的错误处理看似啰嗦，但只要分清边界、合理封装，就能写出清晰又健壮的代码。
