17370845950

应返回error而非随意panic，仅在不可恢复时用panic；必须显式处理error，禁用_忽略；合理包装错误，避免冗余；recover仅用于顶层防护，非错误处理机制。

panic 代替 error 返回，导致无法恢复

新手常把 panic 当作“报错”用，比如在文件打开失败、JSON 解析出错时直接 panic(err)。这会让调用方彻底失去控制权，且无法用 recover 拦截（除非在同 goroutine 且显式 defer），更不符合 Go 的错误处理哲学。

正确做法是：绝大多数非程序崩溃类问题，应返回 error 类型，由调用方决定是否终止流程。

• 只有真正不可恢复的场景才用 panic：如 nil 指针解引用、切片越界、断言失败等运行时错误
• http.HandlerFunc 等框架入口中，panic 可能被中间件捕获并转为 500，但这是框架行为，不是你该依赖的错误处理方式
• 避免在库函数中 panic —— 这等于强制调用方用 recover，破坏了 API 的可预测性

忽略 error 或只写 _ = err

Go 编译器强制检查未使用的变量，但新手常写 _ = doSomething() 来“绕过”编译错误，或干脆删掉 err 变量声明。结果是：磁盘写满、网络超时、权限不足……全被静默吞掉。

哪怕只是日志记录，也必须显式处理 error。

• 不要用 if err != nil { return } 就完事 —— 至少加 log.Printf("failed to X: %v", err)
• 在 CLI 工具中，常见做法是 if err != nil { log.Fatal(err) }；在库中则必须向上返回
• 使用 errors.Is(err, os.ErrNotExist) 或 errors.As(err, &pathErr) 做类型判断，而不是用字符串匹配 err.Error()

error 包装丢失上下文或过度包装

Go 1.13 引入了 %w 动词和 errors.Unwrap，但新手要么完全不用（只返回原始错误），要么层层 fmt.Errorf("step A failed: %w", err) 导致堆栈爆炸、日志冗余。

关键是要让错误既可定位，又不重复。

• 在关键边界处包装一次即可：比如从数据库层到 service 层，用 fmt.Errorf("create user: %w", err)
• 避免在每一层都包装 —— 不要从 DAO → Service → Handler 都加前缀，最终日志里出现 “HTTP handler → service → repo → sql driver” 四重嵌套
• 调试时用 fmt.Printf("%+v", err) 查看带栈信息的错误（需用 github.com/pkg/errors 或 Go 1.20+ errors.Join 配合）

defer + recover 滥用，误以为能兜住所有错误

看到 “Go 没有 try/catch” 就急着自己模拟，写一堆 defer func() { if r := recover(); r != nil { ... } }()。但 recover 只对同 goroutine 中的 panic 有效，且一旦执行就终止当前 defer 链，极易掩盖真实问题。

它不是错误处理机制，而是最后的崩溃防护网。

• 仅在顶层 goroutine（如 HTTP handler、goroutine 入口）中谨慎使用 recover，用于防止 panic 导致进程退出
• 绝不在普通函数里写 recover —— 这说明你本该用 error 处理，却用 panic 制造了需要兜底的麻烦
• recover() 返回的是 interface{}，不是 error，不能直接参与 Go 的错误链，也无法用 errors.Is 判断

最隐蔽的坑是：把错误处理逻辑写得“看起来很完整”，比如每层都 if err != nil { return err }，但忘了上层没检查返回值，或者用 var err error 声明后，在多个分支里忘记赋值 —— 此时 err 是 nil，而实际操作已经失败。