主函数退出前怎样确认所有后台清理动作已经完成

如果 Go 程序把清理工作放到后台 goroutine，再让 main 直接返回，进程可能在清理完成前就结束。可靠的做法是把退出当成一个有明确边界的阶段：先停止接收新任务，再关闭输入或发出取消信号，等待全部 worker 结束，最后由拥有资源的主流程关闭连接、文件和客户端。

确认清理完成的标准不是“调用过清理函数”，而是所有后台 goroutine 都已经退出，并且它们依赖的资源仍由明确的拥有者按顺序释放。

影响面：主函数返回不会替后台 goroutine 等待

defer 只绑定当前函数的返回，不会把其他 goroutine 纳入等待范围。主函数中的 defer 可能执行，但它不能证明后台 worker 已经写完日志、提交完任务或关闭了自己的资源。尤其是短命令、容器任务和测试程序，main 一返回，进程就没有继续运行的机会。

因此，退出条件应写在主流程里：主流程知道任务何时不再增加，worker 知道何时停止，等待对象则负责回答“是否全部结束”。不要用固定的 time.Sleep 猜测清理需要多久，它既可能等待过长，也可能在慢机器上提前退出。

修复动作：用 WaitGroup 建立可判断的退出条件

最小可靠模式是把计数器当成 worker 生命周期的集合。Add 放在 go 语句之前，避免 goroutine 尚未登记就被主函数抢先等待；Done 放在 worker 入口的 defer 中，确保正常返回和错误返回都会归还计数。

package main

import (
	"context"
	"log"
	"sync"
)

type Job struct{ ID int }

func worker(ctx context.Context, jobs 

这段代码中的 Wait 只说明 worker 已经返回，不代表所有业务动作天然成功。真实项目还要让任务处理函数返回错误，或把错误写入受控的结果 channel，由主流程在 Wait 后统一判断。

资源顺序：先停止接收，再等待工作，最后释放依赖

关闭顺序最好由资源拥有关系决定。发送端停止产生任务后关闭 jobs；worker 结束并执行自己的局部清理；主流程调用 Wait；最后关闭数据库连接、文件、日志刷盘器等共享依赖。这样不会出现 worker 还在写文件，主流程却已经先关闭文件的竞态。

如果任务必须尽量完成，可以只关闭输入，让 worker 把已经进入队列的任务处理完；如果任务允许中断，则调用 cancel，并让实际 I/O 使用带 context 的 API。两种策略不要混写成“先 cancel 再 close 所有 channel”，否则仍可能让发送方向已关闭的 channel 写入而 panic。

关闭动作也可能失败。建议把清理错误集中返回或记录，不要在多个 goroutine 中重复关闭同一个客户端。对有超时要求的程序，可以在等待阶段使用独立的退出截止时间；超时后记录未完成数量并执行进程级兜底，但要明确这已经是放弃部分清理，而不是“确认全部完成”。

常见问题：怎样区分完成等待与强制取消

只调用 cancel 能确认后台清理完成吗？

不能。cancel 只是广播停止意图，必须继续等待 worker 退出；如果 worker 没有检查 ctx.Done()，它甚至可能完全不响应。

为什么不建议用 time.Sleep 等几秒？

睡眠没有观察实际完成状态，任务耗时变化后就会失效。用 WaitGroup 等待明确的生命周期，比猜测时间可靠。

多个 goroutine 谁来关闭 channel？

通常由拥有发送权、且能确认不会再发送的一方关闭；接收方不要随意关闭共享输入。资源关闭同样遵循单一拥有者原则。

把“主函数退出”改成可观测的收口协议后，后台清理才有明确结果：输入停止、worker 计数归零、共享依赖最后释放。这个顺序比增加一个等待秒数更能稳定处理慢任务、异常返回和部署终止。