go中用下划线忽略error风险极高，仅资源清理、日志上报等无副作用场景可安全忽略；业务逻辑中忽略io.eof、os.isnotexist等语义错误将导致panic或数据丢失。
Go 中用下划线忽略错误的常见写法和真实风险
直接忽略 error 返回值（比如写成 _ = someFunc() 或 _, _ = strconv.Atoi("abc")）看似省事，但多数时候是在埋雷。Go 的错误设计本意是“显式处理”，不是让你跳过它。
真正该忽略错误的场景极少，典型如：资源清理（defer f.Close()）、日志写入失败、指标上报超时——这些操作失败不影响主流程正确性，且无合理回退手段。
- 别在业务逻辑路径中用
_吞掉io.EOF、os.IsNotExist这类有语义的错误；它们往往意味着你需要分支处理 -
json.Unmarshal返回err != nil时忽略，大概率导致后续 panic 或静默数据丢失 - 用
_忽略多返回值中的 error，必须确认其他返回值在 error 不为 nil 时是零值或未定义——否则可能读到垃圾数据
哪些错误真的可以安全忽略？看错误类型再决定
不是所有错误都适合忽略，关键看它是否属于“可预期、不可控、无副作用”的那一类。Go 标准库中明确标注为“safe to ignore”的极少，但有些模式已被社区广泛接受。
-
os.RemoveAll在路径已不存在时返回os.IsNotExist(err)：这是常见竞态场景，可忽略 -
sync.Pool.Put没有 error 返回，但sync.Pool.Get也不报错——它本就不该失败，无需检查 -
log.Printf、metrics.Inc类型的副作用调用：失败不改变业务状态，且重试无意义 - 注意：
fmt.Printf返回(n int, err error)，但实际几乎不会出错（除非 writer 是自定义且故意返回 error），此时忽略err相对安全
比下划线更清晰的忽略方式：用 blank identifier + 显式注释
单纯写 _ 让人看不懂意图。加一行注释说明“为什么这里可以忽略”，既帮协作者理解，也倒逼自己确认合理性。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
if err := os.Remove(tempFile); err != nil && !os.IsNotExist(err) {
// 文件删不掉且不是因为已经不存在 → 需要告警
log.Warnf("failed to remove %s: %v", tempFile, err)
}
// 忽略 os.IsNotExist：临时文件可能已被其他 goroutine 清理
这种写法比 _ = os.Remove(tempFile) 强得多——它表达了判断逻辑，也隔离了真正需要关注的错误分支。
- 永远不要写
_, err := someFunc(); _ = err：这等于没忽略，还浪费一次赋值 - 如果函数只返回 error（如
http.CloseNotifier已废弃的接口），直接用_ = f()即可，但务必配注释 - 静态检查工具如
errcheck默认会报这类忽略，可通过//nolint:errcheck跳过——但每次加都要想三秒值不值得
容易被当成“可忽略”实则危险的错误模式
很多开发者把“我暂时不想处理”等同于“可以忽略”，结果上线后才发现是关键路径断点。
-
io.ReadFull返回io.ErrUnexpectedEOF：说明数据不完整，不是“差不多得了”，而是协议解析必然失败 -
database/sql的Rows.Scan错误：若忽略，后续Rows.Next()可能 panic，或漏读某列数据而不自知 -
time.Parse失败却忽略：时间字段变成零值0001-01-01，下游做时间计算时引发诡异偏移 - 调用
exec.Command后只检查cmd.Run() == nil，却忽略cmd.ProcessState.ExitCode()：命令执行失败但退出码非 0，错误被吞掉
错误是否可忽略，不取决于它“看起来不严重”，而取决于它是否影响你当前函数的契约——返回值是否可信、状态是否一致、下游是否还能继续工作。这点最容易被跳过，也最值得停下来多看一眼。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
