go 语言强调显式错误处理，但并非所有返回 error 的函数都可能产生真实错误；是否忽略 nil error 取决于接口抽象层级与具体实现的可靠性。
go 语言强调显式错误处理，但并非所有返回 error 的函数都可能产生真实错误；是否忽略 nil error 取决于接口抽象层级与具体实现的可靠性。
在 Go 中，“总是检查错误”是一条广为流传的准则，源自 Go 团队对错误作为一等值（first-class values）的设计哲学：错误不是异常，而是函数正常返回的一部分，应被显式决策——处理、传播或记录。然而，这一原则需结合具体上下文理性应用，而非机械执行。
✅ 安全可忽略 error 的典型场景
当调用的是已知无失败路径的底层具体实现时，忽略 error 是惯用且合理的。例如：
sha1Hasher := sha1.New()
_, err := sha1Hasher.Write([]byte("hello"))
// err 永远为 nil —— 源码中 Write 方法未设置 err 字段
// 此处省略检查是 idiomatic Go，简洁且无风险
同理，fmt.Print* 系列函数内部调用 os.Stdout.Write，而标准库中 os.Stdout 的默认实现（*os.File）在写入终端或管道时虽理论上可能出错（如 EPIPE），但 fmt 包已做兜底处理并忽略部分非关键错误；用户直接调用 fmt.Println("ok") 无需、也不应检查其返回的 error。
⚠️ 必须检查 error 的关键情形
一旦涉及接口类型（如 io.Writer）或运行时可替换的抽象层，就必须检查 error。原因在于：
- 接口不承诺行为，仅约定契约；任何满足
Write([]byte) (int, error)的实现都可能返回非 nil error； - 生产环境中
os.Stdout可能被重定向至文件、网络连接或自定义 writer，此时 I/O 错误（如磁盘满、连接中断）真实存在； - 忽略接口调用的 error 会掩盖潜在故障，导致数据静默丢失或状态不一致。
// ❌ 危险：w 是 io.Writer 接口，错误不可预知
func writeTo(w io.Writer, data []byte) {
w.Write(data) // 错误被丢弃！
}
// ✅ 正确：始终检查接口方法的 error
func writeTo(w io.Writer, data []byte) error {
_, err := w.Write(data)
if err != nil {
return fmt.Errorf("write to writer failed: %w", err)
}
return nil
}
? 最佳实践总结
-
具体类型 + 已验证无错误路径 → 可省略检查（如
sha1.Write,bytes.Buffer.Write）； - 接口类型 / 可配置依赖 / I/O 边界 → 必须检查 error；
- 若不确定，宁可检查：
if err != nil { return err }成本极低，却能保障健壮性； - 使用
errors.Is/errors.As进行语义化错误判断，而非仅!= nil； - 日志记录错误时，避免仅
log.Printf("%v", err)，应包含上下文（如操作、参数摘要）。
简言之：Go 的错误哲学不是“检查一切”，而是“为抽象负责”——越靠近稳定的具体实现，自由度越高；越靠近开放的接口契约，责任越重。
