go中if err != nil冗余是控制流设计问题，需通过封装io操作、自定义结果类型、明确放弃非关键错误等方式优化，而非依赖panic/recover或语法糖。
Go 里 if err != nil 写太多？不是语法问题，是控制流设计问题
Go 的多值返回 + 显式错误检查不是缺陷，而是约束——它逼你面对错误分支。但写成一连串 if err != nil { return err } 确实难读，尤其嵌套调用时。这不是靠“优雅语法糖”能解决的，得从函数职责和错误传播路径入手。
用 defer + recover 拦截错误？别碰
有人想用 panic/recover 模拟 try-catch，把错误集中处理。这在 Go 里是反模式：panic 应只用于真正不可恢复的程序异常（比如空指针解引用），不是业务错误的替代品。滥用会导致：
-
recover只对同 goroutine 有效，跨 goroutine 失效 - 堆栈被截断，原始错误上下文丢失
- 性能开销比普通 if 高一个数量级（panic 是重量级操作）
- 静态分析工具（如
errcheck）直接报错：你漏了错误检查
真正减少 if err != nil 的三个实操点
核心思路：让错误检查不显眼，而不是删掉它。以下做法经大量生产代码验证：
- 把多个连续 IO 操作封装进单个函数，内部统一检查，只在最外层暴露一次
if err != nil；例如ReadConfig()内部调用os.Open、json.Decode、Validate()，全部错误转为一个error返回 - 用自定义类型包装返回值，把
err和业务数据绑在一起，比如type Result struct { Data User; Err error }，调用方用if r.Err != nil一次判断，避免重复写 if - 对纯副作用操作（如日志、指标上报），用
_ = log.Printf(...)明确放弃错误处理——前提是它不影响主流程，且你清楚放弃的后果
Go 1.20+ 的 try 块？不存在
社区曾提案 try 关键字（类似 Rust 的 ?），但被 Go 团队明确拒绝。理由很实在：try 会让错误路径变得隐晦，破坏 Go “显式即安全” 的哲学。现在所有第三方 macro 或代码生成方案（比如 go:generate + 自定义模板）都增加了构建复杂度，且 IDE 支持差、调试困难。与其押注未来语法，不如把 if err != nil 写在该写的地方——比如函数入口、资源释放前、关键状态变更后。
立即学习“go语言免费学习笔记（深入）”；
最容易被忽略的是：错误变量名。别用 e 或 er，统一用 err；多个错误时加前缀，比如 parseErr、dbErr。不是为了好看，是为了 grep err 能准确定位所有错误检查点。
