可恢复错误应通过 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.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 的错误处理看似啰嗦，但只要分清边界、合理封装，就能写出清晰又健壮的代码。
