go中==比较规则：值类型逐字节比，指针比地址，接口先比类型再比值，map/slice/channel/func不可比。
值类型用 == 比较时，是逐字段深拷贝式对比
Go 的值类型（如 struct、[3]int、string）用 == 判断相等，本质是按内存布局逐字节比较。只要所有可导出/可比较字段都相等，就返回 true。
但注意：含不可比较字段的 struct 无法用 == —— 比如字段是 map、func、[]byte（切片）、或含这些类型的嵌套结构。此时编译直接报错：invalid operation: cannot compare ... (struct containing []byte)。
-
string是值类型，==比较内容，安全高效 -
[4]int可比；[]int不可比（切片是引用类型，且本身不可比较） - 自定义
struct中只要所有字段都支持==，该 struct 就支持== - 空 struct
{}总是相等：{} == {}恒为true
指针类型用 == 比较，只看地址是否相同
指针变量的 == 不关心它指向的内容，只判断两个指针是否指向同一块内存地址。哪怕两个 *int 指向的值完全一样，只要地址不同，== 就是 false。
常见误用场景：想判断两个指针“内容是否相等”，却写了 p1 == p2，结果永远 false（除非真指向同一变量）。
立即学习“go语言免费学习笔记（深入）”；
- 比较指针内容是否相等，得解引用：
*p1 == *p2（前提是p1和p2都非 nil） - nil 指针可参与
==：任何*T类型的 nil 值之间都相等 - 不同变量的地址一定不同，即使它们刚被初始化为相同值：
var a, b int = 1, 1; &a == &b是false
接口类型用 == 比较，行为取决于底层值
接口变量 == 的规则最易踩坑：它先判断动态类型是否一致，再对底层值做对应类型的 == 比较。一旦类型不同，直接 false；类型相同但值不等，也 false。
典型陷阱是 nil 接口和 nil 指针混用：var s *string; var i interface{} = s，此时 i == nil 是 false（因为 i 的动态类型是 *string，值是 nil，但接口本身非 nil）。
- 只有当接口的动态类型和值都为 nil 时，
i == nil才为true - 含 slice/map/func 的接口无法用
==比较（因底层值不可比较）→ 运行时报 panic：panic: runtime error: comparing uncomparable type ... - 建议：需要判等的接口，优先用类型断言后比较底层值，或实现
Equal()方法
map/slice/channel/func 不支持 ==，别硬试
这四类类型在 Go 中被明确禁止用 == 比较，编译器会直接拒绝。不是性能问题，是语言设计上就不允许——因为它们的“相等性”没有唯一合理的定义（比如 map 的遍历顺序不确定，slice 底层数组可能重叠）。
试图写 m1 == m2 或 s1 == s2，编译错误信息很明确：invalid operation: cannot compare ... (map has no == operator)。
- 要比较 map 内容是否一致，用
reflect.DeepEqual（注意性能开销和循环引用风险） - 比较 slice 是否相等，推荐
bytes.Equal（仅限[]byte），或手动循环len+==元素 - channel 和 func 只能比较是否为同一个实例（即指针地址），但语法上不支持
==，只能用== nil或传参时做身份判断
真正容易被忽略的是接口比较时的类型一致性，以及 struct 中混入不可比较字段后导致整个类型失效——这种错误往往在新增字段后才暴露，而且不报编译错，只在用到 == 的地方才炸。
