defer 无法捕获普通错误，仅能通过 recover 拦截同一 goroutine 中的 panic；对正常返回的 error 应显式判断转换，defer 仅适用于资源清理及合并 cleanup 错误。
defer 中无法直接 recover 非 panic 错误
很多人误以为 defer 能“捕获”普通返回错误（比如 err != nil），其实不能。defer 只在函数退出时执行，它不拦截返回值，也不修改已确定的 return 结果。真正能用 defer + recover 拦截的，仅限于运行时 panic——而且必须发生在同一 goroutine、且未被其他 recover 提前捕获。
所以，想“转换特定类型错误”，得区分两种场景：
- 你实际想处理的是 panic（比如空指针、下标越界），想把它转成可返回的
error - 你真正面对的是函数正常返回的
error值（比如io.EOF、os.IsNotExist），这时defer不参与，得靠手动判断或包装
用 defer + recover 转换 panic 为自定义 error
这是 defer 真正能起作用的典型场景：把本会崩溃的 panic，兜住并转成业务可处理的 error。但要注意，recover() 必须在 defer 函数里调用，且只对当前 goroutine 有效。
常见错误：在 defer 外调用 recover()，或在子 goroutine 里 panic 后试图从外层 recover——都无效。
func safeParseJSON(data []byte) error {
var result error
defer func() {
if r := recover(); r != nil {
switch x := r.(type) {
case string:
result = fmt.Errorf("json parse panic: %s", x)
case error:
result = fmt.Errorf("json parse panic: %w", x)
default:
result = fmt.Errorf("json parse panic: unknown type %T", x)
}
}
}()
json.Unmarshal(data, &struct{}{}) // 可能 panic（如嵌套过深）
return result
}
-
recover()必须在 defer 函数内部，且是第一个语句（否则 panic 已传播出去） - panic 值类型不确定，强制类型断言前务必做
r != nil判断 - 不要直接返回
fmt.Errorf("%v", r)——丢失原始类型信息，不利于下游用errors.As判断
对正常 error 做类型转换，defer 不是合适工具
如果你的函数返回 error，比如 os.Open 返回 *os.PathError，想把它转成自定义错误类型（如 FileNotFound），应该在 return 前显式判断，而不是依赖 defer。
用 defer 做这事不仅多余，还容易掩盖逻辑——因为 defer 在 return 之后才执行，此时返回值已锁定。
func openConfig(path string) (io.ReadCloser, error) {
f, err := os.Open(path)
if err != nil {
if os.IsNotExist(err) {
return nil, &FileNotFound{Path: path}
}
return nil, err
}
return f, nil
}
-
os.IsNotExist、errors.Is、errors.As是判断错误类型的正确方式 - 想统一转换某类错误？写个中间函数或 wrapper，比如
WrapIOError(err)，别塞进 defer - 在 defer 里改返回值变量（如上面示例中的
result）只对命名返回值有效，且易读性差，不推荐用于 error 转换主逻辑
真正需要 defer 的边界场景：资源 cleanup + 错误合并
唯一和 error 转换强相关的 defer 使用场景，是 cleanup 过程中发生新错误，需与主逻辑错误合并。比如文件操作后 Close() 失败，你想把两个 error 一起返回。
这时候 defer 不是用来“捕获”，而是确保 cleanup 执行，并有机会收集 secondary error。
func readAndClose(f *os.File) ([]byte, error) {
data, err := io.ReadAll(f)
var closeErr error
defer func() {
if e := f.Close(); e != nil {
closeErr = e
}
}()
if err != nil {
return nil, err
}
if closeErr != nil {
return nil, fmt.Errorf("read ok but close failed: %w", closeErr)
}
return data, nil
}
- 主逻辑 error（
io.ReadAll）优先级高于 cleanup error（f.Close()） - 不能用
errors.Join直接合并——Go 1.20+ 支持，但很多旧项目仍用%w或自定义结构体 - 如果主逻辑已出错，是否还要执行 cleanup？通常要，但需避免 panic（比如
f为 nil 时f.Close()panic），加 nil 检查更稳妥
最常被忽略的一点：panic 的根源往往不是业务逻辑，而是没校验输入（比如传了 nil interface{} 给 json.Unmarshal）、或并发访问未保护的 map——这些比 recover 更值得前置防御。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
