defer中指针参数的值在定义defer语句时求值，而非执行时；解引用（*p）也在该时刻完成，因此获取的是当时的快照值，非最新状态。
defer 里传指针，值是定义时还是执行时取的？
是定义 defer 语句时求值，不是执行时。哪怕指针本身没变，它指向的对象内容变了，defer 拿到的仍是调用时刻那个地址上当时的值（如果读的是解引用结果）。
常见错误现象：defer fmt.Println(*p) 打印出意外的旧值，尤其在循环或修改指针所指对象后；或者误以为传了“最新状态”，结果发现不是。
- 参数在
defer语句出现时立即求值：指针变量本身（即地址）被拷贝，但*p这种解引用操作也在此刻完成（如果写在 defer 参数里） - 想延迟读取最新值？得把解引用动作包进闭包，比如
defer func() { fmt.Println(*p) }() - 性能影响极小，但语义差异大——前者是快照，后者是延迟求值
for 循环中 defer 使用指针的典型陷阱
循环变量复用导致所有 defer 实际共享同一个地址，最后都打印最后一次迭代的值。
使用场景：批量资源清理、日志记录、状态回滚等需要延迟执行的操作，但又依赖循环中的指针变量。
立即学习“go语言免费学习笔记（深入）”；
- 错误写法：
for _, v := range items { p := &v; defer fmt.Println(*p) }→ 全部输出最后一个v的值 - 正确做法之一：在循环内显式创建新变量并取其地址，如
for _, v := range items { v := v; p := &v; defer fmt.Println(*p) } - 更推荐：避免在 defer 参数里直接解引用，改用匿名函数封装，确保每次迭代绑定独立作用域
defer 传 *T 和传 T 在内存与行为上的关键区别
传 *T 是传地址副本，传 T 是传值副本；但 defer 对两者的求值时机规则一致：都在 defer 语句执行时完成。
容易踩的坑在于混淆“指针变量的值”和“指针所指对象的值”。前者（地址）不变，后者（内容）可能被后续代码修改。
- 若函数内修改了
*p，而 defer 中用了*p（非闭包），那修改无效——因为解引用早已完成 - 若 defer 中只传
p（不加*），那打印的是地址，和后续修改无关；但多数人真正想要的是内容 - 结构体较大时传
*T更轻量，但这和 defer 求值时机无关，纯属参数传递开销问题
调试这类问题最有效的手段
别靠猜，用打印地址和内容来确认 defer 到底捕获了什么。
示例：在 defer 前加一行 fmt.Printf("addr=%p, val=%v\n", p, *p)，再对比 defer 内实际输出，能立刻暴露是否发生预期外的覆盖或复用。
- 对循环场景，额外打印循环索引和变量地址，验证是否真有多个不同地址
- 注意：Go 1.21+ 对循环变量的地址复用更激进，老代码升级后更容易暴露这类 bug
- 静态检查工具如
staticcheck能识别部分明显模式（比如循环中 defer 引用循环变量），但无法覆盖所有间接情况
最麻烦的不是语法错，而是逻辑上你以为 defer 看到了“将来”的状态，其实它只记得“那一刻”的快照——这点一旦忽略，排查起来特别绕。
