Go 子进程退出但管道仍阻塞怎么办

遇到“Go 子进程明明退出了，cmd.Wait() 却一直不返回”，先别急着把问题归结为子进程没有结束。os/exec 的 Wait 不只等待进程状态，还要等待标准输入输出相关的复制协程；只要管道写端仍被某个子进程或后代进程持有，读端就可能等不到 EOF。

实用的处理方式是：先检查标准流的连接和读取顺序，再给 Cmd.WaitDelay 设置一个符合业务的收口时间。到期后用 errors.Is(err, exec.ErrWaitDelay) 区分“进程成功但 I/O 没收口”，不要把它和真正的退出码错误混在一起。

先确认卡住的是进程还是 EOF

Cmd.Start 成功后，Wait 会等待命令退出，并等待连接到 Stdout、Stderr 的复制循环完成。若输出目标是 *os.File，通常直接连接文件；若目标是普通 io.Writer，Go 会在内部通过管道复制输出，直到 EOF、I/O 错误或非零 WaitDelay 到期。

最典型的现场是 Unix shell 启动一个后台子进程：shell 自己已经退出，但后台进程仍继承了 stdout 的写端。父侧读协程看不到 EOF，因而 Wait 继续等待。这里的“管道阻塞”不是说 Wait 忽略了退出状态，而是标准流的生命周期比父进程更长。

先排除 StdoutPipe 的读取顺序错误

如果使用 StdoutPipe 或 StderrPipe，不要先调用 Wait 再读取。官方接口明确要求先把管道中的数据读完，再调用 Wait；否则 Wait 可能先关闭管道，或者在读取协程结束前形成互相等待。大量输出时还要并行消费 stdout 和 stderr，避免一侧写满缓冲区。

如果不需要逐块处理，直接把输出交给一个普通 writer 往往更简单；需要流式处理时，再使用管道并安排清晰的读取完成信号。无论哪种方式，WaitDelay 都不是读取顺序的补丁，它只是对异常延迟设置上限。

package main

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

func main() {
    // shell 退出后，后台 sleep 仍可能继承 stdout 的写端；这里只构造排查场景。
    cmd := exec.Command("sh", "-c", "printf 'ready\\n'; sleep 30 &")
    var output bytes.Buffer
    cmd.Stdout = &output
    cmd.Stderr = &output
    // 给异常的管道收口设置上限，不把它当成正常读取超时。
    cmd.WaitDelay = 800 * time.Millisecond

    if err := cmd.Start(); err != nil {
        panic(err)
    }
    err := cmd.Wait()
    switch {
    case errors.Is(err, exec.ErrWaitDelay):
        // 进程退出状态可能正常，但残留管道已被 WaitDelay 关闭。
        fmt.Printf("I/O 未及时收口: %q\\n", output.String())
    case err != nil:
        // 这里再处理启动失败、退出码错误或其他 I/O 错误。
        fmt.Printf("命令失败: %v\\n", err)
    default:
        // 正常路径同时拿到了完整输出和成功退出状态。
        fmt.Printf("命令完成: %q\\n", output.String())
    }
}

这个 Unix 示例的重点不是把 sleep 当成生产命令，而是展示诊断信号：父 shell 结束后，继承写端的后台进程会让默认的 EOF 等待变长；设置 WaitDelay 后，Go 会关闭仍然打开的 I/O 管道，并返回 exec.ErrWaitDelay。示例代码只用于说明 API 语义，未把示例输出当作本机执行证据。

WaitDelay 应该怎么设，哪些问题不能靠它解决

WaitDelay 的计时从关联上下文结束，或 Wait 观察到子进程退出时开始，以先发生者为准。到期时，如果进程还没退出，Go 会尝试结束它；如果进程已经退出但 I/O 管道仍开着，Go 会关闭父侧管道以解除读写阻塞。上下文取消、命令退出码和管道超时是三条不同线索，日志中应分别保留。

如果只设置 WaitDelay 而不修复子进程树，得到的只是“到点收口”的兜底结果。命令会产生更深层后代时，应从 shell 改为直接启动目标程序，或明确关闭继承的标准流；如果业务必须保留后台进程，则给它独立的输出文件或其他明确的日志通道。

用错误分类完成复查

修复后不要只看“Wait 返回了”。把输出保存下来，再按 errors.Is 判断 exec.ErrWaitDelay，按 *exec.ExitError 读取退出失败，按上下文错误区分调用方主动取消。对生产任务，还应记录 WaitDelay 配置值、命令是否经过 shell、stdout/stderr 的连接方式以及是否允许子进程继承描述符。

正常命令不应为了追求“更快返回”设置过短的延迟；它可能截断仍在传输的合法尾部输出。更稳妥的顺序是先修复管道持有者，再用一个能覆盖正常收尾的上限保护调用方。

相关问题

WaitDelay 为零会怎样？

零值表示不启用这条延迟上限，I/O 管道会继续读到 EOF；如果孤儿子进程仍持有描述符，EOF 可能迟迟不到。

ErrWaitDelay 代表子进程一定失败吗？

不一定。若命令本身成功退出、没有发生取消，而管道因 WaitDelay 到期被关闭，Wait 可能返回 exec.ErrWaitDelay。它描述的是 I/O 收口问题。

应该直接把 WaitDelay 设成很大吗？

不建议。先修复读取顺序、stderr 消费和描述符继承，再按正常收尾时间设置上限；过大的值只会把错误推迟到调用方。

接口细节可查 Go 官方文档：https://pkg.go.dev/os/exec；源码中的 Cmd.WaitDelay 和 ErrWaitDelay 说明了进程、管道与收口时机的关系。