Golang exec.Cmd非阻塞os.Stdin读取的差异及解决方法

问题现象 #

直接将os.Stdin赋值给exec.Cmd.Stdin时，即使命令（比如env）不需要读取标准输入，代码也能正常执行结束：

cmd := exec.Command("env")
cmd.Stdin = os.Stdin
cmd.Stdout = os.Stdout

但通过管道传递标准输入时，执行env后会一直阻塞，直到有输入传入：

cmd := exec.Command("env")
reader, writer := os.Pipe()
go func() {
  io.Copy(writer, os.Stdin)
  reader.Close()
}()
cmd.Stdin = reader
cmd.Stdout = os.Stdout

甚至用结构体简单包装os.Stdin，也会出现同样的阻塞情况：

cmd := exec.Command("env")
cmd.Stdin = struct{io.Reader}{os.Stdin}
cmd.Stdout = os.Stdout

问题根源 #

Go标准库的exec.Cmd在处理标准输入时，会做类型判断：

• 如果Stdin是*os.File类型，会直接将该文件描述符传递给子进程，子进程继承后如果不读取它，执行完毕就会正常退出，不会阻塞。
• 如果Stdin不是*os.File，底层会自动创建一个管道，并启动goroutine将数据从你的Reader复制到这个管道中。只有当Reader返回EOF时，这个复制goroutine才会结束。

核心逻辑大致如下（基于Go 1.21.0）：

if f, ok := c.Stdin.(*os.File); ok {
    return f, nil
}

pr, pw, err := os.Pipe()
if err != nil {
    return nil, err
}
// 启动goroutine将数据从c.Stdin复制到pw...

终端环境下的os.Stdin默认不会主动发送EOF，所以用管道或包装后的Reader时，io.Copy会一直等待读取数据，导致复制goroutine阻塞，进而让整个命令执行流程卡住。

解决方案 #

1. 管道方式的非阻塞处理 #

如果必须通过管道传递输入，关键是要主动告诉子进程没有更多数据，即关闭管道的写入端：

• 如果不需要给子进程传递任何输入，直接关闭写入端即可：

cmd := exec.Command("env")
reader, writer := os.Pipe()
writer.Close() // 主动关闭写入端，发送EOF
cmd.Stdin = reader
cmd.Stdout = os.Stdout
err := cmd.Run()
reader.Close()

• 如果需要复制部分输入数据，复制完成后务必关闭写入端：

cmd := exec.Command("env")
reader, writer := os.Pipe()
go func() {
    defer writer.Close() // 确保复制完成后关闭写入端
    io.Copy(writer, os.Stdin)
}()
cmd.Stdin = reader
cmd.Stdout = os.Stdout
err := cmd.Run()
reader.Close()

2. net.Conn作为输入的场景 #

当用net.Conn作为Cmd.Stdin时，因为net.Conn不属于*os.File，同样会触发内部管道逻辑，解决思路类似：

• 如果客户端会主动断开连接，io.Copy会读到EOF，自动结束复制流程，无需额外处理：

// 假设conn是已建立的网络连接
cmd := exec.Command("env")
r, w := os.Pipe()
go func() {
    defer w.Close()
    io.Copy(w, conn) // 当conn关闭时，Copy自动结束
}()
cmd.Stdin = r
cmd.Stdout = os.Stdout
err := cmd.Run()
r.Close()
conn.Close()

• 如果命令不需要从连接读取数据，直接关闭管道写入端即可避免阻塞：

cmd := exec.Command("env")
r, w := os.Pipe()
w.Close()
cmd.Stdin = r
cmd.Stdout = os.Stdout
err := cmd.Run()
r.Close()

内容的提问来源于stack exchange，提问作者404