reflect.DeepEqual性能不可控因必须走完整反射路径且无法短路，同一代码数据形态微变即导致耗时差一个数量级；遇func、map等会panic或静默失败；nil slice与nil map行为不一致，业务中易引发断言随机失败。
reflect.DeepEqual 为什么在结构体比较中性能不可控
它不是“有点慢”，而是根本无法预测耗时——同一份代码，数据形态稍有变化，CPU 时间可能差出一个数量级。核心问题在于：必须走完整反射路径，且无法短路。
常见错误现象：pprof 显示 reflect.deepValueEqual 占 CPU 超 70%；go test -bench=. 发现某个断言从 100ns 暴涨到 2ms；线上批量校验响应体时 GC 频率明显升高。
- 哪怕第一个字段就不同，它仍会递归展开整个结构树，不提前退出
- 嵌套 5 层 struct + 每层含
[]map[string]interface{}，实际复杂度接近O(n×m) -
interface{}参数会触发额外类型解析，比如(*MyStruct)(nil)和(*Other)(nil)底层类型不同，就得解包多层
哪些字段会让 reflect.DeepEqual 直接 panic 或静默失败
它不是“比较失败”，是压根拒绝参与——但表现完全不同：有的崩，有的假阴性，还都不报具体位置。
常见错误现象：测试里 struct 加了个 OnSuccess func()，一跑就 panic；gRPC message 里带 map[time.Time]string，结果永远 false 却找不到原因。
- 直接
panic：遇到func、chan、unsafe.Pointer、complex64/complex128 - 静默返回
false：map 的 key 是不可比较类型（如struct{a,b int}）、任意位置出现math.NaN() - 未导出字段被跳过：比如
cache map[string]int或mu sync.RWMutex，导致两个逻辑不同的实例“意外相等”
nil slice 与 nil map 在 DeepEqual 中行为不一致的坑
这不是 bug，是底层 header 实现差异决定的必然结果——但业务代码几乎总会混用，导致断言随机失败。
常见错误现象：HTTP handler 返回结构体时，tags 字段有时是 null（解成 nil map），有时是 {}（解成空 map），测试断言总失败；而 slice 字段却一直通过，让人误以为 “DeepEqual 很稳”。
-
[]int(nil)和[]int{}被判为相等 -
map[string]int(nil)和map[string]int{}被判为不等 - protobuf/gRPC 解析后字段初始化方式不可控，尤其在 JSON 场景下
- 写测试时，确保预期值和实际值在
nil/空上保持一致，比如统一用make(map[string]int)而非字面量map[string]int{}（后者是nil）
替代方案选型的关键判断点
手写 Equal 方法、泛型 cmp.Equal、或代码生成的 XXXEqual，都不是单纯“更快”的替换，而是要对齐你的约束条件。
- 如果结构体字段稳定、无循环引用、且你控制所有初始化路径，手写
Equal最轻量、最可控 - 如果需忽略字段、容忍浮点误差、处理
time.Time精度、或支持 protobuf，cmp.Equal是更安全的选择，但必须显式传cmpopts.IgnoreUnexported或cmp.Comparer，否则行为可能翻车 - 如果结构体来自 IDL（如 Protobuf/Thrift），优先用生成的
XXXEqual，它绕过反射，也规避了nil/{}语义歧义
真正难的不是选哪个函数，而是厘清你比较的到底是什么：是内存布局一致性？业务语义一致性？还是 JSON 序列化后的等价性？这三者在 Go 里从来就不是一回事。
