不可靠，因map遍历顺序随机且reflect.deepequal对nil/空slice、未导出字段、func、interface{}中类型不一致零值等场景处理失败；推荐用cmp.equal配合cmpopts定制化比较。
Testify 的 assert.Equal 对 map 深度比较是否可靠？
不可靠，尤其当 map 值含 slice、嵌套 Struct、指针或 Interface{} 时，assert.Equal 默认只做浅层反射比较，容易因 map 迭代顺序不一致或底层结构差异误判为不等。
- go 中 map 的遍历顺序是随机的，
reflect.DeepEqual（Testify 底层所用）虽能处理无序性，但遇到nilslice 和空 slice、未导出字段、func 类型值仍会失败 - 若 map value 是
interface{}，且实际存了不同底层类型的零值（如nilvs0），assert.Equal可能静默通过或 panic - 推荐显式使用
assert.EqualValues替代 —— 它强制忽略类型差异，只比对可转换后的值，对数字、布尔、字符串、基础复合类型更宽容
如何安全比对含 slice 或嵌套 struct 的 map？
必须先标准化数据结构，再交给 Testify；不能依赖默认行为。
- 对 map 中所有 slice 值，提前调用
sort.Slice排序（需确保元素可比），否则即使内容相同，因顺序不同也会被判定不等 - 嵌套 struct 若含 unexported 字段，
reflect.DeepEqual无法访问，直接返回 false；此时应改用cmp.Equal（来自 golang.org/x/exp/cmp）并配cmp.AllowUnexported - 避免在测试中直接比对含
time.Time的 map：微秒级差异常见，建议用cmp.Comparer(func(a, b time.Time) bool { return a.Truncate(time.Second).Equal(b.Truncate(time.Second)) })
为什么 assert.ObjectsAreEqual 不该用于 map 比较？
它只是 reflect.DeepEqual 的封装，且额外做了 String/bytes 转换，反而增加歧义和开销，对 map 没有任何增强。
- 源码里它会把非字符串类型强制转成
fmt.sprintf("%v")再比字符串 —— 这会让map[string]int{"a": 1}和map[string]int{"a": 01}看似相等（因输出都是map[a:1]），实则逻辑错误 - 遇到 NaN、-0、+0 等浮点边界值，字符串化后完全丢失语义，
assert.ObjectsAreEqual会给出错误结论 - 真要调试差异，不如直接用
cmp.Diff输出结构化差异，比看字符串日志高效得多
生产级测试中 map 比对的最小可行方案
别拼凑多个 assert，用一个稳定、可读、可调试的方案收口。
立即学习“go语言免费学习笔记（深入）”；
- 导入
golang.org/x/exp/cmp和golang.org/x/exp/cmp/cmpopts - 写断言时统一用：
assert.True(t, cmp.Equal(got, want, cmpopts.EquateEmpty(), cmpopts.SortSlices(func(a, b any) bool { return fmt.Sprint(a) - 如果 map key 是自定义类型，确保其实现了
Comparable（即支持 ==），否则 cmp 会 panic；这时得加cmp.Comparer显式定义相等逻辑
真正难的不是写对一行断言，而是保证所有测试用例里的 map 构造方式一致 —— 比如是否总用 make + 显式赋值，还是混用了字面量和 append。这点没人帮你检查，只能靠 code review 和 pre-commit hook 卡住。