该用 reflect.DeepEqual 的场景是单元测试验证返回值或临时调试，且对象结构简单、不含不可比较成员；否则应优先手写 Equal 方法或使用 cmp.Equal。
什么时候该用 reflect.DeepEqual，而不是 ==
Go 中 == 只能比较可比较类型（如基本类型、指针、数组、结构体字段全可比较），一旦含 slice、map、func、chan 或含这些字段的结构体，== 直接编译报错：invalid operation: == (mismatched types)。这时候必须换深度比较。
但别一上来就默认用 reflect.DeepEqual——它开销大、不透明、对浮点数/NaN/NaN 处理不符合直觉，且无法跳过某些字段或自定义比较逻辑。
- 适合场景：单元测试里验证返回值是否“看起来一样”，临时调试，对象结构简单且不含不可比较成员
- 不适合场景：高频调用（如网络请求响应比对）、需要忽略时间戳/ID 等字段、要区分
nilslice 和空slice -
reflect.DeepEqual认为nilslice 和[]int{}相等，但业务上常需区分
reflect.DeepEqual 对 nil、NaN、指针的常见误判
它不是“语义相等”，而是基于反射逐字段递归比较内存表现，导致几个经典坑：
-
NaN != NaN是 IEEE 754 规定，但reflect.DeepEqual却认为两个math.NaN()相等——因为底层 bit pattern 一样，且它不走==判断 - 指向同一地址的两个指针，和指向不同地址但内容相同的两个指针，在
reflect.DeepEqual下结果一样；但它无法识别“逻辑上应视为相同”的指针别名（比如缓存中复用的对象） -
nil接口和nil指针会被当作“空值”统一处理，但若接口里装了*int且值为nil，和一个未初始化的interface{}，reflect.DeepEqual会返回true，而实际类型信息已丢失
示例：
fmt.Println(reflect.DeepEqual(math.NaN(), math.NaN())) // true —— 注意，这不是数学意义上的相等
立即学习“go语言免费学习笔记（深入）”；
替代方案：什么时候该自己写比较函数
当结构体字段多、有业务含义、或需控制比较粒度时，手写比反射快、安全、可读性强。
- 为结构体实现
Equal(other *MyStruct) bool方法，显式列出要比较的字段，跳过UpdatedAt、ID等非幂等字段 - 用
cmp.Equal（来自github.com/google/go-cmp/cmp）替代：支持选项如cmpopts.IgnoreFields、cmpopts.EquateNaNs、cmpopts.SortSlices - 对 map/slice 做确定性排序后再比（
reflect.DeepEqual不保证遍历顺序，map 尤其危险）
示例（用 cmp）：
cmp.Equal(a, b, cmpopts.IgnoreFields(MyStruct{}, "CreatedAt", "ID"))
性能敏感时的实测提醒
reflect.DeepEqual 是反射实现，每次调用都要解析类型、遍历字段、分配临时对象。压测显示：对含 10 个字段的结构体，比手写 Equal 慢 3–5 倍；含嵌套 slice 时差距拉大到 10 倍以上。
- 不要在 HTTP handler 或数据库查询结果比对中直接用它做响应校验
- 如果只是判断两个 JSON 字节是否一致，用
bytes.Equal比反序列化再DeepEqual快一个数量级 - 注意：它不短路，即使第一个字段就不同，也会继续检查所有字段
真正难的不是“怎么比”，而是想清楚“什么算相等”——类型定义、业务约束、精度要求、nil 语义，这些都得先厘清，工具只是执行者。
