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") ——脆弱且不跨平台。正确方式是：
立即学习“go语言免费学习笔记（深入）”；
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 无效。
工具链能帮你守住底线
仅靠人工审查很难覆盖所有分支。推荐接入静态检查：
-
errcheck：专查未使用 error 返回值的调用，CI 中强制失败 -
go vet -shadow：发现局部变量遮蔽err（比如循环里重复声明err := xxx()，外层 err 被覆盖） - IDE 插件（如 GoLand 的 “Unhandled error result” 提示）实时标红未处理点
注意：errcheck 默认会放过 _ = someFunc()，但这种写法本身已是危险信号——除非你加了注释说明为何忽略（例如 “ignore EOF on stream close”），否则一律禁止。
最常被忽略的一点：不是所有函数返回 error 都代表失败。比如 io.Read 在流结束时返回 io.EOF，这是正常控制流，该用 errors.Is(err, io.EOF) 显式识别，而不是当成异常处理。
