在go中，对同一变量多次使用defer调用方法时，最终执行的是哪个实例，取决于该方法的接收者类型（值接收者 or 指针接收者）以及变量本身的类型（值 or 指针），而非“最后一次赋值”的直观印象。
当你在函数中对同一个变量多次调用 defer rows.Close()（例如两次查询后都 defer 同一变量的 Close 方法），实际被关闭的对象并非由“最后一行赋值决定”，而是由 defer 语句执行时该变量的当前状态（尤其是其内存地址或值拷贝）决定。关键在于 Go 的 defer 机制：函数值与参数（含方法接收者）在 defer 语句执行时即被求值并保存，而非等到函数返回时才取值。
? 核心规则总结：
- ✅ *指针变量 + 指针接收者方法（如 `sql.Rows.Close()）**：安全可靠。每次defer rows.Close()保存的是rows当前指向的地址；即使后续rows被重新赋值为另一个*sql.Rows，两次 defer 仍分别绑定到两个不同的底层资源。这是database/sql` 包能正确工作的根本原因。
- ⚠️ 指针变量 + 值接收者方法：虽不常见，但此时接收者是 *X 的副本（即指针值本身被拷贝），两次 defer 保存的是不同指针值（地址），行为符合预期。
- ❌ 值变量 + 值接收者方法：每次 defer 会拷贝整个结构体（如 X{...}）作为接收者。第二次 defer 保存的是新赋值后的结构体副本，第一次的副本已固化——因此两次 Close 操作作用于两个独立副本，原始资源可能未被释放。
- ⚠️ 值变量 + 指针接收者方法：危险！ 此时 defer 保存的是该局部变量的地址（如 &x）。若后续修改 x，两次 defer 实际共享同一内存地址，最终两次 Close 都操作最后赋值的那个值（见下文示例输出中的 Value-X2 Second 重复出现），导致逻辑错误或资源泄漏。
? 示例验证（精简关键部分）
type X struct { S string }
func (x X) Close() { fmt.Println("Value-Closing", x.S) }
func (x *X) CloseP() { fmt.Println("Pointer-Closing", x.S) }
func main() {
// 场景1：值变量 + 值接收者 → 两次 defer 保存不同副本
x := X{"First"}; defer x.Close() // 保存 "First"
x = X{"Second"}; defer x.Close() // 保存 "Second"
// 输出：Value-Closing Second \n Value-Closing First
// 场景2：值变量 + 指针接收者 → 两次 defer 保存同一地址（&x）
x2 := X{"First"}; defer x2.CloseP() // 保存 &x2（指向"First"）
x2 = X{"Second"}; defer x2.CloseP() // 仍保存 &x2（现指向"Second"）
// 输出：Pointer-Closing Second \n Pointer-Closing Second ← 问题所在！
// 场景3：指针变量 + 指针接收者 → 安全（推荐模式）
xp := &X{"First"}; defer xp.Close() // 保存地址 A
xp = &X{"Second"}; defer xp.Close() // 保存地址 B
// 输出：Pointer-Closing Second \n Pointer-Closing First ← 正确关闭两个实例
}✅ 最佳实践建议
-
优先使用独立变量名：避免歧义，提升可读性与可维护性：
rows1 := db.Query("SELECT ..."); defer rows1.Close() rows2 := db.Query("SELECT ..."); defer rows2.Close() -
理解 database/sql 的设计保障：sql.Rows 是指针类型，Close() 是指针接收者方法，因此你的原始代码（两次 defer rows.Close()）在技术上是安全的——它会正确关闭两个查询结果集。但强烈建议改用独立变量，因为：
- 符合直觉，降低认知负担；
- 避免未来重构时因变量复用引入隐患；
- 静态分析工具（如 govet）可能对重复 defer 发出警告。
-
自定义类型设计原则：若实现资源管理方法（如 Close()），始终使用指针接收者，并确保调用方持有指针（如通过 NewX() 返回 *X），以保证 defer 行为可预测。
立即学习“go语言免费学习笔记（深入）”；
? 总结：Go 的 defer 不是“延迟读取变量”，而是“延迟执行已冻结的函数+参数”。牢记 “defer 时求值，return 时执行” 这一原则，结合接收者类型与变量类型，即可准确预判资源清理行为。
