go中同类型指针用==比较是安全的，仅比较地址值而非内容，nil指针可与同类型指针比较；但不可用于判断逻辑相等，结构体指针应避免依赖==判断业务等价性。
Go 中两个指针用 == 比较是否安全
安全，但仅限于同类型指针且指向同一对象（或都为 nil）时才有明确语义。Go 允许对相同类型的指针变量直接用 == 比较，底层比的是地址值，不是所指内容。
常见错误现象：用 == 比较两个结构体指针，发现结果为 false，但结构体字段完全一样——这是正常行为，因为它们指向不同内存地址。
- 只有
*T和*T类型才能直接比较；*int和*int64不行，编译报错invalid operation: cannot compare - nil 指针可与任意同类型指针比较：
p == nil是标准写法 - 不支持对切片、map、func、chan 的指针做
==比较（因为它们本身是引用类型，再取指针后类型可能不可比较）
什么时候不该用 == 比较指针
当你真正想判断“两个指针指向的内容是否逻辑相等”，而不是“是否指向同一块内存”时，== 就失效了。
典型场景：缓存中查一个对象，你传入一个新构造的 &User{ID: 123} 去和已存在的 *User 比较——地址必然不同，但业务上你关心的是 ID 是否一致。
立即学习“go语言免费学习笔记（深入）”；
- 结构体指针之间不要依赖
==判断业务等价性，改用字段级比较或实现Equal()方法 - 接口值包含指针时，
==行为取决于接口的动态类型是否可比较；若接口里装的是map或slice，即使底层是指针也会 panic - 通过
unsafe.Pointer转换后的指针，不能直接用==比较，除非你明确知道它们来自同一分配源且未被 GC 移动
nil 指针比较的几个易错点
nil 在 Go 中不是字面量，而是预声明的零值，它没有固定类型，但会根据上下文推导为对应指针类型。这导致一些隐式转换陷阱。
-
var p *string; if p == nil { ... }✅ 正确 -
if p == (*string)(nil) { ... }✅ 显式类型转换也行，但没必要 -
if p == interface{}(nil) { ... }❌ 编译失败：类型不匹配，interface{}不是*string -
if p == (interface{})(nil) { ... }❌ 同样失败，类型断言不改变可比较性规则 - 函数返回
interface{}包裹的指针时，不能直接跟nil比：应先类型断言再比，或用if v == nil判空（前提是 v 是 interface 类型且底层值为 nil）
性能与逃逸分析的影响
指针比较本身开销极小（就是一次机器字长的整数比较），但决定“要不要取指针”会影响逃逸分析，进而影响性能。
比如你频繁把局部变量取地址传参，可能导致本可栈分配的对象被抬升到堆上，GC 压力上升——这时比较指针是否相等反而成了次要问题，根源在设计层面是否真需要指针语义。
- 小结构体（如
type Point struct{ X, Y int }）按值传递通常比传*Point更快，也避免了指针比较带来的歧义 - 如果函数签名强制要求指针（例如要修改原值），那比较指针地址才有意义；否则优先考虑值语义
- benchmark 时别只测
==速度，要结合逃逸分析看整体分配行为：go build -gcflags="-m" main.go
