go中指针相等性比较应直接使用p == q，它原生支持、语义明确、性能最优；常见错误包括误用地址字符串比较、值接收者中取形参地址、类型不兼容及忽略nil检查。
== 就够了，只要两个指针类型相同且都指向同一地址（或同为 nil），p == q 就返回 true。这是 Go 原生支持、语义明确、性能最优的方式——不需要反射、不用 unsafe、更不要解引用比较内容。
为什么 p == q 有时返回 false，但打印出来地址“看起来一样”？
这不是比较逻辑的问题，而是你误把地址字符串当成了可比依据。Go 启用 ASLR，每次运行栈地址都变，fmt.Printf("%p", &x) 输出的只是当前快照，不能用于判断相等性。真正可靠的只有 == 运算符本身。
- 别写
fmt.Sprintf("%p", p) == fmt.Sprintf("%p", q)—— 地址字符串格式可能因平台/版本不同而变化，且毫无必要 - 调试时直接写
if p == q { ... }，让编译器和运行时决定 - 在
dlv中可用print p == q实时验证
值接收者里取地址导致指针永远不等
这是最常踩的坑：在值接收者方法中对形参取地址，得到的是副本的地址，不是原始变量的地址。
- 错误写法：
func (m Map) NewFragment() Fragment { return Fragment{Map: &m} }→&m指向栈上临时副本，&originalM指向原变量，二者必然不等 - 正确做法：改用指针接收者
func (m *Map) NewFragment() Fragment { return Fragment{Map: m} }，直接传递原指针 - 若必须保留值接收者，又需生成指向原始对象的指针，请显式传入
origin *Map参数，而非依赖&m
比较前要确认类型兼容，否则编译失败
Go 对指针比较有严格类型检查：*int 和 *int64 即使底层都是整数，也不能用 == 比较；*string 和 string 更不行。
- 常见错误：结构体字段是
*string，却直接和string变量比较 → 编译报错invalid operation: cannot compare - 正确做法：统一类型，或显式解引用，如
*s1 == s2（前提是s1非nil） - 注意
nil指针可与同类型其他指针比较，但nil与未初始化的接口值、切片、map 等不是一回事
真正容易被忽略的点在于：指针相等性本身从不出错，出错的永远是「你以为它该相等」的假设——比如没意识到值接收者会复制、没检查指针是否为 nil 就解引用、或者混淆了指针类型和基础类型。写判断时，先盯住变量声明和赋值路径，再动 ==。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
