Go pprof.StartCPUProfile 停止太晚会造成什么影响

用 pprof.StartCPUProfile 做一次性 CPU 分析时，停止点放得太晚，最直接的后果是采样窗口变大：目标函数结束后的清理、等待、日志处理甚至下一段业务都会进入同一个 profile。程序结束时还要等 StopCPUProfile 把剩余数据写完，所以“多采一会儿”不等于“结果更完整”。

如果只想看某段工作负载，就让 profile 紧贴这段代码开始和结束；让 StopCPUProfile 在目标工作负载之后立即执行，通常比在 main 函数末尾 defer 更容易解释。

StartCPUProfile 停止太晚，影响的到底是什么

StartCPUProfile 为当前进程开启 CPU profiling，并把 profile 数据缓冲后写入传入的 io.Writer。它返回错误的一种情况是当前已经有 profile 在运行。StopCPUProfile 停止当前 profile，并且只有在该 profile 的写入全部完成后才返回。

因此，停止太晚有两个边界需要分开看。第一，统计边界被拉长了，目标阶段之后的 CPU 消耗也会参与采样，热点比例会被重新分配。第二，停止动作本身包含写入收尾，若输出较大或 writer 较慢，调用方会在这里等待。它不是把停止调用“丢到后台”就能消失的工作。

把停止点放到目标函数之后，窗口才容易解释

一次性分析更适合显式控制生命周期。下面的示例只把 profiledWork 放进采样区间，示例输出文件名仅用于本地分析；它不是本机运行结果。

package main

import (
    "log"
    "os"
    "runtime/pprof"
)

func main() {
    f, err := os.Create("cpu.prof")
    if err != nil {
        log.Fatal("创建 CPU profile 文件失败：", err) // 文件不可写时不要继续假设 profile 已开启
    }

    if err := pprof.StartCPUProfile(f); err != nil {
        _ = f.Close() // 启动失败时主动释放 writer，避免留下无用文件句柄
        log.Fatal("启动 CPU profile 失败：", err)
    }

    profiledWork() // 只把需要分析的工作放进采样窗口

    pprof.StopCPUProfile() // 先停止并等待 profile 写入完成
    if err := f.Close(); err != nil {
        log.Fatal("关闭 CPU profile 文件失败：", err) // 关闭失败应保留错误信号
    }
}

func profiledWork() {
    // 这里替换成实际要分析的一段业务或基准工作。
}

这个顺序的关键不是函数名，而是边界：文件先打开，profile 成功后再执行目标工作，停止后才关闭 writer。若把 StopCPUProfile 放到整个进程最后，profile 中就很难区分目标逻辑和收尾逻辑。

defer 能不能用：看 profile 的生命周期

如果 profile 覆盖的是整个短命令，下面的写法仍然合理，因为整个 main 就是目标范围：

f, err := os.Create("cpu.prof")
if err != nil {
    log.Fatal("创建 profile 文件失败：", err) // 失败时不注册后续清理动作
}
defer f.Close() // 后注册的 StopCPUProfile 会先执行

if err := pprof.StartCPUProfile(f); err != nil {
    log.Fatal("启动 profile 失败：", err) // 已有 profile 或其他启动错误都应中止
}
defer pprof.StopCPUProfile() // 仅适合覆盖整个当前函数的采样范围

Go 的 defer 按后进先出执行，所以这里会先停止 profile，再关闭文件。问题在于生命周期：如果同一个函数里还要做长时间等待、刷新缓存或处理下一项工作，defer 会把这些阶段也纳入采样。此时应改为显式停止，或把采样代码收进一个更小的函数。

用 top 和窗口对照，避免把误采样当成热点

生成 profile 后，可以用下面的命令查看热点。命令只负责读取已生成的剖面文件，不会替代对采样窗口的判断。

# 用 top 先看函数级热点，再决定是否需要打开调用图
go tool pprof -top cpu.prof

# 需要查看调用关系时打开交互式图
go tool pprof -web cpu.prof

排查时先问三个问题：热点是否发生在目标工作负载期间，采样开始前是否还有初始化，停止前是否做了额外等待或清理。如果 profile 很长但热点分散，不要先调整 pprof 参数，先缩短窗口重新采一份。

常见问题

停止太晚会让 CPU profile 失效吗？

不一定会失效，但它回答的问题变了：结果代表整个更长窗口，而不是原本想观察的那段工作。先明确采样目标，再决定是否重采。

StopCPUProfile 要不要放进 goroutine？

通常不建议为了缩短表面等待而异步调用。停止函数要完成 profile 写入，应该由拥有 writer 生命周期的流程明确等待它返回。

为什么 profile 文件还没关闭也能生成数据？

profile 会在采样期间写入 writer，但文件最终是否完整仍取决于 StopCPUProfile 的收尾和文件关闭。分析前应让停止和关闭都完成。