在Go中，对同一变量多次使用defer调用方法时，最终执行的是哪个实例，取决于该方法的接收者类型（值接收者或指针接收者）以及变量本身的类型（值还是指针），而非语句书写顺序。
当你在函数中对同一个变量（如 rows）两次调用 defer rows.Close()，Go 并不会“覆盖”前一个 defer，而是将每次 defer 语句即时求值并独立保存——包括函数值和所有参数（含方法接收者）。关键在于：接收者是按值复制，还是按地址引用？
✅ 指针变量 + 指针接收者 → 安全可靠（推荐场景）
以 database/sql.Rows 为例：
rows := db.Query("SELECT * FROM users") // 返回 *sql.Rows（指针）
defer rows.Close() // 此时保存：rows 的地址 + Close 方法
rows = db.Query("SELECT * FROM posts") // rows 指向新对象
defer rows.Close() // 此时保存：rows 的*新地址* + Close 方法由于 Rows.Close() 是指针接收者方法（func (r *Rows) Close()），且 rows 本身是 *Rows 类型，两次 defer 分别捕获了两个不同内存地址，因此两个查询结果集都会被正确关闭。
立即学习“go语言免费学习笔记（深入）”；
⚠️ 值变量 + 指针接收者 → 行为异常（易踩坑！）
type Config struct{ Name string }
func (c *Config) Close() { fmt.Println("Closing", c.Name) }
cfg := Config{"v1"}
defer cfg.Close() // 保存：&cfg 地址（指向栈上 cfg 变量）
cfg = Config{"v2"} // 修改栈上 cfg 的内容
defer cfg.Close() // 仍保存：&cfg 地址（同上！）⚠️ 两个 defer 实际都传入了 &cfg —— 即同一个地址。最终执行时，两次都读取 cfg.Name，输出均为 "v2"。后赋值覆盖了前一次的语义意图。
❌ 值变量 + 值接收者 → 表面“正常”，实则隐性拷贝
func (c Config) Close() { fmt.Println("Closing", c.Name) }
cfg := Config{"v1"}
defer cfg.Close() // 立即拷贝：c = {"v1"}
cfg = Config{"v2"}
defer cfg.Close() // 立即拷贝：c = {"v2"}此时两次 defer 各自持有独立副本，输出 "v1" 和 "v2"。看似合理，但若 Config 很大，会造成不必要的内存开销；更严重的是，它掩盖了逻辑耦合风险——你本意可能是关闭两个不同资源，却误用了同一变量名。
✅ 最佳实践：显式命名，避免歧义
// ✅ 清晰、安全、可维护
users, err := db.Query("SELECT * FROM users")
if err != nil { /* handle */ }
defer users.Close()
posts, err := db.Query("SELECT * FROM posts")
if err != nil { /* handle */ }
defer posts.Close()? 总结要点
- defer 的接收者和参数在 defer 语句执行时即求值并快照，不是延迟到 return 时才取值；
- 若变量是指针类型，且方法是指针接收者 → 每次 defer 捕获的是当前指针值（地址），行为符合直觉；
- 若变量是值类型，无论接收者是值还是指针 → 都存在共享状态或冗余拷贝风险，应主动规避；
- 永远优先使用不同变量名处理多个需 defer 清理的资源，这是最简单、最健壮、最符合 Go 习惯的写法。
记住：defer 不是魔法，它是确定性的快照机制。理解接收者语义与变量类型的交互，才能写出既高效又无副作用的清理逻辑。
