go 语言强调显式错误处理，但对明确不会返回错误的函数（如 crypto/sha1.write）可省略检查；而对接口类型（如 io.writer）调用时，因实现不确定，必须检查错误。
go 语言强调显式错误处理，但对明确不会返回错误的函数（如 crypto/sha1.write）可省略检查；而对接口类型（如 io.writer）调用时，因实现不确定，必须检查错误。
在 Go 中，“检查所有错误”是一条广受推崇的实践准则，其核心并非教条式地 if err != nil { ... } 套路，而是基于类型确定性与行为可预测性的工程判断。
✅ 可安全忽略错误的场景：具体类型 + 已知无错实现
以 crypto/sha1.Hash.Write 为例，其方法签名是：
func (h *digest) Write(p []byte) (n int, err error)
但源码中始终返回 n = len(p), err = nil（见 sha1.go L112)。由于你直接调用的是 具体结构体方法，且该实现被 Go 标准库保证永不返回非 nil 错误，此时忽略错误是安全、惯用且推荐的：
sha1Hasher.Write(data) // ✅ 简洁、清晰、符合 Go 的“简单即美”
类似地，fmt.Print / log.Print 等向 os.Stdout 写入的函数，在绝大多数上下文中也可不检查错误——因为它们底层调用的是已知稳定的 os.File.Write（对标准输出句柄而言），但请注意：这属于基于事实的简化，而非语言契约。
⚠️ 必须检查错误的场景：接口类型 + 实现不可控
关键分水岭在于 是否通过接口调用。例如 io.Writer 接口：
type Writer interface {
Write(p []byte) (n int, err error)
}
当你持有 io.Writer 接口变量时，实际实现可能是：
-
os.File（可能因磁盘满、权限不足等失败） -
bytes.Buffer（内存分配失败时理论上可返回err） - 自定义网络 writer（网络中断、超时）
- 甚至测试用的
mockWriter（故意返回io.EOF模拟边界）
此时，忽略错误即放弃故障可见性，违反 Go “errors are values” 的设计哲学——错误值是控制流的一部分，不是异常，必须被显式决策：
// ❌ 危险：隐藏潜在失败
writer.Write(data)
// ✅ 正确：明确处理或传播
n, err := writer.Write(data)
if err != nil {
return fmt.Errorf("failed to write to output: %w", err)
}
? 最佳实践总结
-
具体类型调用（如
sha1Hasher.Write,strings.Builder.WriteString）：查阅文档或源码确认是否恒返nil错误；若确定，则可省略检查。 -
接口调用（如
io.Writer.Write,json.Marshal,http.Client.Do）：一律检查错误——这是健壮性的底线，也是 Go 工程化的标志性习惯。 -
日志/调试输出（如
log.Printf）：虽常忽略，但生产环境建议包装为log.Output并检查（尤其当log.SetOutput被重定向至文件或网络时）。 -
工具链辅助：启用
govet -shadow和静态分析工具（如errcheck）可自动发现未处理的错误，避免疏漏。
记住：Go 不强制你 panic 或崩溃，但它要求你主动选择忽略——而这个选择，必须建立在充分理解类型契约的基础之上。
