%p只能格式化指针类型，传非指针变量会panic；输出的是当前运行时虚拟内存地址，受aslr影响，每次重启不同，仅适用于调试时判断指针是否相同。
Go 中 %p 只能格式化指针类型，传普通变量会 panic
直接对非指针变量用 %p，比如 fmt.Printf("%p", x)（x 是 int），Go 会报 panic: reflect: call of Value.Interface on zero Value 或更直白的类型错误。因为 %p 的语义就是“输出指针值所指向的地址”，底层依赖 reflect.Value 的指针校验，传入非指针就过不了这一关。
实操建议：
- 确保传给
%p的是显式指针类型：比如&x、new(int)、或已声明的*int变量 - 不要试图用
%p打印结构体字段地址（除非该字段本身是指针）；想打印结构体内某个字段的地址，得写成&s.field - 如果变量是 nil 指针，
%p会输出0x0，这是合法且常见的，不用额外判空
输出的地址是运行时虚拟内存地址，不可跨进程/重启复现
Go 的 %p 输出的是当前 goroutine 在本次运行中该指针指向的虚拟内存地址，受 ASLR（地址空间布局随机化）影响。每次运行程序，同一行代码输出的地址几乎肯定不同。
这意味着：
立即学习“go语言免费学习笔记（深入）”；
- 不能把
%p输出当唯一 ID 用 —— 即使同一对象，重启后地址就变 - 日志里记录
%p主要用于调试时比对「是不是同一个指针」，比如判断两个变量是否指向同一块内存 - 在 CGO 场景下，若需和 C 层共享地址，必须用
C.malloc+unsafe.Pointer显式管理，%p本身不保证与 C 的printf("%p")格式兼容（虽然通常都是十六进制）
fmt.Printf("%p", &x) 和 fmt.Printf("%p", unsafe.Pointer(&x)) 效果一样，但前者更安全
两者都输出 x 的地址，但路径不同：&x 是 Go 原生指针，unsafe.Pointer(&x) 是绕过类型系统的转换。Go 编译器对前者有完整类型检查和逃逸分析支持；后者一旦误用（比如指向栈上已失效的变量），可能引发静默内存错误。
所以：
- 优先用
&x，99% 的场景够用 - 只有当你需要把指针转为整数做算术（比如偏移计算）、或对接 C 函数参数时，才动
unsafe.Pointer - 别为了“看起来更底层”而刻意用
unsafe—— 它不会让%p输出更“准”，只是多了一层不必要风险
结构体指针和接口值的 %p 行为容易混淆
对结构体指针 %p 输出的是结构体实例的地址；但对接口变量（如 interface{}）用 %p，输出的是接口头（iface）自身的地址，不是它内部存储的动态值的地址 —— 这点非常反直觉。
例如：
type T struct{ n int }
var t T
var i interface{} = t
fmt.Printf("%p\n", &t) // 输出 t 实例地址
fmt.Printf("%p\n", &i) // 输出接口变量 i 自身在栈上的地址，不是 t 的地址
所以：
- 想确认接口是否持有了某个具体值的地址，得先断言成具体指针类型再取地址，比如
v, ok := i.(*T); if ok { fmt.Printf("%p", v) } - 直接对接口变量用
%p几乎没意义，容易误读 - 切片、map、channel 等引用类型变量本身不是指针，
&s打印的是其 header 结构体地址，不是底层数组或哈希表地址
真正要注意的，是别把 %p 当对象身份标识用，也别指望它在不同 goroutine 间稳定 —— 它只是调试时一眼看穿“谁指向谁”的快照工具，拍完就得扔。
