err != nil 有时不生效，因接口值由动态类型和动态值组成，仅当二者均为 nil 时才真为 nil；传入 *MyErr(nil) 会使动态类型非空，导致判空失效。
为什么 err != nil 有时不生效？
因为 err 是接口类型（如 error），它不为空，不代表它内部的值不为空。Go 接口值由「动态类型 + 动态值」组成；只有二者都为 nil，接口才真正为 nil。当你把一个 (*MyErr)(nil) 赋给 error，接口的动态类型是 *MyErr，动态值是 nil —— 类型非空，整个接口就不等于 nil。
- 常见错误现象：
if err != nil没进分支，但后续调用err.Error()却 panic - 根本原因：你传入的是一个「带类型的 nil 值」，不是「无类型的 nil 接口」
- 典型场景：自定义错误类型用指针接收者实现
Error()方法，然后返回(*MyErr)(nil) - 实操建议：统一用值构造器返回
nil错误，例如return nil而非return (*MyErr)(nil)
IsNil 函数怎么写才安全？
直接对任意 interface{} 用 == nil 不可靠；用 reflect.ValueOf(v).IsNil() 又可能 panic —— 它只对六种可空类型有效（Ptr/Slice/Map/Chan/Func/UnsafePointer），对 interface{} 还要额外递归检查。
- 正确做法：先判断
Kind()，再分型处理；对Interface类型需调用.Elem().Interface()后递归 - 关键细节：
reflect.ValueOf(nil).Kind()是Invalid，不能直接.IsNil() - 示例逻辑：
func IsNil(v interface{}) bool { rv := reflect.ValueOf(v) if !rv.IsValid() { return true } switch rv.Kind() { case reflect.Chan, reflect.Func, reflect.Map, reflect.Ptr, reflect.Slice, reflect.UnsafePointer: return rv.IsNil() case reflect.Interface: if rv.IsNil() { return true } return IsNil(rv.Elem().Interface()) default: return false } } - 注意：该函数无法检测结构体字段是否为 nil 指针，那是另一层判空问题
什么时候必须用 reflect，什么时候直接比 == nil？
简单类型、已知具体类型的变量，优先直接比较；泛型或通用容器（比如 interface{} 参数）才需要反射兜底。
- 可以直接
== nil的：明确是*T、[]int、map[string]int、chan int等 —— 类型已知且属于六类可空类型之一 - 必须用
reflect的：函数参数是interface{}，且你不知道它里面装的是什么（比如通用日志、序列化、断言前校验） - 性能影响：
reflect.ValueOf有小开销，高频路径（如循环内）避免滥用；生产中多数err判空仍应靠约定而非反射 - 兼容性：该方式在所有 Go 版本（1.0+）都稳定，无风险
接口判空最易忽略的边界点
不是所有「看起来像 nil」的东西都该被当成 nil 处理 —— Go 的语义决定了有些 nil 是“合法中间态”，不该提前拦截。
立即学习“go语言免费学习笔记（深入）”；
- 零大小结构体指针（如
*struct{}）即使为nil，也可能被编译器优化成相同地址，导致==比较不可靠 - 接口内嵌接口时（如
type Wrapper interface{ error; Extra() string }），判空需确认是否真的要穿透到底层值 - HTTP handler 中常写的
if r == nil是错的 ——*http.Request是指针，但框架保证不传nil，真正该防的是r.Context() == nil或r.Body == nil - 真正难缠的永远不是「怎么写判空」，而是「该不该在这层判空」—— 很多 panic 其实源于过早解引用，而不是没判空
