reflect.DeepEqual 测试变慢因通用深度遍历不跳零值、不缓存类型、无短路；go-cmp 更优，支持忽略字段、自定义比较、早返回且优化常见类型；极简场景或禁第三方依赖时仍可用 reflect.DeepEqual。
为什么 reflect.DeepEqual 在测试里跑得越来越慢
因为它是通用型深度遍历，不跳过零值、不缓存类型信息、不做短路判断——哪怕两个 map 只差一个 key，它也会把整个结构全走一遍。尤其在 benchmark 里对比大 slice 或嵌套 struct 时，耗时可能差 5–10 倍。
- 对含指针、interface{}、func 类型的值会 panic，但测试中常因 mock 数据混入未察觉
- 无法忽略字段（比如
UpdatedAt time.Time），每次都要手动构造“干净”期望值 - Go 1.21+ 对
reflect包做了更多安全检查，小对象差异检测开销反而更明显
用 github.com/google/go-cmp/cmp 替代的实操要点
它默认行为更贴近测试需求：可忽略字段、支持自定义比较器、遇到第一个不等就返回，且对常见类型（time.Time、strings、slices）有优化路径。
- 基础用法：
if !cmp.Equal(got, want) { t.Errorf("mismatch: %v", cmp.Diff(want, got)) } - 忽略时间字段：
cmp.Options{cmp.Comparer(func(a, b time.Time) bool { return a.Equal(b) })}，比reflect手动删字段干净得多 - 忽略某个字段：
cmpopts.IgnoreFields(MyStruct{}, "ID", "CreatedAt")，不用再写DeepEqual前先赋零值 - 注意：
cmp.Diff输出是字符串，别直接塞进t.Error——长 diff 会刷屏，建议用t.Log(cmp.Diff(...))单独打
什么情况下还是得回退到 reflect.DeepEqual
不是所有场景都适合换库。当你的测试对象极简单（比如只比几个 int/string 字段），或者项目不允许引入第三方依赖时，reflect.DeepEqual 依然够用且无额外构建负担。
- 纯值类型组合（
struct{A int; B string}）+ 小数据量（ - CI 环境受限（如 air-gapped 构建），没法拉
go-cmp，硬加 vendor 代价大于收益 - 某些生成代码（如 protobuf 的 Go 结构体）自带
XXX_XXXEqual方法，比任何通用比较都快，优先用它
容易被忽略的兼容性坑
go-cmp 默认不比较 unexported 字段，而 reflect.DeepEqual 会——这在测试带私有状态的 struct 时可能让测试“意外通过”或“意外失败”。
立即学习“go语言免费学习笔记（深入）”；
- 如果结构体里有
mu sync.RWMutex这类非导出字段，cmp.Equal默认跳过，但你可能真想确认锁状态（虽然通常不该测） - 解决办法：
cmp.AllowUnexported(MyStruct{})，但要清楚这是在绕过封装边界 - 另一个坑：
cmp.Equal(nil, (*int)(nil))返回 true，而reflect.DeepEqual也返回 true；但cmp.Equal((*int)(nil), new(int))是 false，reflect.DeepEqual却是 true——指针 nil vs 非-nil 地址的语义差异，得看业务是否敏感
真正影响速度的从来不是函数名长短，而是你有没有意识到：测试里的“相等”从来不是数学意义上的，而是业务语义上的。字段要不要比、时间精度到秒还是纳秒、浮点误差容多少——这些决策点，比选哪个库更重要。
