DeepEqual 判定值一致性而非指针一致性，解引用后严格按类型比较；类型不匹配会 panic，nil 指针仅同类型才相等；判断同一对象须用 == 或反射取地址。
Go 中 DeepEqual 判定的是值一致性，不是指针一致性
它只看两个值“长得一样不一样”，完全忽略底层是否指向同一块内存。哪怕两个 *int 指向不同地址，只要解引用后数值相等，DeepEqual 就返回 true；反过来，两个相同地址的指针如果类型不匹配（比如 *int 和 *int32），直接 panic。
- 常见错误现象：
DeepEqual(&a, &b)返回true，但后续修改a不影响b—— 误以为“相等 = 同一对象” - 使用场景：单元测试里验证函数输出结构是否符合预期，比如比较两个
map[string][]*User - 性能影响：递归遍历所有字段，对含循环引用的结构会无限递归并 panic；对大嵌套结构（如千级 slice）明显慢于
==
DeepEqual 对指针的处理逻辑：解引用 + 类型严格匹配
它不会比较指针地址本身，而是先检查类型是否一致，再尝试解引用比较。一旦类型不兼容（哪怕只是别名差异），立刻停止并返回 false 或 panic。
- 参数差异：
DeepEqual(nil, nil)返回true；但DeepEqual((*int)(nil), (*int32)(nil))panic，因为*int≠*int32 - 容易踩的坑：自定义类型带未导出字段时，即使字段值全等，
DeepEqual也可能因无法访问而返回false（取决于结构体是否可比较） - 兼容性注意：Go 1.21+ 对某些内建类型（如
unsafe.Pointer）的比较行为更严格，旧代码可能突然失败
想判断“是不是同一个对象”？别用 DeepEqual，改用 == 或 reflect.ValueOf(x).Pointer()
DeepEqual 的设计目标从来就不是身份判定。真要确认两个指针是否指向同一地址，必须用原生 ==（仅限相同类型指针），或通过反射取地址比较。
- 实操建议：对
*T类型，直接写p1 == p2；若类型不同但你知道底层是同一块内存，用reflect.ValueOf(p1).Pointer() == reflect.ValueOf(p2).Pointer() - 为什么这样做：避免把“值相等”误当作“对象同一”，尤其在缓存、事件监听、资源归属判断等场景下，语义完全不同
- 性能对比：
==是单条 CPU 指令，DeepEqual是深度遍历 —— 差几个数量级
DeepEqual 底层其实没那么神秘，就是递归调用 equal 函数
源码在 src/reflect/deepequal.go，核心是 equal 函数，按类型分治：基础类型直接 ==，slice/map/struct 逐项递归，指针则解引用后继续。没有哈希、没有缓存、不跳过零值字段。
立即学习“go语言免费学习笔记（深入）”；
- 容易被忽略的地方：它不支持自定义比较逻辑（比如忽略时间精度、忽略 map 顺序），也不处理 context.Context 或 sync.Mutex 等不可比较类型
- 替代方案提示：需要灵活控制比较行为时，别硬改
DeepEqual，用cmp.Equal（来自github.com/google/go-cmp/cmp），它支持选项、过滤、自定义比较器 - 调试技巧：遇到意外
false，用fmt.Printf("%#v\n%#v", a, b)看字面量差异，比猜类型匹配问题快得多
