Go中interface{}不能直接用==比较，除非都为nil；安全方案是reflect.DeepEqual，但性能差；类型已知时应优先用类型断言+类型检查。
Interface变量直接用==会panic
Go里interface{}不是引用类型，但也不是能随便比较的值类型。两个interface{}用==只有在都为nil时安全；只要其中任一非nil，运行时就可能触发panic: runtime error: comparing uncomparable type xxx——尤其是当底层是切片、map、func或包含这些字段的结构体时。
根本原因：Go只允许比较“可比较”（comparable）类型的值，而interface{}的动态类型若不可比较，整个比较就非法。
- 常见踩坑：把
[]int、map[string]int、func()塞进interface{}后直接== - 安全场景：两个
interface{}都装的是int、string、struct{}这类可比较类型，且值相等——但这不保险，因为调用方无法控制传入类型 - 结论：别信
==，它不是接口比较的解法
用reflect.DeepEqual做深度相等判断
最通用的方案是reflect.DeepEqual，它能递归比较任意两个值，包括interface底层的各种类型（哪怕含slice/map），且不会panic。
但它有代价：
- 性能差：反射开销大，不适合高频调用（如循环内、热路径）
- 语义注意：对浮点数NaN、函数、不支持比较的struct字段行为特殊（比如NaN==NaN返回false，但
DeepEqual认为相等） - nil指针和nil slice/map会被视为相等，符合直觉
示例：
import "reflect"
a := interface{}([]int{1, 2})
b := interface{}([]int{1, 2})
fmt.Println(reflect.DeepEqual(a, b)) // true
自定义比较逻辑前先确认类型是否一致
如果已知interface里大概率是某几种具体类型（比如只可能是int、string或time.Time），用类型断言+分支比反射快得多，也更可控。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
关键点在于：必须先用reflect.TypeOf或双断言确认两个interface的动态类型完全相同，再比较值。类型不同直接返回false，避免错误断言。
- 错误写法：
v1.(string) == v2.(string)—— 若v2不是string会panic - 正确写法：用
v1, ok1 := x.(string); v2, ok2 := y.(string); if ok1 && ok2 { return v1 == v2 } - 更稳写法：用
reflect.TypeOf(x) == reflect.TypeOf(y)统一判型，再分发到对应比较函数
json.Marshal后比较字符串（仅限简单场景）
对纯数据结构（无func、channel、不导出字段、无循环引用），可以走json.Marshal序列化再比字符串。代码短、不用反射、类型无关。
但风险明显：
- 字段顺序影响结果（Go struct默认按声明顺序，但json包不保证；加
json:"xxx"标签也不解决嵌套map键序问题） - 浮点精度丢失、time.Time格式依赖
MarshalJSON实现 - 性能比
reflect.DeepEqual还差（涉及内存分配、编码、GC） - 遇到不可序列化类型（如
func）直接panic
只建议用于测试中临时验证，或明确知道输入受限的CLI工具。
类型断言分支和reflect.DeepEqual之间没有银弹。实际选哪个，取决于你能否约束输入类型、性能敏感度、以及是否愿意为安全多写几行类型检查。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
