Golang错误处理对代码可读性的影响

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) 稳定识别。

• 适合封装有业务语义的错误，比如 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 函数并显式传参

错误链的完整性、错误类型的可判定性、以及 panic 和 error 的职责分离——这三点漏掉任何一项，都会让半年后的自己看不懂当时为什么那样写。