Go错误处理需显式检查error，禁用下划线忽略；用go vet、staticcheck、errcheck等工具检测未处理错误；封装常用操作减少样板代码；测试必须覆盖error分支。
Go语言的错误处理机制看似简单，实则容易因惯性写法或疏忽导致错误被静默忽略。最典型的“隐藏错误”是调用返回error的函数后未检查、未处理，甚至直接丢弃——编译器不报错，程序却在运行时行为异常或数据丢失。
别用下划线忽略error
这是最常见的漏检源头。例如：
❌ 错误写法：
f, _ := os.Open("config.json") // 错误被丢弃！
json.NewDecoder(f).Decode(&cfg) // f可能为nil，这里panic
✅ 正确做法：显式检查并处理每一步可能失败的操作：
- 用
if err != nil立即判断，不跳过 - 必要时提前返回（如函数签名支持）、记录日志、或封装为自定义错误向上抛
- 避免在一行中连续调用多个可能出错的函数而不检查中间结果
用go vet和静态分析工具主动拦截
Go自带的go vet能发现部分明显的问题，比如未使用的变量（含err）。但默认不启用errorsas等更严格的检查。
- 运行
go vet -vettool=$(which staticcheck) ./...（需安装staticcheck）可捕获“ignored error”类问题 - 在CI流程中加入
golangci-lint，启用errcheck插件：它专查未检查的error返回值 - 编辑器（如VS Code + Go extension）开启实时vet提示，写完就提醒
封装常用操作，把错误检查“固化”进API
重复写if err != nil { return err }易疲劳出错。可通过小工具函数或包装类型减少样板代码：
- 对文件读取、JSON解析等高频操作，封装成返回
(T, error)的函数，并强制调用方处理 - 使用
defer配合recover仅用于真正需要捕获panic的场景，不要用来替代error检查 - 在关键路径（如HTTP handler、数据库事务）开头统一加
if err != nil { log.Error(err); return }模板
测试要覆盖error分支，别只测“happy path”
很多隐藏错误只在特定输入或环境（如磁盘满、网络超时）下触发，单元测试若只构造成功案例就形同虚设。
- 用
io.ErrUnexpectedEOF、os.ErrNotExist等标准错误模拟失败路径 - 对返回
error的函数，至少写一个“返回非nil error时行为正确”的测试用例 - 借助
gomock或接口抽象，让依赖（如DB、HTTP client）可控地返回错误，验证错误传播与恢复逻辑
基本上就这些。Go不强制你处理error，但它的设计哲学是“显式优于隐式”。只要养成检查习惯、借助工具兜底、用测试验证边界，90%以上的隐藏错误都能在开发阶段暴露出来。
