reflect.DeepEqual 不按预期工作因其严格遵循反射规则而非语义比较，会因NaN、未导出字段、nil/空切片差异、类型路径不同等导致误判；手写Equal或用cmp更可靠。
Go 的 reflect.DeepEqual 为什么有时不按预期工作
它不是“智能比较”，而是按反射规则逐字段递归展开，遇到不可比较类型（如 func、map 中的 NaN 浮点键）、未导出字段、或指针指向同一地址但值不同等情况，行为容易误判。
常见错误现象：reflect.DeepEqual 返回 false，但两个结构体“看起来一样”；或者返回 true，但实际有隐藏差异（比如一个字段是 nil slice，另一个是空 slice）。
-
[]int(nil)和[]int{}在 Go 中不相等，reflect.DeepEqual严格区分 -
math.NaN()与任何值（包括自身）用==都是false，但reflect.DeepEqual对NaN值做特殊处理——相同位置都是NaN就算相等 - 含未导出字段的 struct，如果两个变量类型不同（哪怕字段名/类型完全一致），只要一个是匿名嵌入、一个是显式定义，就可能因反射路径不同而失败
自己写深度比较时，reflect.Value 怎么安全递归
直接调 reflect.Value.Interface() 可能 panic（比如 Invalid 或 UnsafeAddr 不可用），必须先检查有效性；递归入口要统一处理指针、接口、切片、映射等容器类型，否则栈溢出或无限循环。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 开头加
v := reflect.ValueOf(x); if !v.IsValid() { return false } - 对指针用
v.Elem()前，先判断v.Kind() == reflect.Ptr && !v.IsNil() - 对 interface{}，先取
v.Elem()再继续，避免把 interface 当成普通值比较 - 切片和映射需分别比长度、再逐项比——但注意：
reflect.Value.MapKeys()返回的 key 顺序不保证，要先排序再遍历
什么时候该放弃反射，改用自定义 Equal 方法
反射慢（约比手写快 10–100 倍），且无法绕过语言限制（比如不能访问未导出字段）。当类型稳定、比较逻辑明确时，手写 Equal 更可靠、更快、更易调试。
典型适用场景：
- 业务模型 struct（如
User、Order），字段少且固定 - 需要忽略某些字段（如
UpdatedAt时间戳）或做归一化（如忽略 map key 的顺序、字符串首尾空格） - 涉及浮点数比较，需指定误差范围（
float64不能直接用==）
示例：一个带忽略字段的比较函数签名通常是 func (a *User) Equal(b *User, opts ...EqualOption) bool，其中 EqualOption 可控制是否忽略时间字段、是否深比较关联结构体等。
第三方库如 github.com/google/go-cmp/cmp 解决了哪些反射痛点
cmp 不基于 reflect.DeepEqual，而是用代码生成 + 类型特化策略，在保持灵活性的同时规避多数反射缺陷。它默认忽略未导出字段，支持自定义比较器、选项式忽略、以及清晰的 diff 输出。
但要注意：
- 引入
cmp后编译变慢（尤其大型项目），因为要为每个比较类型生成专用逻辑 -
cmp.Diff默认不比较未导出字段，但如果你显式传cmp.Exporter，它仍会尝试——此时若字段是 unexported + non-comparable（如sync.Mutex），仍 panic - 和
reflect.DeepEqual行为不完全兼容：例如nilslice 和空 slice 默认视为不等，需加cmp.AllowUnexported或自定义选项才能调整
真正复杂的比较逻辑，最终都会落到“定义清楚什么是‘相等’”——而不是依赖反射自动猜。这点最容易被忽略，也最常导致后期维护踩坑。
