安全，但仅限于比较是否指向同一块内存地址；go允许相同类型指针用==比较地址，不支持解引用或值比较，nil指针间恒等，reflect.deepequal不可替代地址比较。
Go 中两个指针变量用 == 比较是否安全？
安全，但仅限于比较「是否指向同一块内存地址」。Go 规范明确允许对相同类型（或可互相转换）的指针使用 == 和 !=，结果是布尔值，语义清晰：地址相同即为真。
常见误用是拿它判断两个指针所指向的值是否相等——这不行，== 不会解引用，也不会递归比较结构体字段。
- 支持比较的指针类型包括：
*int、*string、*struct{}、unsafe.Pointer等 - 不支持比较的场景：
[]int（切片）、map[string]int、func()等非指针类型，哪怕底层有指针字段也不行 - 注意：接口值（
interface{}）包含动态类型和数据指针，两个接口变量用==比较的是整个接口头（含类型和值），不是单纯比内部指针
为什么 *T 类型的 nil 指针之间 == 为 true，但与未初始化 struct 字段中的嵌入指针比较可能出人意料？
因为 Go 中所有零值指针（包括显式赋值 nil 或未初始化的指针字段）都表示空地址（0x0），所以任意两个 *T 类型的 nil 值用 == 比较恒为 true。
但陷阱常出现在结构体字段中：
- 如果结构体字段是
*T类型，且未显式初始化，它的零值就是nil，与其他nil指针相等 - 但如果字段是
T（非指针），而你错误地取了它的地址（如&s.field），这个地址永远不为nil，即使s.field是零值 - 更隐蔽的是：从 map 或 channel 读取一个未设置的键对应值，若该值是指针类型，得到的是
nil；但从 slice 索引越界 panic，不会返回nil指针
用 reflect.DeepEqual 替代指针比较？什么时候不该用？
reflect.DeepEqual 比较的是值内容，不是地址。它会递归遍历结构体、切片、map 等，适合验证逻辑等价性，但完全不适合替代指针相等性判断。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
典型反模式：
- 用
reflect.DeepEqual(p1, p2)判断两个*MyStruct是否指向同一实例 —— 效率极低，且无法区分“同址”和“同值不同址” - 对含函数、
unsafe.Pointer、含不可比较字段（如sync.Mutex）的结构体调用它会 panic - 性能开销大：每次调用都触发反射运行时路径，比
==慢 100 倍以上（尤其对大结构体）
真正需要深度比较时，应先确认是否必须绕过指针语义；否则优先用自定义 Equal() 方法或直接比地址。
如何通过指针比较优化内存访问（如避免重复解引用或缓存失效）？
指针相等性本身不优化内存，但它能帮你做「快路径判断」，从而跳过昂贵操作。关键不是比较本身，而是比较后的分支选择。
- 缓存一致性场景：比如某个函数接收
*Node，内部要查其父节点是否等于某已知节点，用node.parent == cachedRoot比node.parent.ID == cachedRoot.ID更快（避免两次字段访问 + 可能的 cache miss） - 避免重复初始化：在 sync.Once 或 lazy-init 结构中，常用
if p == nil快速退出，而不是先解引用再判断字段 - 注意逃逸分析影响：过度依赖指针比较可能让本可栈分配的对象逃逸到堆，得用
go build -gcflags="-m"验证实际分配行为
真正影响性能的是后续是否触发内存加载、是否利用 CPU 缓存局部性，而不是 == 这条指令本身 —— 它编译后通常就是一条 cmp 汇编。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
