go struct 的 == 行为自1.0起完全由字段类型和类型定义一致性决定，无版本差异；含不可比较字段、匿名/具名类型不一致、嵌套类型不匹配等均导致编译失败，reflect.deepequal语义稳定但不调用equal方法。
Go 语言中 struct 的 == 行为在不同版本间没有变化——自 Go 1.0 起，struct 是否支持 == 完全由其字段类型和类型定义一致性决定，编译器规则稳定未改。所谓“版本差异”多是开发者误将自己代码中类型定义、字段变更或反射使用方式的变动，归因于 Go 版本升级。
struct == 编译失败：不是版本问题，是字段类型问题
只要 struct 含有不可比较字段（[]T、map[K]V、func()、unsafe.Pointer 等），无论 Go 1.18 还是 Go 1.23，都会在编译时报 invalid operation: cannot compare ... (struct containing ... cannot be compared)。
- 常见错误现象：
type User struct { Name string Roles []string }，直接写u1 == u2必报错 - 别试图升级 Go 版本来“修复”它——这是语言规范，不是 bug
- 数组（
[3]int）可比较，切片（[]int）不可比较，这个分界线从不模糊
匿名 struct 和具名 struct 比较失败：类型名不一致就不是同一类型
哪怕两个 struct 字段完全一样，一个用 struct{ X int }，一个用 type S struct{ X int }，它们就是不同类型，== 直接拒绝编译，且该规则在所有 Go 版本中一致。
- 测试中高频出错：写
got := fn() ; want := struct{X int}{1}→ 报cannot compare struct{} == struct{} - 正确做法：复用同名类型，或统一用
reflect.DeepEqual - 嵌套时也严格检查：外层
type A struct{ B struct{X int} }和type A struct{ B BType }中的BType不同，整个A就不可比
reflect.DeepEqual 行为稳定，但要注意它不调用自定义 Equal 方法
reflect.DeepEqual 在所有 Go 版本中语义一致：逐字段递归比较值，忽略方法集，不处理循环引用（会 panic），对 nil slice 和空 slice 视为相等。
- 性能影响：对含大量嵌套或大 map 的 struct，反射开销明显；Go 1.21+ 无优化，别指望新版更快
- 浮点比较仍是位级：NaN != NaN，和
==一致；需容差请手动提取字段处理 - 自定义
Equal(other T) bool方法不会被DeepEqual调用——它只看内存布局，不走方法集
真正容易被忽略的是：当 struct 字段顺序错一位、或某个字段从 int 改成 *int、或加了个未导出字段，都可能让原本能 == 的类型突然失效——这种变化跟 Go 版本无关，只跟你的代码是否满足语言的可比较性约束有关。
