if err != nil 不能省略或合并判断，因为err是普通返回值，跳过检查会导致panic、资源泄漏或逻辑错乱；多个函数调用不能共用一个err判断，必须逐个检查并立即处理。
为什么 if err != nil 不能省略或合并判断
Go 的错误处理是显式且强制的，err 不是异常，而是函数返回的普通值。跳过检查或用 || 合并多个 err != nil 判断会直接导致 panic、资源泄漏或逻辑错乱——比如 os.Open 失败后继续对 nil *os.File 调用 Close()，就会 panic。
常见错误现象：panic: runtime error: invalid memory address or nil pointer dereference，往往就源于漏判上一步的 err。
- 每个可能返回非
nilerr的调用后，都必须立即检查 - 不能把多个函数调用写在同一行再统一判断，例如
f1(), f2(); if err != nil是无效的——只有最后一个函数的err被赋值 - 如果函数返回多个值（如
val, err），必须用多变量赋值接收，否则err无法捕获
如何正确写 if err != nil：结构、顺序与提前返回
Go 社区公认的惯用写法是「错误优先、提前返回」，即把错误检查放在函数体最开头，成功逻辑向右缩进减少嵌套。这不是风格偏好，而是为了可读性和可维护性。
func processFile(path string) error {
f, err := os.Open(path)
if err != nil {
return fmt.Errorf("failed to open %s: %w", path, err)
}
defer f.Close()
data, err := io.ReadAll(f)
if err != nil {
return fmt.Errorf("failed to read %s: %w", path, err)
}
// 正常业务逻辑在这里，无需 else 包裹
return json.Unmarshal(data, &config)
}
- 每次检查后，用
return立即退出，不写else - 用
%w格式化动词包装错误，保留原始调用栈（需 Go 1.13+） -
defer放在if err != nil之后，确保资源只在成功获取后才安排释放
哪些场景下 if err != nil 需要特殊处理
不是所有错误都需要立刻返回。有些错误是预期中的（如 io.EOF、os.IsNotExist），应单独分支处理；有些错误需要重试或降级；还有些仅需日志记录而不中断流程。
立即学习“go语言免费学习笔记（深入）”；
- 判断特定错误类型：用
errors.Is(err, io.EOF)或os.IsNotExist(err)，而不是字符串匹配 - 忽略某些错误：如
os.Remove删除不存在的文件，可接受os.IsNotExist(err)并跳过 - 重试逻辑：网络请求失败时，用指数退避 +
time.Sleep，但注意别无限重试 - 日志+继续：如监控上报失败，记录
log.Printf("warning: failed to report metric: %v", err)，但不 return
容易被忽略的细节和陷阱
很多 bug 来自对作用域、变量遮蔽和错误值生命周期的误判。
- 在
for或if内部用:=声明err，会导致外部的err未被更新，后续if err != nil检查的是旧值 -
defer中的函数若依赖err，要注意它捕获的是声明时的值，不是 return 语句中最终赋的值（可用命名返回参数解决） - 不要用
err == nil判断「没有错误」来代替if err != nil，语义反直觉且易出错 - 第三方库返回的
err可能是nil，但内部状态异常（如sql.Rows的Scan错误需调用Err()显式检查）
最复杂的点往往不在语法，而在错误传播路径的设计：什么时候包装、什么时候丢弃、什么时候转成用户可见提示——这需要结合业务语义，而非套用模板。
