deepequal 遇循环引用会栈溢出，因无环检测而无限递归；应改用 go-cmp（自带环检测）或手动实现带 visited map 的比较逻辑，避免直接使用 reflect.deepequal 处理含指针互引或 sync.mutex 的结构。
DeepEqual 在循环引用结构里直接 panic
Go 的 reflect.DeepEqual 遇到含循环引用的结构（比如树节点互相持有父/子指针、图结构、带 sync.Mutex 的 struct）会无限递归，最终栈溢出或触发 runtime.fatalerror。这不是 bug，是设计使然——它没做环检测，只管一层层钻下去。
常见错误现象：runtime: goroutine stack exceeds 1000000000-byte limit 或直接 fatal error: stack overflow；调试时发现两个明显不同的变量却卡在 DeepEqual 调用里不动。
- 别在测试中对含指针互引的 struct 直接用
DeepEqual，哪怕只是临时比较 - 含
sync.Mutex、sync.RWMutex的 struct 也得小心——它们内部有不可比较字段，DeepEqual会绕过但可能触发深层循环 - JSON 序列化再比字符串？不行，丢失类型信息且性能差，还可能因浮点精度、map 键序等问题误判
用 reflect.Value 自实现带环检测的比较逻辑
核心思路是维护一个已访问地址映射表（map[uintptr]bool），每次进入指针/接口/切片/映射前先查地址是否见过。注意：必须用 Value.UnsafeAddr() 或 Value.Pointer() 获取底层地址，不能用 &v——反射值本身是副本。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 只对
Kind() == reflect.Ptr、reflect.Map、reflect.Slice、reflect.Interface这几类做环检测，其他类型（int、string、struct 字段值）无需记录 - 用
unsafe.Pointer转成uintptr当 key，避免 gc 移动导致地址失效（实际 Go 1.20+ 对未逃逸的反射值地址是稳定的，但保险起见仍推荐uintptr） - 递归调用前先
if visited[addr] { return true }，命中即短路返回 true（视为“相同”，因为已确认路径一致）
示例关键片段：
func deepEqualWithCycle(v1, v2 reflect.Value, visited map[uintptr]bool) bool {
if !v1.IsValid() || !v2.IsValid() {
return v1.IsValid() == v2.IsValid()
}
if v1.Type() != v2.Type() {
return false
}
switch v1.Kind() {
case reflect.Ptr:
p1, p2 := v1.Pointer(), v2.Pointer()
if p1 == 0 && p2 == 0 {
return true
}
if p1 == 0 || p2 == 0 {
return false
}
if visited[p1] && visited[p2] {
return true // 已访问过，认为结构一致
}
visited[p1], visited[p2] = true, true
return deepEqualWithCycle(v1.Elem(), v2.Elem(), visited)
// ... 其他 kind 处理省略
}
}
第三方库选型：go-cmp 是更稳的选择
go-cmp（Google 出品）默认就带环检测，且支持自定义选项（忽略字段、转换函数、排序比较等）。它不依赖 reflect.DeepEqual，而是自己遍历并缓存已见地址，行为更可控。
使用场景：
- 单元测试里替代
reflect.DeepEqual，尤其涉及 ORM 模型、AST 节点、配置树等易循环结构 - 需要忽略某些字段（如
UpdatedAt时间戳）时，用cmpopts.IgnoreFields比手写跳过逻辑干净得多 - 对比含
func或unsafe.Pointer的 struct？go-cmp默认 panic，但你可以加cmp.AllowUnexported或自定义Transformer
最小启动示例：
import "github.com/google/go-cmp/cmp"
diff := cmp.Diff(obj1, obj2)
if diff != "" {
t.Errorf("mismatch (-want +got):\n%s", diff)
}
哪些情况其实根本不用 DeepEqual
很多所谓“要深比较”的场景，本质是验证行为而非内存结构。硬上 DeepEqual 反而掩盖设计问题。
- API 响应体比较？优先用字段断言：
if got.Name != want.Name，清晰、快、报错准 - 数据库模型比较？用主键+版本号判断是否同一记录，而不是比整个 struct
- 配置对象是否变更？加个
Version() string方法，基于 JSON 序列化哈希，避开指针和私有字段干扰 - 测试中构造了带循环的 fake 对象？重构掉循环——比如把父引用改成 ID 字段，测试时用 map 模拟查找
环检测不是银弹。真正难的从来不是怎么绕过 panic，而是识别出：这个结构本就不该被“深比较”。
