reflect.DeepEqual 不按预期工作因默认对func、unsafe.Pointer等panic，NaN不相等，静默忽略未导出字段，time.Time精度敏感，且不调用自定义Equal方法；应在其上封装钩子处理特殊类型。
为什么 reflect.DeepEqual 有时不按预期工作
它确实能比较嵌套结构，但默认行为在遇到 func、unsafe.Pointer、含不可比较字段的 struct（比如含 map 或 slice 字段但本身未导出）时直接 panic；更隐蔽的是，它对浮点数 NaN 的处理是「NaN != NaN」，而有些业务场景需要视为相等。
- 如果结构体里有未导出字段，
reflect.DeepEqual会跳过——不是报错，而是静默忽略，容易误判为“相等” - 比较含
time.Time的对象时，若精度不同（比如一个带纳秒、一个只到秒），结果为 false，但你可能只关心语义时间是否一致 - 自定义类型实现
Equal方法后，reflect.DeepEqual不会调用它，完全走反射路径
如何安全替换或封装 reflect.DeepEqual
不要从零写反射遍历，而是在它基础上加可控钩子。核心是用 reflect.Value 手动展开，遇到特定类型（如 float64、time.Time、自定义类型）时委托给用户逻辑。
- 用
reflect.Value.Interface()提取值前，先检查Value.CanInterface()，避免 panic - 对
float32/float64，改用math.IsNaN+math.Abs(a-b) 判断 - 对
time.Time，统一转成UnixNano()再比，或提供可选的精度参数（如time.Second） - 预留
EqualFunc类型回调：func(a, b interface{}) bool，在递归进入前先查是否命中自定义规则
示例片段：
func DeepEqual(a, b interface{}, opts ...DeepEqualOption) bool {
cfg := defaultConfig()
for _, opt := range opts {
opt(cfg)
}
return deepValueEqual(reflect.ValueOf(a), reflect.ValueOf(b), cfg)
}
哪些字段必须显式排除或标准化
反射无法自动理解业务语义，像 ID、创建时间、缓存字段这类“存在即合理但不该参与比较”的内容，得靠约定而非推断。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 用 struct tag 标记跳过字段：
json:"-" diff:"skip"，解析时检查structField.Tag.Get("diff") == "skip" - 对 map/slice 元素，
reflect.DeepEqual默认按顺序比较；若业务允许无序，需先排序再比（比如对 slice 调用sort.Slice） - 指针比较要小心：
&a == &b是地址相等，但*a == *b才是值相等；封装函数应默认解引用，除非显式传入comparePointersAsValues: false
性能和循环引用怎么破
纯反射路径比原生 == 慢 10–100 倍，且遇到循环引用（A.field → B → A）会无限递归直到栈溢出。
- 用
map[uintptr]bool记录已访问的指针地址（value.UnsafeAddr()），每次进入前查重 - 对高频调用场景（如单元测试断言），考虑生成专用比较函数（用
go:generate+golang.org/x/tools/go/packages分析 AST） - 避免在热路径用泛型版
DeepEqual[T any]，因为类型擦除后仍走反射；真要性能，就为关键结构体手写Equal方法
最常被忽略的一点：没人在意 interface{} 底层是 nil 指针还是 nil 接口值——它们在反射里表现不同，但业务上往往该视为等价。这点必须在封装层做归一化处理。
