Go slog 与 pprof 标签怎样关联一次后台任务

后台任务出问题时，最实用的关联键通常不是 goroutine 数量，而是一个稳定的 task_id。把它作为 slog 的结构化字段，同时作为 runtime/pprof 的标签，就能从日志先找到任务，再到 CPU 或 goroutine profile 中按同一身份缩小范围。需要先说清楚：slog 不会自动读取 pprof 标签，两边必须在同一个任务上下文里显式写入同一个值。

先把两种关联方式拆开

slog 的字段和 pprof 的标签是两条独立的观测路径。前者属于日志记录，适合按字段检索一条任务的开始、阶段和错误；后者属于 profile 上下文，适合观察带有该标签的 CPU 或 goroutine 工作。它们都可以使用同一个字符串身份，但没有一条隐藏机制会替你完成复制。

因此，值班时不要把“日志里有 task_id”理解为“profile 一定有同名标签”。正确的设计是让任务入口同时准备两个对象：一个带字段的 logger，一个带标签的 context，并把二者沿着同一条执行链传下去。

在任务入口固定一个不会复用的 task_id

任务 ID 的职责是把一次后台任务和同队列的其他任务区分开。它不必承载业务内容，也不要直接使用 worker 编号；worker 会处理许多任务，复用 worker ID 会让日志和 profile 混在一起。实际项目可以使用队列系统已有的 ID，或在入队时生成一个短而稳定的字符串。

package main

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

func runTask(parent context.Context, logger *slog.Logger, taskID string) {
    // 结构化日志和 pprof 都使用同一个任务身份，但各自写入自己的观测通道。
    taskLogger := logger.With("task_id", taskID)
    labels := pprof.Labels("task_id", taskID)

    pprof.Do(parent, labels, func(profileCtx context.Context) {
        // 日志显式接收 profileCtx，后续 Handler 才有机会读取当前上下文。
        taskLogger.InfoContext(profileCtx, "后台任务开始")
        doWork(profileCtx, taskLogger)
        taskLogger.InfoContext(profileCtx, "后台任务结束")
    })
}

func doWork(ctx context.Context, logger *slog.Logger) {
    // 业务函数继续接收 context，避免在深层重新创建 Background。
    logger.InfoContext(ctx, "处理任务阶段")
}

func main() {
    // JSONHandler 便于日志系统按 task_id 建索引；这里不依赖全局默认 logger。
    logger := slog.New(slog.NewJSONHandler(os.Stdout, nil))
    runTask(context.Background(), logger, "task-20261114-001")
}

这段代码的关键不在于把 logger 放进 context，而是让两个对象从同一个任务入口派生：taskLogger 保存日志字段，profileCtx 保存 pprof 标签。后续函数只要继续接收这两个参数，就不会因为换层或换 goroutine 而丢掉身份。

用 InfoContext 把日志写在同一条上下文链上

如果只调用 logger.Info，日志字段仍然可以出现，因为字段已经由 With 附加；但是它没有把任务 context 交给 Handler。需要让自定义 Handler、链路追踪或其他上下文感知逻辑参与时，应优先使用 InfoContext、LogContext 或 LogAttrs 的上下文版本。

func reportStage(ctx context.Context, logger *slog.Logger, stage string) {
    // task_id 已由入口 logger.With 固定，这里只追加阶段字段。
    logger.InfoContext(ctx, "后台任务阶段完成",
        slog.String("stage", stage),
    )
}

func reportError(ctx context.Context, logger *slog.Logger, err error) {
    // 错误信息与阶段使用同一条 ctx，避免异步日志脱离任务链。
    logger.ErrorContext(ctx, "后台任务失败",
        slog.Any("error", err),
    )
}

这里的 task_id 来自 logger，不是从 pprof 标签自动读取的。如果你的团队希望只传一个对象，可以自定义一个任务运行时结构体，把 ctx 和带字段的 logger 放在一起；不要把每一层都重新拼接 ID，否则很容易出现字段名不一致或值被覆盖。

把 pprof.Do 放在真正的任务生命周期内

pprof.Do 的作用域是回调函数。它会给父 context 增加标签，并在回调返回后恢复原来的标签。对后台队列而言，最合适的入口通常是“任务已经出队、准备执行”的地方，而不是进程启动时，也不是把整个 worker 永久包住。

type Task struct {
    ID string
}

func worker(ctx context.Context, logger *slog.Logger, tasks 

如果任务内部还要启动 goroutine，应在 pprof.Do 的回调期间创建它，并把回调收到的 profileCtx 传给日志点。这样既保留标签继承机会，也保留了取消信号。若 goroutine 在回调之外才启动，就不能再假设它自动拥有这组标签，应重新设计任务边界。

取消、失败和结束日志要保持同一个身份

后台任务常见的误关联并不是 profile API 出错，而是结束路径换了 context：开始日志带了 task_id，取消日志却使用了 context.Background()，最后在检索时看起来像两次不同的任务。结束和失败都应沿用任务入口创建的 logger 与 context。

func runWithCancel(parent context.Context, logger *slog.Logger, taskID string) {
    taskCtx, cancel := context.WithCancel(parent)
    defer cancel() // 任务结束时释放下游监听者

    taskLogger := logger.With("task_id", taskID)
    pprof.Do(taskCtx, pprof.Labels("task_id", taskID), func(profileCtx context.Context) {
        if err := doCancellableWork(profileCtx); err != nil {
            // 取消、超时和业务错误都保留 task_id，便于和开始日志配对。
            taskLogger.ErrorContext(profileCtx, "后台任务退出", slog.Any("error", err))
            return
        }
        taskLogger.InfoContext(profileCtx, "后台任务成功")
    })
}

func doCancellableWork(ctx context.Context) error {
    // 真实业务应在阻塞点检查 ctx；示例只保留接口边界。
    select {
    case 

这里的 defer cancel() 只负责释放这个任务派生出的取消链，不是用来清除 pprof 标签的。标签的恢复由 pprof.Do 自己完成，业务代码不要尝试调用低层 API 手动“清空”标签。

日志找得到但 profile 对不上时，按这张清单排查

1. 先确认 ID 唯一性：同一时间窗口内，队列重试、批量拆分和任务复用是否产生了相同的 task_id。如果会复用，追加一次执行编号，而不是只使用业务对象 ID。
2. 再确认日志入口：开始、阶段、错误、结束是否都使用同一个 taskLogger；检查是否有深层函数偷偷调用了全局 slog.Info。
3. 再确认上下文传递：profile 回调收到的 context 是否传给了真正的工作函数；新 goroutine 是否在回调内启动，是否把该 context 作为参数传入。
4. 最后确认 profile 类型：官方文档说明当前 CPU 和 goroutine profile 会使用标签信息，不要拿不支持标签筛选的其他 profile 期待同样结果。

适合落地的最小约定

如果项目只需要一条简单约定，可以把它写进后台任务执行器：每个执行实例生成一个不复用的 task_id；出队后创建带字段的 logger；在同一入口调用 pprof.Do；所有下游函数显式接收 context 和 logger；结束、失败、取消必须从原链路返回。这样日志和 profile 的关联靠的是明确的数据流，而不是依赖某个 Handler 或 profile 工具的隐式行为。

我的经验是，先把“身份”和“作用域”分开设计，排查会简单很多：task_id 解决“是哪一次任务”，pprof.Do 解决“这段执行是否属于该任务的 profile 范围”。前者必须长期稳定，后者必须短而准确。

相关问题

• pprof 标签会自动出现在 slog 日志里吗？不会。需要把相同的 ID 显式作为 slog 字段写入，或在自定义 Handler 中自行读取并约定映射。
• 应该把整个 worker 放进 pprof.Do 吗？通常不应该。worker 会连续处理多个任务，把每个出队任务放进独立作用域更容易避免标签串线。
• task_id 应该放在 context.Value 里吗？可以作为业务上下文的一部分，但不要只依赖 context.Value 让日志自动发现；日志字段仍应在任务入口明确构造。
• 只看 goroutine profile 能判断任务耗时吗？不能。goroutine profile 更适合看当时的栈与阻塞关系；任务耗时应由开始/结束日志或独立指标记录。