Go exec.CommandContext 超时后怎么判断进程是否仍在运行

用 exec.CommandContext 执行外部命令时，超时并不等于“还能不能看到一个正在运行的进程”。更可靠的判断是：先看 ctx.Err() 说明谁触发了取消，再让 cmd.Run() 或 cmd.Wait() 完成等待，最后读取 ProcessState 和 *exec.ExitError。cmd.Process 非空只表示命令曾经成功启动，不能拿它当作存活探针。

为什么 ctx.Err 不等于进程还在

ctx.Err() == context.DeadlineExceeded 只回答“等待期限到了”，不回答“操作系统里的直接子进程此刻是否已经结束”。CommandContext 把 context 和命令关联起来，默认在 context 完成后调用 Process.Kill；随后仍需要 Run 或 Wait 回收命令。

因此可以把两个问题拆开：取消原因用 context 判断，进程终态用等待结果判断。ProcessState != nil 说明 Wait 已经为成功启动的命令填充了状态；但在 Unix 上，被信号杀死不属于普通的 exit，所以 Exited() 可能为假，ExitCode() 会是 -1。这不是“进程还活着”的证据，而是“它没有通过正常 exit 结束”的信息。

先让 Run 或 Wait 完成，再判断最终状态

下面的示例把标准输出和标准错误合并到一个缓冲区，并故意让命令运行时间超过 deadline。注意判断顺序：先调用 Run，再检查超时和退出错误。这样返回时，直接子进程不会因为调用方提前结束而悬在半路。

package main

import (
    "bytes"
    "context"
    "errors"
    "fmt"
    "os/exec"
    "time"
)

func main() {
    ctx, cancel := context.WithTimeout(context.Background(), 800*time.Millisecond)
    defer cancel() // 无论命令是否超时，都释放 context 的计时器资源

    // 参数按独立位置传递；这里用 sh -c 只为了构造一个可重复的慢命令。
    cmd := exec.CommandContext(ctx, "sh", "-c", "printf 'begin\\n'; sleep 2")
    var output bytes.Buffer
    cmd.Stdout = &output // 保留超时前已经产生的标准输出
    cmd.Stderr = &output // 错误输出也进入同一个可读缓冲区

    err := cmd.Run() // Run 会启动命令并等待退出及输出复制完成
    timedOut := errors.Is(ctx.Err(), context.DeadlineExceeded)

    var exitErr *exec.ExitError
    failed := errors.As(err, &exitErr)
    fmt.Printf("timedOut=%v output=%q\\n", timedOut, output.String())
    fmt.Printf("waited=%v exitError=%v\\n", cmd.ProcessState != nil, failed)
    if cmd.ProcessState != nil {
        // 被信号终止时，ExitCode 通常为 -1；不要把它当成正常退出码。
        fmt.Printf("success=%v exited=%v exitCode=%d\\n",
            cmd.ProcessState.Success(), cmd.ProcessState.Exited(), cmd.ProcessState.ExitCode())
    }
}

这个例子中，超时后通常会得到一个 *exec.ExitError，错误文本常见为被信号终止；真正可依赖的是类型和 ProcessState，不是某一段平台相关的错误字符串。若命令在 deadline 前正常退出，err 为 nil，即使之后调用了 cancel 也不应把它改判为超时。

输出采集和清理必须跟着 Wait 完成

如果只调用 Start，看到 ctx.Done() 就直接返回，问题不在于“少读了一条日志”，而在于命令对象和输出链路可能还没有收尾。使用 StdoutPipe 或 StderrPipe 时尤其要安排读取并最终调用 Wait；使用 bytes.Buffer 这种普通 writer，则让 Run 统一等待复制更简单。

需要手动拆分输出时，写成“启动、读取、等待”的明确结构：

var stdout, stderr bytes.Buffer
cmd := exec.CommandContext(ctx, "my-tool", "--input", inputPath) // 每个参数独立传递
cmd.Stdout = &stdout
cmd.Stderr = &stderr

if err := cmd.Start(); err != nil {
    return fmt.Errorf("启动外部命令失败: %w", err)
}

waitErr := cmd.Wait() // 即使 context 已超时，也必须等待直接子进程完成回收
if errors.Is(ctx.Err(), context.DeadlineExceeded) {
    // 先记录超时，再结合 waitErr 和 ProcessState 判断最终结果。
    log.Printf("命令超时，stdout=%q，waitErr=%v", stdout.String(), waitErr)
    return waitErr
}
return waitErr

复查参数和进程树边界

参数传递也会影响排查结果。能直接调用可执行文件时，优先把参数拆成多个字符串，例如 exec.CommandContext(ctx, "my-tool", "--name", value)，不要先拼接整条 shell 命令。这样空格和特殊字符不会悄悄改变实际参数，也更容易把输出与目标命令对应起来。

还要留意一个边界：CommandContext 默认针对的是它启动的直接进程。若该进程又创建了孙进程，直接子进程被终止并不自动等于整个进程树都消失；这属于进程组或平台级生命周期管理问题。本文的“已结束”特指直接子进程已经被 Run/Wait 等待完成。

常见问题

超时后还能读取命令已经输出的内容吗？

可以。把 Stdout 和 Stderr 绑定到缓冲区，Run 返回后再读取；只能拿到终止前已经写出的内容。

为什么 ProcessState.Exited() 是 false？

在 Unix 上，被信号终止不属于普通的 exit，所以 Exited 可能为 false。结合 ProcessState != nil、Success 和 ExitCode 判断，不要单独解读一个布尔值。

cmd.Process 非空能证明进程还在运行吗？

不能。它只说明启动阶段拿到了进程对象；是否已经结束要等 Run 或 Wait，实时探测则需要另行设计。

排查这类超时问题时，固定顺序就够了：先记录 context 的取消原因，再等待直接子进程，最后结合输出、ExitError 和 ProcessState 记录结果。这样“超时”“被终止”“输出未收完”和“后代进程仍在”不会被混成一个状态。