如何避免Golang中忽略错误返回值_Golang错误处理最佳实践_技术教程

Go语言忽略error返回值会埋下崩溃、数据丢失或静默失败隐患；常见于I/O、JSON解析、数据库操作等场景；正确处理需按错误语义分级响应、保留错误链、用errors.Is/As判断类型，并借助errcheck等工具检测。

Go 语言里忽略 error 返回值不是“写法问题”，而是直接埋下运行时崩溃、数据丢失或静默失败的隐患。编译器不会报错，但生产环境里 70% 的非预期行为都源于这里。

哪些地方最容易漏判 `error`？

常见于 I/O、类型转换、JSON 解析、数据库操作等场景，尤其在嵌套调用或快速原型开发中：

json.Unmarshal 返回 error，但有人只检查结构体字段是否为空
os.Open 后直接对 *os.File 调用 Read，没确认文件是否真打开了
strconv.Atoi 忽略第二个返回值，导致传入非数字字符串时程序 panic（因为返回 0 和 error，而你用了 0）
HTTP handler 中调用 req.ParseForm() 后不检查 error，后续读 req.FormValue 可能返回空或旧值

怎么写才算“处理了 error”？

不是只要写了 if err != nil 就算合格——关键看后续动作是否匹配上下文语义：

不可恢复错误（如配置文件读取失败、DB 连接初始化失败）：应立即 log.Fatal 或向主函数返回 error 并退出
可重试操作（如 HTTP 请求、临时文件写入）：用简单重试逻辑 + 指数退避，别直接 panic
用户输入校验失败：返回带明确提示的 http.Error 或封装为自定义 error（如 ErrInvalidEmail），而不是吞掉
日志记录必须包含上下文：用 fmt.Errorf("failed to parse config: %w", err) 保留原始 error 链，别只
写 fmt.Errorf("parse failed")

用 `errors.Is` 和 `errors.As` 替代字符串匹配

当需要区分错误类型（比如判断是不是网络超时），别用 strings.Contains(err.Error(), "timeout") ——脆弱且不跨平台。正确方式是：

if errors.Is(err, context.DeadlineExceeded) {
    // 处理超时
}
var netErr net.Error
if errors.As(err, &netErr) && netErr.Timeout() {
    // 更细粒度的网络超时判断
}

前提是上游函数用了 %w 包装错误（如 fmt.Errorf("read header: %w", err)），否则 error 链断裂，errors.Is 无效。