Reflect.DeepEqual只比较导出字段且忽略struct tag，跳过未导出字段；nil切片与空切片相等，但nil map与空map不等；遇函数、channel等类型直接panic；无定制能力且性能差，生产环境应避免使用。
Reflect.DeepEqual 会忽略字段标签和未导出字段
Reflect.DeepEqual 比较的是值的「运行时结构」，不是源码定义。它只递归比较导出（首字母大写）字段的值，所有 unexported 字段（比如 name string）一律被跳过，无论有没有赋值、是否为零值。字段上的 struct tag（如 json:"name"）完全不参与比较——哪怕两个 struct 只有 tag 不同，DeepEqual 也会返回 true。
常见错误现象：
• 定义了带 json tag 的 struct，想用 DeepEqual 模拟序列化后比对，结果误判相等
• 包含私有缓存字段（如 mu sync.RWMutex），因字段被忽略，两个明显不同的实例却返回 true
- 如果需要包含未导出字段，必须手动实现
Equal方法或用cmp.Equal（需额外引入github.com/google/go-cmp/cmp） - 若依赖 tag 行为（如忽略某些字段），
DeepEqual无法满足，应改用序列化 + 字节比对，或自定义比较逻辑 - 注意：
sync.Mutex等非可比较类型字段即使导出，也会导致 panic ——DeepEqual内部调用==时失败
nil slice 和 nil map 在 DeepEqual 中表现不一致
Go 的 nil 值在反射比较中不是统一处理的。DeepEqual 认为 nil []int 和 []int{} 相等，但 nil map[string]int 和 map[string]int{} **不相等**。这是由底层实现决定的：slice header 为全零即视为 nil，而 map header 即使为空也含运行时指针，nil map 的 header 全零，空 map 则非零。
使用场景：
• 测试中初始化 struct 字段常混用 nil 和空集合
• API 响应结构体中 map 字段可能为 nil 或显式初始化为空
立即学习“go语言免费学习笔记（深入）”；
- 对 slice：放心用
DeepEqual，nil和空切片可互换 - 对 map：必须保持初始化方式一致，否则比较失败；建议统一用
make(map[T]U)初始化，避免nil - 若无法控制初始化方式，可在比较前做归一化：
if m == nil { m = make(map[string]int) }
函数、channel、unsafe.Pointer 类型直接 panic
Reflect.DeepEqual 遇到函数值、channel、unsafe.Pointer、complex64/128 时，会立即 panic 并报错 panic: reflect: DeepEqual not defined on func。这不是比较失败，而是根本禁止参与比较——哪怕它们嵌套在 struct 或 map 深层，只要路径上存在这类类型，整个调用就崩。
常见错误现象：
• struct 中塞了个 func() error 字段用于 mock，测试时直接 panic
• 使用 context.Context（内部含 cancelFunc）作为 struct 字段，DeepEqual 崩溃
- 解决方案不是“绕过”，而是提前过滤：比较前用
reflect.Value.Kind()检查字段类型，跳过函数/channel 等不可比类型 - 更稳妥的做法是：把这类字段抽离到独立变量，不在待比较数据结构中携带
- 别试图用
fmt.Sprintf转字符串再比——函数地址每次不同，channel 地址也变，毫无意义
性能差且无法定制比较逻辑
Reflect.DeepEqual 是纯反射实现，没有缓存、不跳过零值字段、不做短路（即使第一个字段就不同，仍会继续遍历所有字段）。对深度大于 5、字段数超 20 的 struct，耗时明显高于手写比较或 cmp.Equal。更重要的是，它不支持任何定制：无法忽略某个字段、无法用近似浮点比较、无法按业务规则处理时间字段。
使用场景：
• 单元测试中简单断言小结构体
• 临时调试打印后肉眼核对（不推荐）
- 生产代码或高频调用场景，务必避免
DeepEqual；优先手写Equal方法 - 需要灵活性时，用
cmp.Equal(x, y, cmp.Comparer(func(a, b time.Time) bool { return a.UTC().Truncate(time.Second) == b.UTC().Truncate(time.Second) })) - 注意：
cmp.Equal默认也不比较 unexported 字段，需加cmp.Exporter选项才可访问私有字段
真正难处理的永远是那些「看起来一样但语义不同」的字段：time.Time 的时区、float64 的精度、string 的 Unicode 归一化——DeepEqual 对这些一概不管，它只管内存布局是否一致。
