Go 的错误处理是显式设计而非缺陷；必须用 if err != nil 显式检查，因 error 是普通返回值，需针对不同失败场景（如文件不存在、超时）制定策略，避免跳过检查、滥用 panic 或 log.Fatal。
Go 的错误传播不是问题，而是设计选择；关键在于别让错误处理逻辑污染业务主干，也别用 panic 替代可控错误流。
为什么 if err != nil 看起来冗余却不能省
Go 没有异常机制，error 是普通返回值，必须显式检查。这不是语法负担，而是强制你面对失败路径——比如文件不存在、网络超时、JSON 解析失败，每种都该有对应策略。
常见错误现象：跳过检查或只在最外层统一处理，导致 panic 或静默失败。
- 调用
os.Open后不检查err，后续对nil文件句柄读取直接 panic - 用
log.Fatal在中间层退出，破坏调用栈可恢复性 - 把多个操作链成一行（如
json.Unmarshal(..., &v)）却不拆开检查，出错时无法定位是解析失败还是赋值失败
如何用封装减少重复的 if err != nil
不是消灭检查，而是把“检查 + 处理”逻辑下沉到合适层级。重点区分：哪些错误该立即返回？哪些该重试？哪些该降级？
立即学习“go语言免费学习笔记（深入）”；
实操建议：
- 对 I/O 类操作（如 HTTP 请求、DB 查询），封装为带重试和上下文取消的函数，内部统一处理
context.DeadlineExceeded和net.OpError - 用自定义 error 类型（如实现
IsTimeout() bool方法）替代字符串匹配，避免strings.Contains(err.Error(), "timeout") - 在 handler 或 CLI 命令入口处做一次集中错误映射：把底层
sql.ErrNoRows转为 HTTP 404，把validation.Error转为 400，保持上层协议语义清晰
errors.Is 和 errors.As 什么时候必须用
Go 1.13 引入的错误包装机制，解决了传统 == 或 strings.Contains 判断脆弱的问题。但很多人只在顶层用，漏掉了中间层的包装成本。
典型场景：
- 调用第三方库返回
fmt.Errorf("read failed: %w", io.EOF)，你无法用err == io.EOF判断，必须用errors.Is(err, io.EOF) - 需要获取原始错误详情（如 PostgreSQL 错误码），用
errors.As(err, &pgErr)提取嵌套的*pq.Error - 自己封装函数时，记得用
%w格式动词包装下游错误，否则errors.Is会失效
别让 defer + recover 变成错误处理惯性
recover 只该用于极少数必须拦截 panic 的场景（如 HTTP server 的 goroutine 崩溃兜底），绝不能用来替代 error 返回。它无法捕获非 panic 错误，且掩盖了本该暴露的控制流。
容易踩的坑：
- 在数据库事务函数里用
defer func() { if r := recover(); r != nil { tx.Rollback() } }()，结果tx.Commit()失败时没 rollback，因为Commit返回的是error，不是 panic - 把
recover放在中间件里试图“统一捕获所有错误”，结果业务层返回的user.ErrNotFound完全被忽略 - recover 后不重新 panic 或返回明确 error，导致上层认为操作成功
最常被忽略的一点：错误值本身可能包含敏感信息（如 SQL 查询、文件路径、用户输入）。日志或响应前记得用 errors.Unwrap 或自定义 Error() 方法脱敏，而不是直接打印原始 error。
