Go里if err != nil嵌套太深，怎么扁平化？
Go的错误检查习惯性写成层层if err != nil，很快变成“右滑一屏才能看到业务逻辑”。这不是风格问题，是可读性和维护性的硬伤。根本解法不是省略检查，而是让错误路径提前退出、主流程保持左对齐。
- 用
return或panic（仅限不可恢复场景）立刻终止当前函数，而不是包进else块 - 避免把多个
if err != nil塞进同一层缩进；每个错误检查后紧跟对应处理，然后直接return - 如果必须链式调用，优先用
defer清理资源，而不是靠else兜底
示例：
func processFile(path string) error {
f, err := os.Open(path)
if err != nil {
return fmt.Errorf("open %s: %w", path, err) // 直接返回，不套else
}
defer f.Close()
<pre class='brush:php;toolbar:false;'>data, err := io.ReadAll(f)
if err != nil {
return fmt.Errorf("read %s: %w", path, err) // 同样直接返回
}
return json.Unmarshal(data, &cfg) // 主逻辑在最外层缩进}
重构时该不该把错误包装成自定义类型？
不是所有错误都需要自定义。只有当需要区分错误语义（比如ErrNotFound vs ErrPermissionDenied）、支持程序逻辑分支判断、或统一加trace ID时，才值得封装。
立即学习“go语言免费学习笔记（深入）”；
- 用
errors.Is()和errors.As()做语义判断，别用==或strings.Contains() - 包装错误时优先用
%w（带栈），不用%s（丢栈） - 自定义错误类型只需实现
Error() string方法，不必带字段或方法——除非真要暴露状态
常见误用：为每个HTTP handler都建一个HandlerError，结果90%的错误只用一次，反而增加类型噪音。
用errors.Join()合并多个错误，要注意什么？
errors.Join()适合批量操作失败后汇总原因（比如并发写多个文件，部分失败），但它不是万能聚合器。
- 它返回的错误对象本身不包含新上下文，只是把多个
error拼成一个；如果想加前缀，得手动fmt.Errorf("batch failed: %w", errors.Join(errs...)) - 被
Join的错误若含重复栈帧（比如都来自同一defer），调试时可能混淆源头 -
errors.Is()对Join结果只检查是否等于任一子错误，errors.As()则只匹配第一个能转换的子错误
简单场景下，用切片存错误、最后fmt.Errorf("failed: %v", errs)更轻量，也更容易控制输出格式。
重构老代码时，哪些if err != nil不能动？
不是所有嵌套都该“扁平化”。有些结构看似冗余，实则是刻意为之：
- 涉及资源释放顺序的（比如先关A再关B，且B关闭也可能出错），强行提前
return可能导致A没关 - 错误处理逻辑本身依赖前置变量（比如日志里要打印已解析的
reqID），而reqID在后续步骤才生成 - 调用链中已有
recover()捕获panic，此时用panic代替return err会绕过原有恢复机制
这类地方，宁可多两行else，也不要为了“扁平”破坏控制流契约。
错误处理重构真正的难点，从来不在语法怎么写，而在判断哪条路径该被当作“异常”、哪条该算“常规分支”——这个分界线，往往藏在业务语义里，而不是函数签名上。
