Reflect.DeepEqual常返false因严格校验类型、零值及不可比字段；禁用场景包括需忽略字段、浮点容差、含mutex、性能敏感；安全比较slice/map需标准化；业务相等应自定义Equal方法。
Reflect.DeepEqual 为什么经常返回 false？
因为 DeepEqual 对类型、零值、不可比字段（如 func、map、slice 的底层指针）都严格校验，哪怕两个 struct 字段值相同，只要其中一个字段是 nil map、另一个是 make(map[string]int)，就判为不等。
常见错误现象：DeepEqual 在测试中意外失败，尤其出现在 HTTP 响应结构体、JSON 解析后对象、带嵌套 slice 的 DTO 中。
- struct 字段顺序不同不影响结果，但字段名必须完全一致（包括大小写和 tag）
- interface{} 类型的值比较时，会递归比较其底层值，但如果 interface{} 存的是不同动态类型（比如
intvsint64），直接判不等 - time.Time 和 time.Duration 虽然底层是 int64，但类型不同 → 不等；同理
[]byte和string也不互通
哪些场景不该用 Reflect.DeepEqual？
不是所有“想比内容”都适合 DeepEqual。它本质是保守、精确、无业务语义的逐字段递归比较，遇到以下情况建议绕开：
- 要忽略某些字段（比如
ID、UpdatedAt、Version）→ 改用自定义比较函数或先清空再比 - 需要容忍浮点数误差（如
float64计算结果）→DeepEqual是位级比较，0.1+0.2 ≠ 0.3 会直接失败 - 结构体含
sync.Mutex或其他不可比较字段 → 运行时报 panic: "cannot compare struct with unexported field" - 性能敏感路径（如高频日志 diff、流式数据校验）→
DeepEqual是反射实现，比原生 == 慢 10–100 倍
怎么安全地用 DeepEqual 比较含 slice 或 map 的结构？
关键是确保参与比较的 slice/map 都非 nil，且元素顺序、键顺序（对 map）不影响语义时，需提前标准化。
立即学习“go语言免费学习笔记（深入）”；
- slice：用
sort.Slice排序后再比（前提是元素可比且排序逻辑确定） - map：转成
[][2]interface{}后排序键 → 或直接用maps.Equal（Go 1.21+）配合自定义相等函数 - 含指针字段的 struct：如果指针可能为 nil，
DeepEqual会把nil和&v当作不同；必要时先解引用或统一转值 - 示例：比较两个 map[string][]int，先确保 key 顺序无关 → 可遍历 keys 排序后逐个比
reflect.DeepEqual(m1[k], m2[k])
替代方案：什么时候该写自己的 Equal 方法？
当业务上“相等”的定义和 DeepEqual 不一致时，硬套只会让问题更隐蔽。比如：
- HTTP 请求结构体中，
Header字段是http.Header（本质map[string][]string），但 header key 不区分大小写 →DeepEqual会失败 - 数据库模型中，
CreatedAt是 time.Time，但测试只关心是否“在同一天”，而非毫秒级一致 - 第三方库返回的 struct 含未导出字段（如
http.Response.body），DeepEqual无法跳过，直接 panic
这时最稳的方式是给 struct 实现 Equal(other *YourType) bool 方法，显式控制每个字段怎么比——尤其是那些容易被忽略的：时间精度、浮点容差、nil vs empty、大小写、tag 映射逻辑。
复杂点往往不在“怎么比”，而在“哪些字段真该参与比较”。漏掉一个业务上关键的字段，或误加一个运行时必然不同的字段（比如随机 ID），比错比慢更难排查。
