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，失败时返回非nilerror”的约定 - 这个
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 包工具，就能避开大部分陷阱。
