go中重复if err != nil的根本原因是每步都检查并处理错误，而非延后统一处理；应区分必须立即响应的错误与可合并上报的错误，用defer+错误变量或errors.join优化。
Go 中 if err != nil 重复出现的根本原因
不是 Go 强制你写那么多 if err != nil，而是你在每个可能出错的调用后，都试图立刻处理错误——而多数时候，你其实只想“上报”或“终止”，并不需要当场恢复。这种“每步都检查 + 每步都处理”的惯性，让错误路径和业务逻辑深度缠绕。
真正该问的是：哪些错误必须此刻干预？哪些可以延后统一处理？哪些压根不该由当前函数兜底？
用 defer + 自定义 error 类型提前退出
适用于明确知道整个函数只要出一次错就该结束、且错误需携带上下文（比如操作对象名、步骤编号）的场景。避免在中间层层 if err != nil 判断，改用一个可复位的错误变量 + defer 统一响应。
- 定义一个指针型错误变量：
var err error，并在函数开头加defer func() { if err != nil { return } }() - 所有可能出错的地方直接赋值：
err = os.WriteFile(...)，不用if err != nil包裹 - 后续语句用
if err != nil { return }快速跳过（仅检查，不处理），保持代码线性阅读流 - 注意：不能在
defer中修改局部变量作用域外的err，所以必须声明为函数级变量，而非:=声明
用 errors.Join 合并多个错误（Go 1.20+）
当你要批量执行几个操作（如关闭多个资源、校验多个字段），又不想因为第一个失败就中断，但最终仍要一次性返回所有问题时，errors.Join 比手动拼字符串或自定义切片更安全、更标准。
立即学习“go语言免费学习笔记（深入）”；
-
errors.Join会自动忽略nil，支持任意数量参数：errors.Join(err1, err2, err3) - 它保留原始错误链（
Unwrap可追溯），比fmt.Errorf("a: %v, b: %v", err1, err2)更利于调试 - 不要对非错误值调用
errors.Join，传入nil安全，但传入int或字符串会 panic - 示例：
err = errors.Join(closeDB(), closeCache(), closeLog())，之后再统一判断if err != nil
什么时候不该省略 if err != nil
不是所有 err 都能“延后处理”。有些错误类型决定了你必须立刻响应，否则程序状态已不可靠。
-
os.IsNotExist(err)：文件不存在时往往要走创建分支，而不是报错退出 -
context.Canceled或context.DeadlineExceeded：必须立即返回，不能继续执行下游逻辑 - 数据库
sql.ErrNoRows：是预期中的“无数据”，不是异常，常需转为零值而非向上抛 - 任何涉及资源释放、状态重置、锁释放的操作，错误必须就地检查并记录，不能依赖 defer 或合并
最易被忽略的一点：错误是否改变了函数的**可观察行为**？如果 err 发生后你还继续写了日志、发了 HTTP 请求、更新了缓存，那这个 if 就不是冗余，而是必要隔离。冗余的是“相同处理逻辑”的重复，不是“错误检查”本身。
