Go 的 main 返回后，后台任务去哪了？两个示例看懂退出与等待

在 main 函数里加上一句 go，就能启动后台任务。接着运行程序，却发现任务有时没有输出，收尾日志也不见了。理解这个现象，要同时看执行单位和程序退出条件。

本文从“主 goroutine 和主线程”这个问题出发，用两个完整示例说明后台任务如何结束，以及主函数怎样等待它。

先分清函数、goroutine 和操作系统线程

main.main 是程序入口函数。执行这段代码的主 goroutine 是一条由 Go 运行时调度的执行流。操作系统线程承担实际执行，运行时把 goroutine 的工作安排到线程上。

日常代码应分别考虑两件事。任务之间怎样配合，由 channel、锁等同步机制表达。代码是否必须留在某个操作系统线程上，则涉及线程绑定以及被调用库的要求。仅凭一条日志来自 main，无法推断它使用了哪个线程。

Go 语言规范对入口函数的退出行为有明确规定。程序完成初始化后调用 main.main，这次调用返回时，程序结束，其他尚未完成的 goroutine 会随程序一起停止。因而，启动后台工作之后，主函数需要有相应的等待安排。

示例一，确认任务已启动，再让 main 返回

把下面代码单独保存为 main.go，可以用 go run main.go 执行，也可以放进 Go 官方 Playground 运行。

package main

import "fmt"

func main() {
    started := make(chan struct{})
    release := make(chan struct{})

    go func() {
        defer fmt.Println("worker defer")
        close(started)
        <-release
        fmt.Println("worker done")
    }()

    <-started
    fmt.Println("main returns")
}

本次实际输出只有一行。

main returns

started 用来消除“后台函数是否来得及启动”的疑问。主函数从 started 收到关闭信号时，后台函数已经执行过 defer 注册，并走到了 close(started)。之后它要等待 release，而程序中没有向 release 发送数据或关闭它的操作。

主函数随后打印日志并返回，程序正常结束。后台函数中的 worker done 和 worker defer 均未输出。这个结果说明，进程结束时，后台 goroutine 并不会各自再获得一次正常返回、执行 defer 的机会。

因此，把文件刷新、状态上报或者连接清理放进后台函数的 defer，还需要让该函数有机会走到退出流程。单纯启动它，无法保证这些动作完成。

示例二，让完成信号覆盖收尾动作

下面使用 done 表示“后台函数的收尾动作已经执行”。请用它替换上一段代码，单独运行。

package main

import "fmt"

func main() {
    done := make(chan struct{})

    go func() {
        defer close(done)
        defer fmt.Println("worker defer")
        fmt.Println("worker done")
    }()

    <-done
    fmt.Println("main returns")
}

本次实际输出按以下顺序出现。

worker done
worker defer
main returns

后台函数先打印 worker done。函数返回时，已经注册的 defer 按后进先出顺序执行，所以先打印 worker defer，再关闭 done。主函数收到关闭信号后，才继续打印 main returns。

这里的 defer 顺序直接决定完成信号的含义。若把 close(done) 放到业务工作之前，主函数可能过早继续执行。设计完成信号时，应明确它覆盖的是工作启动、主体完成，还是连同收尾一起完成。

对于多个独立任务，可以使用 sync.WaitGroup 统计完成数量。采用 Add 和 Done 的写法时，应在启动 goroutine 前完成 Add，把 Done 放在任务退出路径，并由主函数调用 Wait。若主函数还需要获得任务结果或错误，应另外设计结果传递通道。

time.Sleep 只让当前执行流等待一段时间，不能表达“后台工作已经完成”。机器负载、网络请求和磁盘速度发生变化时，固定等待时长容易失效。用完成信号或 WaitGroup，能够把等待条件直接对应到任务状态。

哪些场景需要关心操作系统线程

runtime.LockOSThread 用于把当前 goroutine 绑定到当前操作系统线程，适用于依赖线程局部状态的系统服务或非 Go 库调用。对应的 UnlockOSThread 调用解除绑定，嵌套调用需要配对。

runtime 文档还说明，init 函数在启动线程上运行。在 init 中调用 LockOSThread，可以让 main 函数在该启动线程上执行。涉及图形界面或其他要求特定线程的库时，应结合库自身的约束安排初始化和调用位置。

普通后台任务的生命周期管理，仍然可以围绕“启动、取消、完成、收尾”设计。主函数开始退出之前，先通知长期任务停止，等待它们结束，再释放任务共用的资源。需要退出时限的程序，还应明确超时后的处理方式。

验证记录与出处

两段完整程序均在 Go 官方 Playground 的 Go 1.27 环境执行通过。第一段输出一行 main returns，第二段按顺序输出三行日志。两个示例验证了入口函数返回和等待完成信号的行为，线程绑定说明依据 runtime 官方文档。

本文基于本站“安全问答”的《主goroutine和主线程的详细讲解》（条目 qHUl）经 AI 辅助改写，补充了独立可运行的示例。技术依据为 The Go Programming Language Specification 的 Program execution、Go statements 与 Defer statements 章节，以及 runtime.LockOSThread 和 sync.WaitGroup 官方文档。