defer不处理错误，仅保证函数退出时执行；真正决定错误返回的是命名返回值和return时机，defer中修改命名返回值才有效，匿名返回值无法被defer影响。
defer 本身不处理错误，它只保证函数退出时执行
很多人误以为 defer 能“捕获”或“传递”错误，其实它只是注册一个延迟调用，和 return 语句的执行顺序有关，但不参与错误值的生成或传播。真正决定错误是否被返回的，是函数签名中的返回值（尤其是命名返回值）和 return 的时机。
常见错误现象：defer 中修改命名返回值看似生效，但在 return 后才执行，导致最终返回值被覆盖或未按预期更新。
- 使用场景：资源清理（如
file.Close()）、锁释放（mu.Unlock()）、恢复 panic（recover()） - 关键点：若需在
defer中影响返回值，必须使用命名返回参数，且defer函数需在return之后、实际返回之前执行 - 示例中易踩坑：
defer func() { err = fmt.Errorf("wrapped") }()只有在函数有命名返回参数err error时才有效；否则该赋值完全无效
命名返回值 + defer 修改 err 是唯一可控方式
Go 中只有通过命名返回参数，才能让 defer 内部对返回变量的修改反映到最终返回值上。这是因为命名返回值在函数入口处就已声明为局部变量，defer 函数可以捕获并修改它。
非命名返回（如 return fmt.Errorf(...)）会直接计算并返回临时值，defer 无法干预。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 正确写法：
func doWork() (err error) { f, _ := os.Open("x") defer func() { if closeErr := f.Close(); closeErr != nil && err == nil { err = closeErr } }() // ... 主逻辑，可能设置 err return } - 错误写法：
func doWork() error { ... }—— 此时err是匿名返回值，defer中的err = ...不会影响最终返回结果 - 注意：多个
defer按后进先出（LIFO）执行，若都修改同一命名返回值，后者会覆盖前者
defer 不适合做错误分类或重试逻辑
defer 的执行时机不可控（仅在函数返回前），且无法访问主逻辑中的中间错误状态，因此不适合用于条件性错误包装、重试、日志分级等需要上下文判断的场景。
典型误用：defer 中检查 err != nil 然后调用 log.Fatal —— 这会导致本应由调用方处理的错误被提前终止程序。
- 应该在主逻辑中显式判断错误并决策：
if err != nil { return fmt.Errorf("read failed: %w", err) } - 重试逻辑必须放在主流程里，比如
for i := 0; i -
defer中只做无副作用、幂等、不依赖中间状态的操作（如关闭文件、解锁）
recover 必须在 defer 函数内直接调用才有效
这是 defer 少数能真正影响错误流的场景：配合 recover() 捕获 panic 并转为 error 返回。但必须满足两个硬性条件：调用 recover() 的函数本身是 defer 注册的，并且不能跨函数间接调用。
- 正确：
func safeCall() (err error) { defer func() { if r := recover(); r != nil { err = fmt.Errorf("panicked: %v", r) } }() riskyOperation() return } - 错误：
defer helperRecover()+func helperRecover() { recover() }—— 此时recover()不在 defer 直接调用链上，永远返回nil - 性能提示：
panic/recover开销大，不应作为常规错误处理手段，仅用于真正异常（如不可恢复的断言失败）
真正容易被忽略的是：命名返回值带来的隐式变量作用域，以及 defer 对它的修改时机——它既不是“返回前”，也不是“返回后”，而是在 return 语句把返回值写入栈帧之后、函数真正退出之前。这个窗口期稍纵即逝，也最易引发竞态理解。
