pprof看不到短命goroutine怎么办

pprof 看不到短命 goroutine，首先确认采集类型：goroutine profile 展示采集时仍存在的 goroutine 栈，不是创建与退出历史。任务在采集前已经结束，快照没有它并不异常。要观察一个时间窗口内的创建、阻塞和唤醒关系，应在任务开始前开启执行 trace，并覆盖整个任务窗口。

官方地址：https://pkg.go.dev/runtime/pprof；https://pkg.go.dev/runtime/trace

先判断你拿到的是快照还是采样

设想某个服务每次请求都创建一个很快结束的 goroutine。请求完成后才保存 goroutine profile，结果只剩主循环与长期工作者。此时不能据此断言短任务没有启动；观测时间与问题范围并不一致。

短任务可能没有恰好落在 CPU 采样点上；大量同类短任务的累计 CPU 成本仍可能出现在热点中。不要把“一个具体实例没有被记录”与“同类工作没有成本”混为一谈。反过来，阻塞中的 goroutine 即使存在，也不代表它一直消耗 CPU。

把 trace 窗口放在创建之前

执行 trace 记录 goroutine 创建、阻塞、唤醒等运行时事件。应先开始采集，再触发有代表性的负载，等待有关任务完成后停止。若发现问题后才开采集，要重新触发可控负载；已经结束的 goroutine 不会被工具补回历史。

选择小而明确的窗口，例如一次批量任务或一段可重现请求，而不是无限记录。保持并发量、输入和业务路径接近实际场景，不要为了让快照看得见就人为加入长时间 Sleep：那会改变原本想研究的调度行为。

用有界示例保存短任务的执行追踪

下面的完整程序创建四十个短任务，任务数量只是演示输入，不是测量结果。trace 在任务创建前启动，WaitGroup 确认所有任务结束；Task 和 Region 帮助按业务含义归类。示例需要支持 errors.Join 的 Go 1.20 及以后版本。

package main

import (
 "context"
 "errors"
 "fmt"
 "os"
 "runtime/trace"
 "sync"
)

func capture() (err error) {
 // 独占创建，避免覆盖已有追踪文件；权限仅限当前用户。
 f, err := os.OpenFile("short.trace", os.O_WRONLY|os.O_CREATE|os.O_EXCL, 0600)
 if err != nil { return err }
 defer func() { err = errors.Join(err, f.Close()) }()
 if err = trace.Start(f); err != nil { return err }
 defer trace.Stop() // 后注册先执行，确保追踪写完后才关闭文件。

 ctx, task := trace.NewTask(context.Background(), "short-batch")
 defer task.End()
 var wg sync.WaitGroup
 for i := 0; i 

文件使用独占创建，第二次运行不会覆盖已有追踪。defer 的注册顺序使 Task 结束、trace 停止写入、文件关闭依次发生。trace.Start 在已有追踪启用时会返回错误，因此生产进程需要由统一入口管理采集，避免多个请求争用同一追踪会话。

# 在独立模块中保存完整示例为 main.go 后运行；文件存在会报错，先妥善归档。
go run .

# 调度延迟剖面可使用文本方式分析，无需把追踪图当截图。
go tool trace -pprof=sched short.trace > sched.pprof
go tool pprof -top sched.pprof

以上示例和命令供读者复现，本文没有执行它们，也不附带虚构的耗时数据。调度延迟剖面是 trace 派生出的聚合视角，不是完整事件历史；查看细节可使用 go tool trace 的交互查看能力，但应保留原 trace 文件供定位。

看到了短任务，该怎样解释它的成本

先按任务类型找到对应工作，再区分运行、就绪等待和阻塞。短任务完成得快，不等于调度成本可以忽略；任务创建很多，也不能直接说明应该改成线程池。需要结合请求耗时、CPU 热点、共享资源竞争和队列等待，判断真正影响业务的部分。

示例中的 short-batch、short-work 是固定分类，生产环境也宜使用数量有限的类型名称。不要把每条用户输入或每个订单号都变成一种 Region 类型。需要关联信息时遵守数据最小化原则，避免让追踪文件承担敏感业务日志。

调整并发方案后怎样比较

如果怀疑频繁创建任务带来额外成本，可在同样输入下比较同步执行、有限并发和原有方案。保持错误处理、等待完成和结果语义一致。有限并发可能减少调度压力，也可能增加队列等待；只有业务目标改善，才能说明调整有效。

trace 会影响被观察程序，适合定位行为与关系；要判断稳定吞吐和延迟，另做符合真实负载的测量。保留版本、采集窗口和负载描述，避免把不同条件的两份文件直接比较。不要仅凭“图里 goroutine 少了”就宣布优化成功。

把 CPU profile 采集时间拉长就能看到每个实例吗

不能保证。更长窗口可能改善同类工作累计成本的统计，但 CPU profile 仍然不是逐实例生命周期记录。

连续多取几次 goroutine 快照可以吗

可以用于观察持续存在的状态，但采集间隙仍可能错过短任务。要回答创建与调度关系，优先选择覆盖负载的 trace。

能用创建总数减去当前数量算出所有退出吗

业务计数可以辅助核对受控任务，但运行时还有其他 goroutine；应明确统计范围，不能拿不同口径的数据拼成逐任务历史。

参考文档：https://pkg.go.dev/runtime/pprof；https://pkg.go.dev/runtime/trace；https://pkg.go.dev/cmd/trace