Go 的 if err != nil 模式虽增加行数但提升可读性，因错误处理与主逻辑线性并列；应避免嵌套缩进、滥用 log.Fatal、忽略错误链（%w）、字符串匹配错误、defer 中误用 err，以及混淆 panic 与 error 职责。
Go 的 if err != nil 模式为什么让代码变长但未必变难读
它确实拉长了函数体，但关键不在于行数，而在于错误分支是否和主逻辑混在一起。如果每个操作后都紧跟着错误处理，主流程反而更线性——你一眼能看出“这步成功了才继续下一步”。真正影响可读的是嵌套过深或重复模式没被封装。
- 连续调用多个可能失败的函数（如文件打开 → 读取 → 解析）时，
if err != nil会形成“阶梯式缩进”，此时应考虑提前返回或提取为小函数 - 不要把错误处理写成
if err != nil { log.Fatal(err) }，这会让调用方无法响应错误；除非是 main 入口且明确要中止程序 - Go 1.20+ 支持
try块（实验性），但标准库和主流项目仍坚持显式检查——不是语法限制，而是设计共识：错误必须被看见、被决策
错误包装：fmt.Errorf("xxx: %w", err) vs fmt.Errorf("xxx: %v", err)
用 %w 能保留原始错误链，支持 errors.Is() 和 errors.As() 判断；用 %v 就只剩字符串描述，后续无法做类型断言或精准匹配。可读性差异体现在维护阶段：当某处日志显示“failed to save user: context deadline exceeded”，你得知道这是超时还是磁盘满——前者可重试，后者得告警。
err := doSomething()
if err != nil {
return fmt.Errorf("processing item %d: %w", id, err) // ✅ 可追溯
// return fmt.Errorf("processing item %d: %v", id, err) // ❌ 丢失底层类型
}
自定义错误类型比字符串判断更利于长期可读
用字符串匹配错误（如 strings.Contains(err.Error(), "timeout")）看似简单，实则脆弱：一旦错误消息微调，逻辑就失效。定义结构体错误并实现 Unwrap() 和 Error()，能让调用方用 errors.Is(err, ErrTimeout) 稳定识别。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 适合封装有业务语义的错误，比如
ErrInsufficientBalance、ErrRateLimited - 避免为每个 HTTP 状态码都建一个错误类型；优先复用
net/http中的http.ErrAbortHandler这类已有语义 - 导出的错误变量名应带包前缀（如
user.ErrNotFound），防止跨包冲突
defer + recover 不该用于常规错误处理
recover() 只捕获 panic，不是错误处理机制。把它当 try/catch 用，会导致控制流跳转不可见、资源泄漏风险升高（defer 的执行顺序容易误判）、且无法传递上下文信息。真正的错误路径必须走显式 return err。
立即学习“go语言免费学习笔记（深入）”；
- 仅在顶层 goroutine（如 HTTP handler）中用
recover()防止 panic 崩溃服务，并记录堆栈；绝不用于恢复业务逻辑 - 别在 defer 里做
if err != nil { ... }—— 此时err通常是上层作用域的旧值，不是当前函数实际返回的错误 - 若需清理资源，用
defer func() { if err != nil { cleanup() } }()要格外小心变量捕获，推荐直接写成独立的 cleanup 函数并显式传参
