Go中接口==比较的是动态类型与动态值是否完全一致，而非逻辑相等；指针存入接口后比较的是地址而非内容，需类型断言后手动比较或实现Equal方法。
Go 中接口比较的底层规则
两个接口变量能直接用 == 比较，但结果往往和你想的不一样——它不是比“里面装的东西是否逻辑相等”，而是比“动态类型 + 动态值”是否完全一致。如果接口里存的是指针，那比较的就是那个指针的地址值，不是它指向的内容。
常见错误现象：interface{}(ptrA) == interface{}(ptrB) 返回 false，即使 ptrA 和 ptrB 指向相同结构体且字段全等。
- 只有当两个接口的动态类型完全相同（包括包路径）、且动态值可比较（如指针、map、slice 本身不可比较，但 *T 可比较）时，
==才不会 panic - 如果任一接口是 nil，另一个非 nil，则直接为
false；两个都是 nil 接口才为true - 指针存进接口后，
==比的是地址，不是解引用后的值 —— 这是绝大多数人踩坑的起点
想比“指针指向的内容”该怎么做
不能依赖接口本身的 ==，得手动取出值再比。前提是知道具体类型，或者用反射做通用比较（但代价高、不推荐日常用）。
使用场景：测试中验证函数返回的接口是否包装了预期的结构体指针；RPC 响应校验；mock 对象断言。
立即学习“go语言免费学习笔记（深入）”；
- 最稳妥：类型断言后比较底层值，例如
if v, ok := iface.(**MyStruct); ok { return *v == *expected } - 若类型不确定但确定是 *T，可用
reflect.DeepEqual，但注意它对指针是解引用比较：reflect.DeepEqual(ptrA, ptrB)比的是内容，不是地址 - 避免对
interface{}直接调reflect.DeepEqual，容易因 nil 指针 panic；先判空或断言
为什么不能直接用 reflect.DeepEqual(interface{}, interface{})
因为 reflect.DeepEqual 对接口类型的处理是：先看接口是否 nil，否则取出其动态值再递归比较。但问题在于，如果两个接口分别装了 *T 和 T，即使内容一样，也会返回 false —— 类型不同。
错误示例：var a interface{} = &MyStruct{X: 1}; var b interface{} = MyStruct{X: 1}; reflect.DeepEqual(a, b) → false，不是 bug，是设计如此。
-
reflect.DeepEqual不忽略类型差异，哪怕只是值 vs 指针 - 如果两个接口都装指针，且指向可比较类型（如 struct、array），那它能正常工作
- 性能影响：每次调用都触发反射，比原生
==慢 10–100 倍，高频路径慎用
实际项目中更安全的判断模式
别试图让接口“自己懂怎么比”，而是把比较逻辑收归到具体类型上，比如定义 Equal(other *T) bool 方法，或实现 Equaler 接口。
这样既避开接口比较陷阱，又保留扩展性。Go 标准库的 url.URL、net.IP 都走这条路。
- 在业务结构体上加
Equal(other *YourType) bool，内部逐字段比较（含嵌套指针的解引用） - 如果必须通过接口传参，让接口要求实现
Equal(Equaler) bool方法，而不是依赖== - 切记：只要涉及指针语义的相等性，就不要把判断权交给接口本身的
==或reflect.DeepEqual—— 它们根本不是为你这个需求设计的
真正难的不是写对一行比较代码，而是意识到 Go 的接口比较从来就不承诺“语义相等”。这点在跨 package 传递指针时尤其容易被忽略。
