Go中error是接口类型，nil表示无错误；直接用err != nil判断最安全，避免转为interface{}后判空失效，需用errors.Is/As区分错误类型，自定义error时确保Error()不panic。
Go 中的 error 是接口类型，nil 表示“无错误”，但判断它是否为 nil 看似简单，实则容易踩坑。关键不是“怎么写 if”，而是“什么时候会误判”。
直接比较 err == nil 是最常用也最安全的方式
只要 error 变量是函数原生返回的（比如 os.ReadFile、json.Unmarshal），直接用 if err != nil 就足够可靠：
Go 的标准库和绝大多数规范函数都遵循“成功时返回 nil，失败时返回非 nil error”的约定 这个 nil 是接口的零值，不是指针或结构体的 nil，无需额外反射或类型转换 不要写成 if err == nil { ... } else { ... } 嵌套过深，推荐提前 return：
content, err := os.ReadFile(“config.json”)
if err != nil {
log.Fatal(“读取配置失败:”, err)
}
// 后续逻辑直接写在这里，不用 else 包裹
避免把 error 赋给 interface{} 后再判 nil
这是最隐蔽的 nil 判断失效场景：
如果写 var e interface{} = err，再判断 e == nil，结果可能不符合预期 因为 interface{} 的 nil 要求底层类型和值都为 nil；而一个 *MyError 类型的 error 值即使为 nil，装进 interface{} 后也不是接口意义上的 nil 所以：永远不要为了“泛化”而把 error 转成 interface{} 再做 == nil 判断
需要区分错误类型？用 errors.Is 和 errors.As
当你要判断是不是某个特定错误（比如文件不存在、超时），别用字符串匹配或强制类型断言：
errors.Is(err, os.ErrNotExist) —— 判断是否是同一类错误（支持包装链） var pathErr *os.PathError; if errors.As(err, &pathErr) { ... } —— 安全提取底层错误详情，比如 pathErr.Path 这两个函数内部已正确处理了 nil 边界情况，比手写 err.(*os.PathError) 更健壮
自定义 error 时确保 Error() 方法不 panic
如果你实现了 error 接口，务必保证 Error() 返回字符串时不会触发 panic：
例如字段可能为 nil 指针，调用前要判空：if e.detail != nil { return e.detail.String() } 否则在日志打印、fmt.Printf("%v", err) 时程序崩溃，表面看像是 “nil error 导致 panic”，其实是自定义逻辑缺陷 测试时可加一行：if err != nil { _ = err.Error() } 快速暴露问题
基本上就这些。nil error 判断本身不复杂，但容易忽略类型转换和接口包装带来的语义变化。坚持原生判空、慎用 interface{}、善用 errors 包工具，就能避开大部分陷阱。
以上就是如何处理Go中出现的nil error问题_Go nil error判断技巧的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1428846.html
微信扫一扫 
支付宝扫一扫 
