defer在return表达式求值后、函数退出前执行，影响命名返回值；需确保绑定正确资源实例，panic时仍执行但无法recover；性能敏感路径应慎用。
Defer 语句执行时机经常被误判
很多人以为 defer 是“函数返回前才执行”，其实它在 return 表达式求值后、函数真正退出前 才触发。这意味着：如果函数有命名返回值，且 defer 中修改了该变量，会影响最终返回结果。
常见错误现象：defer 修改了命名返回值但没生效，或意外覆盖了原本要返回的 error。
- 使用命名返回值时，
defer中对返回变量的赋值会生效（Go 1.17+ 仍如此） - 用
return err这种非命名形式时，defer拿不到这个err的引用，只能靠闭包捕获 - 多个
defer按后进先出（LIFO）顺序执行，别依赖执行顺序做状态流转
示例：
func badCleanup() (err error) {
f, _ := os.Open("x")
defer func() {
if f != nil {
f.Close() // 正确：能访问 f
}
}()
if _, err = io.ReadAll(f); err != nil {
return // 此时 err 已设为非 nil，defer 里 f.Close() 仍会执行
}
return nil
}
文件/数据库连接必须配对 defer Close()
不是“写了 defer 就安全”，关键在于 defer 是否绑定了正确的资源实例。常见问题：在循环中打开多个文件却只 defer 一次，或 defer 放在 if 分支外导致资源未初始化就调用 Close。
使用场景：打开单个文件、获取单次 DB 连接、启动 goroutine 后需确保停止。
- 每个
os.Open、sql.Open、http.Client.Do后应紧跟着对应资源的defer xxx.Close() - 避免
defer f.Close()写在f, err := os.Open(...)上方——此时f是零值，f.Close()panic - 数据库连接池不用手动
Close()，但*sql.Rows和*sql.Tx必须显式 close 或 commit/rollback
正确写法：
f, err := os.Open("log.txt")
if err != nil {
return err
}
defer f.Close() // 绑定的是这次打开的 f 实例
Defer 在 panic 场景下依然执行，但不能 recover
defer 确实会在 panic 后执行，但它本身不捕获 panic。如果你指望 defer 里的日志或清理能“兜底”，得确认它不依赖可能已失效的状态（比如已关闭的 channel、已释放的 mutex）。
容易踩的坑：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 在 defer 中调用
close(ch)，但 ch 已被其他 goroutine 关闭 → panic: close of closed channel - defer 中调用
mu.Unlock()，但 mu 从未 Lock 过，或已被 Unlock → panic: sync: unlock of unlocked mutex - defer 函数内再 panic，会覆盖原始 panic，掩盖真正问题
建议做法：在 defer 前加判断，或用带状态检查的封装：
if mu != nil && mu.TryLock() { // 不推荐；更稳妥是确保 Lock/Unlock 成对出现在同一作用域
defer mu.Unlock()
}
更可靠的方式是把资源生命周期控制在明确的作用域内，而不是靠 defer 猜状态。
性能敏感路径慎用 defer
每次 defer 调用都有微小开销：需分配 defer 记录、入栈、出栈。在高频循环（如每秒百万次请求的中间件）中，累积起来不可忽略。
影响点：
- Go 1.14+ 对简单 defer 做了优化，但闭包形式（
defer func(){...}()）仍比直接调用defer f.Close()多一次函数调用和闭包分配 - 编译器无法内联 defer 调用，可能阻碍进一步优化
- 如果资源释放逻辑简单（如
free(ptr)），直接写在 return 前反而更清晰高效
权衡建议：
普通业务代码完全不用顾虑；HTTP handler、CLI 命令这类低频入口，defer 是首选；纯计算型 hot loop 里，优先用显式 cleanup + goto（是的，Go 允许 goto，且在这里比 defer 更轻量）。
复杂点在于：defer 看似省事，但一旦涉及资源状态交叉、panic 恢复、跨 goroutine 协作，它的“自动”反而成了推理负担。写的时候轻松，读的时候得脑补整个调用栈的 defer 栈——这才是最容易被忽略的地方。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
