Go sync 怎样用 OnceFunc 封装只执行一次的清理

在 Go 服务里，一个资源往往有不止一个退出入口：正常返回会执行 defer，超时分支可能主动关闭，错误分支也可能提前释放。如果这些入口都直接调用 Close，清理逻辑就容易重复。sync.OnceFunc 适合把清理动作包装成一个可重复调用的函数：外部可以调用多次，底层函数只真正执行一次，而且返回函数允许并发调用。

官方文档：https://pkg.go.dev/sync

把资源释放动作放进 sync.OnceFunc 创建的闭包，再把这个闭包交给 defer、超时和错误分支共享，就能把“谁负责调用”和“实际只清理一次”分开。

先分清 OnceFunc 保证了什么

OnceFunc(f) 返回一个无参数函数。这个返回函数可以被多个 goroutine 同时调用，但 f 只会被执行一次。它适合“同一个资源只有一个清理生命周期”的场景，不是让每一次调用都重新执行清理。

它还有一个容易被忽略的边界：如果 f 发生 panic，返回函数的后续调用也会以同一个值 panic。清理函数里应尽量保持动作简单；如果底层关闭失败需要被业务处理，应该在清理 API 设计阶段单独安排错误记录或状态传递，而不是期待 OnceFunc 返回错误。

• 适合：文件、连接、临时目录等一次性释放。
• 不适合：同一个对象需要关闭后再次初始化，或每次调用都要重试的操作。
• 注意：传入函数若再次同步调用自己的返回函数，仍可能形成不可用的递归清理设计。

把清理函数封装成可共享的关闭入口

先让资源的所有权和清理动作在同一处建立，再把返回的闭包交给调用方。下面的示例只展示结构，重点是所有出口都拿到同一个 cleanup，而不是各自重新写一遍关闭逻辑。

package main

import (
    "log"
    "os"
    "sync"
)

func openReport(path string) (func(), error) {
    report, err := os.Open(path)
    if err != nil {
        return nil, err // 打开失败时没有资源，不能创建清理入口
    }

    cleanup := sync.OnceFunc(func() {
        // 关闭动作只放在这里，调用方不直接重复 Close
        if err := report.Close(); err != nil {
            log.Printf("close report: %v", err) // 记录释放阶段的异常
        }
    })
    return cleanup, nil
}

这里的关键不是 os.File，而是闭包捕获了资源，并把唯一的关闭动作藏在 OnceFunc 内部。调用方只需要保存返回的函数，不需要知道清理动作是否已经被另一个分支触发。

让多个退出分支共用同一个清理入口

有了清理闭包后，正常路径可以用 defer cleanup()，提前返回的分支也可以显式调用它。即便某个分支和 defer 同时到达，底层关闭函数也只有一次执行机会。

func processReport(path string, expired bool) error {
    cleanup, err := openReport(path)
    if err != nil {
        return err // 资源未打开，不调用 nil 清理函数
    }
    defer cleanup() // 正常返回和未覆盖的错误路径统一兜底

    if expired {
        cleanup() // 超时或提前结束时主动释放，defer 仍然安全
        return nil
    }

    // 这里执行读取和处理逻辑；所有出口都只依赖同一个 cleanup
    return nil
}

这种写法的价值是减少“漏关”和“重复关”的分支组合。需要注意，OnceFunc 只保护它包住的函数；如果清理前还有一段必须只执行一次的状态变更，也应把那段变更放在同一个闭包中，不能假设调用方的顺序自然可靠。

OnceFunc、sync.Once 和可重试清理怎么选

如果需要把关闭错误交给上层，sync.Once 往往更容易把错误保存到受控变量中；如果只是记录日志并确保底层释放动作不重复，OnceFunc 更直接。两者都不等于“资源已经可安全复用”，资源生命周期仍由调用方设计。

常见问题

OnceFunc 能代替所有 defer 吗？

不能。defer 负责把调用安排到当前函数返回时，OnceFunc 负责限制被包装函数的实际执行次数。常见组合是 defer cleanup()，而不是二选一。

为什么清理函数里发生 panic 要特别小心？

官方语义会保留这次 panic 的值，后续调用仍会 panic。清理动作最好保持幂等、短小且可记录异常；如果释放失败必须重试，就不要把重试策略藏进一个不可再次执行的闭包。

记住一个判断标准：多个入口可以重复“请求清理”，但真正拥有资源的关闭动作只能由一个受控闭包承接。只要资源生命周期确实只有一次，sync.OnceFunc 就能让这层意图在代码中直接可见。