%p打印指针地址是判断值拷贝还是共享引用的铁证：对值类型用&v得栈地址（每次不同），对指针用p得所指内存地址（相同即共享）；结合pprof和delve可验证内存真实状态。
打印指针地址能直接暴露值拷贝还是共享引用
日志里只打结构体内容，根本看不出是副本还是同一块内存。真正有用的是 %p——它输出的是变量本身的地址（对指针则是其存储的地址），这才是判断“是否共享”的铁证。
- 对值类型变量用
&v打印：得到的是该副本在栈上的地址，每次传参或赋值都会变 - 对指针变量用
p打印：得到的是它指向的堆/栈地址；若多个指针日志中地址一致，说明它们真正在操作同一份数据 - 闭包中循环捕获指针时，
fmt.Printf("goroutine %d ptr: %p", i, &item)常发现所有 goroutine 都在改同一个&item地址——这是典型误用
结构体指针字段未初始化导致日志输出 <nil></nil> 而非 panic
结构体里嵌了 *string 或 *User 字段，但没显式赋值，日志里一打印就是 <nil></nil>，程序却不崩溃。这不是安全，而是隐患延迟爆发。
- 日志中看到
user.Name: <nil></nil>，不代表字段可忽略——后续某处*u.Name解引用就会 panic - 用
log.Printf("name ptr: %p, value: %v", u.Name, u.Name)可同时确认地址和解引用结果，比单看%v更可靠 - 结构体初始化时别依赖零值，显式写
Name: new(string)或Name: &defaultName，让日志和行为都明确
pprof + 日志交叉验证：怀疑内存泄漏时看指针存活路径
日志里反复出现某个结构体 ID，但 pprof 的 top 却显示对应类型分配量激增——说明这些对象没被释放，而日志可能是唯一线索。
- 启动 pprof：
import _ "net/http/pprof"并go http.ListenAndServe(":6060", nil) - 在关键逻辑前加日志：
log.Printf("created user %d at %p", u.ID, u)，记录指针地址 - 访问
http://localhost:6060/debug/pprof/heap?debug=1，搜索该地址，看是否还在堆上；对比多次快照，确认是否持续增长 - 特别注意全局 map 中存的
*User：日志里地址反复出现，pprof 里又长期不释放，基本就是忘了delete(m, key)
delve 调试时用 p 和 exa 看穿日志背后的内存真相
日志说 status=active，但业务逻辑却走到了 else 分支？可能结构体字段已被意外覆盖，而日志只打了表面值。
立即学习“go语言免费学习笔记（深入）”；
- 断点停住后执行
p u.Status：看当前值 - 再执行
exa -c 16 &u.Status：查看该字段起始地址往后 16 字节的原始内存，确认是否被相邻字段越界写入 - 对 slice 类型字段，
p u.Data显示长度和底层数组地址，p *(*[]byte)(u.Data)（需类型断言）可强制解引用看真实内容——日志里截断的"data: [1 2 3 ...]"可能掩盖了后面的真实字节
%p、pprof 地址、delve 内存视图串起来，才真正构成指针问题的证据链——而多数人只用了第一环。 
