多数情况不会，但高频循环中滥用defer（如每轮defer锁释放或文件关闭）会因累积注册开销、逃逸和堆分配拖慢性能；应避免循环内defer，改用显式调用或外提资源生命周期。
defer 会拖慢性能吗？多数情况不会，但某些写法确实会
Go 的 defer 本身开销极小（约 3–5 ns），真正影响性能的是它推迟执行的函数体、闭包捕获、以及调用频次。高频循环中滥用 defer（比如每轮都 defer 一个锁释放或日志打印）会导致明显累积开销，甚至触发逃逸和堆分配。
避免在循环内 defer 函数调用
这是最常见也最容易被忽略的性能陷阱。每次迭代都会注册一个 defer 记录，不仅增加 runtime 调度负担，还会让 deferred 函数的参数（尤其是变量引用）持续持有到函数末尾，阻碍 GC。
- ❌ 错误写法：在 for 循环里反复 defer
mu.Unlock()或file.Close() - ✅ 正确做法：把资源生命周期控制移到循环外，或用显式调用代替 defer
- ⚠️ 特别注意：闭包捕获循环变量（如
for i := range items { defer func() { log.Println(i) }() }）不仅逻辑错，还因闭包逃逸进一步拉低性能
for _, f := range files {
f, err := os.Open(f)
if err != nil {
continue
}
// ❌ 千万别这么写
// defer f.Close() // 每次都注册，且可能 close 已关闭的文件
// ✅ 放在单次处理块末尾，或用显式 close + error check
if err := processFile(f); err != nil {
f.Close()
continue
}
f.Close()
}
用 defer true/false 控制是否执行（替代条件 defer）
Go 不支持条件 defer（如 if ok { defer f() }），硬编码会导致无谓注册。更高效的方式是让 defer 调用本身带开关逻辑。
- 不推荐：
if shouldLog { defer log.Printf("done") }→ 语法错误，无法编译 - 推荐：把判断逻辑放进 defer 的匿名函数里，用布尔变量控制
- 注意：
shouldLog必须在 defer 前定义并显式传入，避免意外捕获未初始化值
shouldLog := len(data) > 0
defer func(logIt bool) {
if logIt {
log.Printf("processed %d items", len(data))
}
}(shouldLog)
defer 调用栈深时要警惕 panic 恢复成本
大量 defer 会加长函数返回前的执行链，一旦发生 panic，所有已注册但未执行的 defer 都要逐个调用——包括那些本可跳过的清理逻辑。这不是 CPU 时间问题，而是“异常路径响应延迟”问题。
立即学习“go语言免费学习笔记（深入）”；
真实项目里，defer 性能问题往往不是“用了 defer”，而是“在哪用、怎么用、用多少”。尤其在中间件、数据库连接池、流式处理等场景，defer 的粒度和位置，比省那几个纳秒更重要。
