资源生命周期管理：defer、Close、panic 与 recover 的边界
Go 没有析构函数，资源释放依赖显式的 Close、cancel、Stop 和 Unlock。defer 让清理动作可以紧挨着资源获取，但它不是“函数结束时帮我处理一切”的魔法：参数何时求值、错误是否被忽略、循环里积累多少 defer，都需要开发者自己决定。
先确定所有权，再写 defer
谁成功获取资源，谁负责释放，这是最容易维护的默认规则：
file, err := os.Open(path)
if err != nil {
return err
}
defer file.Close()只有在 err == nil 后才安排清理。不要对可能为 nil 或处于半初始化状态的对象调用 defer resource.Close()。
当资源所有权被转移时，原持有者就不应再关闭。例如把连接交给一个长期运行的 client，构造函数文档要明确 client 是否接管连接。所有权模糊比忘记一行 defer 更难排查，因为它会同时产生泄漏和重复关闭。
defer 的三条规则
1. 参数在 defer 声明时求值
value := 1
defer fmt.Println(value)
value = 2
// 输出 1这对方法接收者也成立。下面的 file 在 defer 创建时就确定了：
defer file.Close()但闭包中的变量在真正执行时读取：
defer func() {
fmt.Println(value) // 输出 2
}()2. 多个 defer 后进先出
defer fmt.Println("first")
defer fmt.Println("second")
// second
// first这使嵌套资源能够按获取顺序的反向释放：先开连接，再开事务；退出时先结束事务，再关连接。
3. defer 可以修改命名返回值
这个能力适合合并关闭错误，但滥用会让返回路径难以阅读：
func writeFile(path string, data []byte) (err error) {
file, err := os.Create(path)
if err != nil {
return err
}
defer func() {
err = errors.Join(err, file.Close())
}()
_, err = file.Write(data)
return err
}文件写入、压缩 writer、数据库提交等场景中，Close 可能负责刷新缓冲区，关闭错误不能一概忽略。只读文件关闭失败通常不影响已经读取的数据，可以根据资源语义选择记录或忽略。
不要在长循环里无限积累 defer
defer 在包围它的函数返回时执行，不是在当前代码块结束时执行：
func process(paths []string) error {
for _, path := range paths {
file, err := os.Open(path)
if err != nil {
return err
}
defer file.Close() // 所有文件要等 process 返回才关闭
// ...
}
return nil
}把每轮操作提取成函数，可以同时保留 defer 的局部性和及时释放：
func processOne(path string) error {
file, err := os.Open(path)
if err != nil {
return err
}
defer file.Close()
return consume(file)
}
func process(paths []string) error {
for _, path := range paths {
if err := processOne(path); err != nil {
return fmt.Errorf("process %q: %w", path, err)
}
}
return nil
}现代 Go 编译器已经优化了许多 defer 场景，不要为了几纳秒把清理动作移到每个 return 前。先保证生命周期正确，确认热路径后再用 benchmark 判断。
锁的 defer 需要关注临界区大小
mu.Lock()
defer mu.Unlock()这种写法可靠，但锁会持有到函数返回。如果函数后半段还有网络请求、日志格式化或其他不需要保护的操作，应缩小作用域：
func update() {
func() {
mu.Lock()
defer mu.Unlock()
updateSharedState()
}()
notifyRemoteService()
}也可以显式解锁。关键不是“必须 defer”，而是解锁路径是否清楚、临界区是否准确。
Context 的 cancel 也是资源释放
context.WithCancel、WithTimeout 和 WithDeadline 返回的 cancel 会断开父子关系并停止关联计时器。即使确定会超时，也应立即 defer：
ctx, cancel := context.WithTimeout(parent, 500*time.Millisecond)
defer cancel()不调用 cancel，不一定永远泄漏，但相关资源可能一直保留到父 Context 结束或截止时间到达。在高频路径中，这足以形成明显压力。
panic 不是普通错误返回
panic 适合表示当前执行路径无法继续维持程序不变量，例如初始化阶段的不可恢复配置、内部状态损坏，或者程序员错误。文件不存在、请求参数不合法、下游超时都属于正常失败，应返回 error。
panic 会沿当前 goroutine 的调用栈展开，并执行沿途 defer：
flowchart TD
P[panic] --> D3[执行当前函数 defer]
D3 --> D2[展开上一层并执行 defer]
D2 --> D1[继续展开]
D1 --> X[无人 recover：进程退出]
recover 只能在同一 goroutine 的 defer 中生效
func safeRun(task func()) (err error) {
defer func() {
if recovered := recover(); recovered != nil {
err = fmt.Errorf("task panicked: %v", recovered)
}
}()
task()
return nil
}这个 recover 捕获不了 task 自己启动的另一个 goroutine 中的 panic。每个 goroutine 都有独立调用栈，需要在对应 goroutine 的边界恢复。
recover 的合理位置通常是进程级边界：HTTP middleware、任务 worker、插件执行器。边界恢复后应记录堆栈，并决定当前请求或任务如何失败：
defer func() {
if value := recover(); value != nil {
logger.Error("worker panicked",
"panic", value,
"stack", string(debug.Stack()),
)
}
}()在每个函数都 recover 会掩盖程序错误，让系统带着损坏状态继续运行。恢复不是“忽略 panic”，而是把故障限制在明确隔离边界内。
清理动作也可能 panic
如果主逻辑已经 panic，defer 中再次 panic，后一个 panic 会让诊断更混乱。清理函数应尽量幂等、可重复调用，并通过 error 报告可预期失败。不要在 defer 里做复杂业务逻辑或发起没有超时的远程调用。
一份实用的资源协议
为自定义组件设计生命周期时，建议明确以下约束：
- 构造成功后由谁调用
Close； Close能否重复调用；Close是否等待后台 goroutine 退出；- 关闭过程中如何处理 Context 和超时；
- 关闭失败后组件处于什么状态。
资源管理的核心不是 defer，而是所有权。defer 只是把所有权决定变成一段更难漏掉的代码。