Go中if err != nil是核心控制流而非语法糖，需显式处理每个错误分支；避免err变量覆盖、缩进嵌套和字符串匹配错误；用errors.Is/As判断错误类型；panic仅用于真正不可恢复的初始化失败等场景。
Go里if err != nil不是语法糖，是控制流核心
Go没有异常机制，err不是可选的装饰，而是函数契约的一部分。你看到的每处if err != nil，本质是在显式处理一个可能失败的分支——它不“丑”，强行藏起来才真容易出错。
常见错误是把多个err检查堆在一行后面，比如：val, err := doA(); if err != nil { return err }之后立刻val2, err := doB()，结果err被覆盖，上一步错误悄无声息丢失。
- 每个
err变量必须独立声明或用:=配合新变量名，避免重用同名err - 不要为了“减少行数”把
if err != nil和下一行函数调用挤在一起，视觉上断开反而更安全 - 如果连续调用多个可能失败的操作，且逻辑上必须全部成功，就老老实实写四次
if err != nil——少一次，线上就多一个难以复现的空指针或panic
提前返回比嵌套if更易读也更安全
很多人下意识写成：
if err == nil {
// 20行正常逻辑
} else {
return err
}
这会让主流程缩进加深，还容易漏掉else里的return，导致后续代码在err != nil时继续执行。
立即学习“go语言免费学习笔记（深入）”；
- 优先用“错误即退出”模式：
if err != nil { return err }，然后直接写主逻辑，不包大括号 - 这种写法让正常路径保持左对齐，一眼看清主干；错误处理集中、无遗漏风险
- 注意：如果函数需要清理资源（如
defer file.Close()），提前返回依然安全——defer会在函数返回前触发
errors.Is和errors.As才是判断错误类型的正确姿势
直接用err == io.EOF或err == ErrNotFound会失效，因为Go错误是接口，底层值可能被包装（比如fmt.Errorf("read failed: %w", io.EOF)）。
常见错误现象：本地测试io.EOF判断正常，上线后加了日志中间件，err被层层包裹，==突然不成立，程序卡死或跳过本该处理的边界情况。
- 判断是否是某类错误，用
errors.Is(err, io.EOF)，它会递归解包直到匹配 - 需要提取具体错误实例（比如获取自定义错误里的字段），用
errors.As(err, &myErr) - 别再用
strings.Contains(err.Error(), "timeout")——不稳定、性能差、无法跨语言本地化
什么时候该用panic？基本只有一种情况
Go里panic不是“严重错误”的代名词，它是“程序无法继续、连错误返回都做不到”的信号。99%的业务错误不该panic。
典型误用：HTTP handler里遇到数据库err != nil就panic，结果整个服务进程崩掉；或者把json.Unmarshal失败当致命错误panic，其实只是客户端发了坏数据。
- 只在真正不可恢复时
panic：比如初始化阶段配置文件读取失败、全局单例构建失败、内存分配器损坏 - HTTP handler、RPC方法、定时任务这些入口函数，必须用
if err != nil兜住所有err，转成状态码或响应体返回 - 如果你不确定该不该
panic，那就别panic——先返回err，观察日志和监控，再决定是否升级为panic
最常被忽略的一点：defer + recover不是优雅错误处理，而是兜底逃生舱。它救不了设计缺陷，只防得住少数几个意外panic。别把它当成try/catch用。
