reflect.DeepEqual 仅支持结构等价比较，不适用于高频调用、含 func/map/unsafe.Pointer/Nan 的场景，也不支持自定义逻辑如忽略字段、时间精度控制或浮点容差，需手动遍历 reflect.Value 实现。
用 reflect.DeepEqual 前先确认它真能解决问题
reflect.DeepEqual 是 Go 标准库 里最常用的通用比较函数，但它不是“万能 ==”。它只做结构等价（structural equality）：递归解引用、忽略未导出字段、处理循环引用，但不支持自定义逻辑。
- 适合场景：单元测试比对返回值、配置结构体是否与预期一致、JSON 反序列化后校验
- 不适合场景：高频调用（如排序、map key 查找），因为每次调用都走完整反射路径，开销大
- 会直接 panic 的情况：
func类型、含不可比较 map key（如[]byte）、unsafe.Pointer、含NaN的 float - 一个常见误解：
nil []int和[]int{}不相等，但nil []int和nil *[]int解引用后可能被误判 —— 它只看底层数据，不看语义
需要跳过字段或容忍浮点误差？自己写 compareValue
当你要忽略 UpdatedAt 字段、把 time.Time 比到秒级、或让 0.1 + 0.2 == 0.3 成立时，reflect.DeepEqual 就不够用了。必须手动遍历 reflect.Value。
- 核心是递归处理
struct：用v.NumField()遍历，用v.Type().Field(i).Tag.Get("cmp")读 struct tag 控制是否跳过 - 浮点比较别用
==：改用math.Abs(a-b)，并把epsilon作为选项传入 - 时间比较推荐用
t1.Equal(t2)或统一转t.UnixMilli()，避免时区 / 精度干扰 - 指针要先判
IsNil()：两边都 nil → 相等；一 nil 一非 nil → 不等；都不 nil → 递归比较.Elem()
func compareValue(vx, vy reflect.Value, opt *CompareOptions) bool {if vx.Kind() != vy.Kind() { return false} switch vx.Kind() { case reflect.Float32, reflect.Float64: a, b := vx.Float(), vy.Float() return math.Abs(a-b) Kind 和 Type 别混用，尤其在自定义类型上
比如你定义了 type MyString string，那么 reflect.TypeOf(MyString("x")).Kind() 是 string，但 Type.String() 是 main.MyString。很多 bug 出在拿 Kind 当 Type 用，比如错误地认为所有 string Kind 都能直接转成 string 接口。
- 判断基础类别（是否是 struct/map/slice）用
Kind() - 判断具体类型（是否是
*http.Request或某个 interface）必须用Type()，再配合.Implements()或.AssignableTo() - 从接口变量提取反射对象时，
reflect.ValueOf(x)得到的是运行时实际值的Value，不是接口类型本身 —— 这是第一定律，也是最容易漏掉的前提
泛型 + 反射才是 Go 1.18+ 的合理组合
纯反射写通用比较既慢又难维护。Go 1.18 引入泛型后，更合理的做法是：用泛型约束输入类型，内部按需调用反射 —— 既保编译期类型安全，又留定制空间。
立即学习“go 语言免费学习笔记（深入）”；
- 简单可比较类型（如
int,string）直接用==，零开销 - 复杂结构体定义泛型函数：
func Equal[T any](a, b T) bool，内部仍可用reflect.DeepEqual，但调用侧有类型推导，不会传错 - 真正高频路径（如 ORM 主键比较）建议用
go:generate为特定 struct 生成无反射的比较方法，性能提升 10x+ - 别为了“看起来泛型”而泛型：如果 T 总是
interface{}，那和没泛型一样，还多一层抽象
最常被忽略的一点：反射比较永远无法绕过“未导出字段不可见”这个封装边界。哪怕你用 unsafe 强行访问，也破坏了包内契约 —— 如果真需要比私有字段，说明设计该重构，而不是让反射背锅。
