短生命周期任务为什么反复出现在泄漏报告中

会反复出现在泄漏报告里的，通常不是“任务太短”，而是任务结束后还有一步结果交付没有完成。典型场景是父函数遇到第一个错误就返回，子 goroutine 却还要把结果写入无缓冲 channel；接收方已经离开，发送方只能永久等待。对 goroutine 来说，业务函数返回只是中途节点，不是生命周期终点。

官方资料：https://go.dev/blog/goroutine-leak-profiles

先区分任务完成与 goroutine 完成

“处理第 5 个任务失败”与“第 1、2、3、4、6 个 goroutine 都退出”是两件事。若结果 channel 没有缓冲，子 goroutine 的最后动作可能是发送结果；父函数在收到错误后立刻返回，后续发送就再也没有接收者。

因此，报告里看到 runOne 或 process 并不意味着这些函数本身很慢。真正有价值的是栈顶附近的等待点。可以把常见信号先整理成一张表：

用 goroutineleak 把报告栈落到阻塞操作

Go 1.27 提供了新的 goroutine 泄漏 profile。已接入 net/http/pprof 的程序可以从对应 endpoint 取得它，再交给 go tool pprof 定位函数和行号。示例命令只表示采集方式，不把输出当作本文运行证据：

# 采集泄漏 profile，文件只用于本地分析
curl http://localhost:6060/debug/pprof/goroutineleak -o leak.prof
# 进入 pprof 后按函数名查看阻塞栈
go tool pprof leak.prof
# 在交互界面定位结果交付函数
(pprof) list runJobs

如果栈落在结果发送处，优先复盘“接收方何时停止”而不是先调大 goroutine 数量。官方机制本身也有边界：它主要覆盖永久阻塞在 channel 或 sync 原语上的 goroutine；突发流量造成的大量暂时等待、低数量但很久才暴露的问题，仍要结合普通 goroutine profile、指标和测试判断。

采集频率也要有约束。泄漏检测会触发特殊的 GC 检查，生产环境可以低频采集，排障时再临时提高频率；不要把每次请求都变成一次 profile 请求。

为结果交付和取消建立生命周期闭环

比“无脑加缓冲”更稳妥的做法，是让父协程拥有收尾职责：子协程用 context 感知取消，结果 channel 按任务数设置有界缓冲，父协程持续排空结果，最后由明确的协调者等待所有发送者退出。

func runJobs(parent context.Context, jobs []Job) ([]Result, error) {
    ctx, cancel := context.WithCancel(parent)
    defer cancel() // 统一释放仍在运行的任务

    results := make(chan result, len(jobs)) // 给错误提前返回留下交付空间
    var wg sync.WaitGroup
    for _, job := range jobs {
        job := job // 固定本轮循环值，避免闭包捕获变化的变量
        wg.Add(1)
        go func() {
            defer wg.Done() // 无论成功失败都让协调者能收尾
            value, err := doJob(ctx, job)
            select {
            case results 

这个结构的关键不是某一行 API，而是责任闭环：cancel 负责通知，results 负责短暂承接，range 负责排空，WaitGroup 确认所有发送者结束，最后才允许 close。如果 doJob 内部完全忽略 context，取消也无法保证快速退出，那就需要为它增加可中断的 I/O 或超时边界。

按边界清单验证修复是否真的生效

修复后不要只跑一次成功案例。至少重复四种输入：全部成功、首个任务失败、零任务、某个任务故意变慢。每轮记录 goroutine 总数和泄漏 profile 的堆栈是否回落；若失败分支结束后数量仍持续增长，说明交付或退出路径还有所有权缺口。

• 发送者是否能在接收方返回后退出？
• 是否存在唯一的 channel 关闭者，且关闭发生在所有发送者完成之后？
• 慢任务是否能响应 context，而不是依赖父函数“希望它快点结束”？
• 报告里的等待是否属于设计好的暂时并发，还是永远没有满足条件的阻塞？

常见问题

把结果 channel 改成缓冲后，为什么仍可能泄漏？

缓冲只能承接有限结果；如果任务数不受控、消费者永久不读，或 worker 还等待另一个未关闭的 channel，泄漏仍会发生。缓冲要和取消、排空、关闭责任一起设计。

普通 goroutine profile 和 goroutineleak 怎么选？

普通 profile 展示当前所有 goroutine，适合看数量趋势和暂时阻塞；goroutineleak 更聚焦于运行时判断为永久阻塞的子集。排障时先用后者缩小范围，再用前者观察全局行为。

短任务结束很快，为什么还会留下很多条报告？

因为每次短任务都可能在最后的结果交付点留下一个等待者。调用频率越高，单次很短的缺口越容易累积成明显的 goroutine 泄漏。