Go pprof.Do 标签在并发请求中如何避免串到其他 goroutine

如果你在并发 HTTP 请求里给 Go pprof 加业务标签，最稳妥的做法是：在请求入口调用 pprof.Do，在它的回调里启动或调用业务逻辑，并把回调返回的新 context.Context 继续传给子 goroutine。pprof.Do 会在回调期间设置当前 goroutine 的标签，回调结束后恢复原状态；回调中创建的 goroutine 会继承当时的标签。不要把标签写成一个全局变量，也不要在线程池 worker 上直接使用 SetGoroutineLabels 却忘记恢复。

这里的“串到其他 goroutine”，通常不是 pprof 把两个请求的 context 混在一起，而是业务代码让一个长期复用的 goroutine 带着上一次任务的标签继续执行，或者异步任务没有携带正确的 context。

记住一条边界：pprof.Do 管的是“回调执行期间的当前 goroutine 状态”和“从该回调创建的 goroutine 的继承关系”，不是给任意已经存在的 goroutine 全局打标签。

先把两种标签作用域分开

pprof.Labels 创建的是一组键值标签，pprof.WithLabels 返回带标签的新 context；而 pprof.Do 把这两步和当前 goroutine 的设置、恢复组合在一起。下面的代码里，request 是业务键，不会因为另一个请求同时进入而被共享修改。

package main

import (
    "context"
    "fmt"
    "runtime/pprof"
)

func handle(ctx context.Context, requestID string) {
    labels := pprof.Labels("request", requestID, "route", "/orders")
    pprof.Do(ctx, labels, func(profileCtx context.Context) {
        // 回调期间当前 goroutine 使用 requestID；子 goroutine 会继承这组标签。
        if value, ok := pprof.Label(profileCtx, "request"); ok {
            fmt.Println("当前请求标签:", value)
        }
        doWork(profileCtx)
    })
    // 回调返回后，当前 goroutine 恢复进入 Do 之前的标签状态。
}

func doWork(ctx context.Context) {
    // 异步任务接收同一个 profileCtx，避免从全局变量读取请求标识。
    go func(childCtx context.Context) {
        if value, ok := pprof.Label(childCtx, "request"); ok {
            fmt.Println("异步任务标签:", value)
        }
    }(ctx)
}

请求入口要用独立的 Do 作用域

在 HTTP handler 中，建议把标签绑定放在每次请求都会经过的入口。每个请求拥有自己的 requestID，并在回调内部调用服务层。不要先修改当前 worker 的标签，再把 worker 放回池子；池子复用的正是最容易留下旧状态的地方。

func orderHandler(w http.ResponseWriter, r *http.Request) {
    requestID := r.Header.Get("X-Request-ID")
    if requestID == "" {
        requestID = "generated-id"
    }

    pprof.Do(r.Context(), pprof.Labels("request", requestID), func(ctx context.Context) {
        // 所有请求内工作都从这个 ctx 派生，结束时由 handler 返回控制生命周期。
        result := loadOrder(ctx)
        fmt.Fprintln(w, result)
    })
}

func loadOrder(ctx context.Context) string {
    // 把 ctx 传入数据库、RPC 或任务函数，标签才有机会跟随调用链。
    return "order loaded"
}

如果一个异步工作必须在 handler 返回后继续运行，不要把它悄悄变成“脱离请求的后台任务”。先明确它是否仍属于这次请求，再决定是继续使用请求 context，还是创建新的业务 context 并重新调用一次 pprof.Do。这样 profile 中的归属才不会模糊。

异步和线程池为什么最容易串标

新 goroutine 会继承创建者的标签，所以在 Do 回调中启动 goroutine 是自然的；但如果 goroutine 来自长期存在的 worker 池，任务提交者的 context 不会自动改变那个 worker 的当前状态。更安全的做法是让 worker 每次处理任务时在本地建立作用域：

type job struct {
    ctx context.Context
    id  string
}

func worker(jobs 

同一个 key 会覆盖父级同名标签，所以“追加 request 标签”并不等于保留两层 request。可以把稳定的上游标识命名为 trace，把当前任务命名为 job，避免下游误以为一个值同时代表两件事。SetGoroutineLabels 是更底层的接口，只有在你确实需要手动控制当前 goroutine 时才使用，并把恢复逻辑当成同一段代码的一部分。

最后用 profile 结果检查隔离

验证重点不是“能否看到标签”，而是同一时段的不同请求是否仍保持各自的值。抓取 CPU 或 goroutine profile 后，按 request、job 等维度观察；如果一个请求 ID 出现在明显不属于它的任务栈上，先查 goroutine 创建位置和 worker 是否把任务 context 传进了 Do，再查是否有裸调用 SetGoroutineLabels。

常见问题

pprof.Do 会让所有 goroutine 都带上同一组标签吗？

不会。它设置的是回调期间的当前 goroutine，并让回调中创建的 goroutine 继承；已经存在且不属于这条创建链的 goroutine 不会被自动改写。

为什么调用 pprof.Label 还能读到旧值？

通常是读取了旧 context，或 worker 在处理新任务前没有重新建立作用域。先检查传入函数的 context 是否来自当前这次 Do，再检查是否复用了任务对象或包级请求变量。

官方 API 说明和实现可参考 https://pkg.go.dev/runtime/pprof 与 https://go.dev/src/runtime/pprof/runtime.go。它们共同说明了标签覆盖、goroutine 继承和回调结束恢复这三个关键行为。