这是ASLR导致的正常现象，每次程序启动栈地址随机变化；应使用指针相等比较而非地址字符串；nil panic定位需结合防御检查、dlv调试或关闭内联；pprof可分析指针引发的内存泄漏；delve中用print *p、whatis等命令查看指针内容。
为什么 fmt.Printf("%p", &x) 显示的地址每次都不一样
这不是 bug，是 Go 运行时启用 ASLR（地址空间布局随机化）的正常表现。每次启动程序，栈、堆、全局变量的基址都会变化，&x 指向的栈地址自然不同。调试时若想确认两个指针是否指向同一变量，别比对地址字符串，改用 == 直接比较指针值：
if p1 == p2 { /* same underlying object */ }。注意：只对同类型指针有效；跨类型（如 *int 和 *int32）需显式转换才能比较，否则编译报错。
nil 指针 panic 却没显示哪一行解引用了
常见于嵌套结构体字段访问或方法链调用，例如 user.Profile.Address.City 中任意一级为 nil，panic 信息只显示 panic: runtime error: invalid memory address or nil pointer dereference，不标出具体字段。解决办法有三：
- 用
go run -gcflags="-l" main.go关闭内联，让 panic 栈更准确 - 在可疑链路前加防御性检查：
if user != nil && user.Profile != nil && user.Profile.Address != nil { ... } - 用 Delve 调试器单步执行，在 panic 前观察各变量值：
dlv debug→break main.go:42→continue→print user.Profile
用 pprof 查指针导致的内存泄漏
指针持有导致对象无法被 GC，典型场景是把局部变量地址存入全局 map 或 channel 后长期未清理。要定位这类问题：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 启动 HTTP pprof 端点：
import _ "net/http/pprof"，运行后访问http://localhost:6060/debug/pprof/heap - 用
go tool pprof http://localhost:6060/debug/pprof/heap进入交互模式 - 输入
top查看最大分配者，再用list <funcname>定位到具体哪行取了地址（如&item）并存入了长生命周期容器 - 特别注意
sync.Pool的 Put/Get 不会自动清空，若 Put 了含指针的结构体，且该结构体又间接引用了大对象，Pool 就成了泄漏温床
Delve 中怎么查看指针指向的实际内容
在 dlv 断点处，print *p 只显示一层解引用，对嵌套结构体或 slice 很难看清。推荐组合使用：
-
print p：看指针本身地址和类型 -
print *p：看直接指向的值（若非 nil） -
print **p（仅当p是**T）：多级解引用 -
whatis p：确认指针类型，避免误判（比如你以为是*string，其实是*struct{...}） - 对 slice/map/channel 类型指针，
print *p可能输出内部结构（如len/cap），但不如dump *p清晰——不过注意dump是 dlv 的扩展命令，需较新版本支持
interface {}(0x...)，用 print *(**interface{})(unsafe.Pointer(&i)) 手动探查（慎用，仅调试）。立即学习“go语言免费学习笔记（深入）”；
