Go exec.Cmd ExtraFiles 怎么向子进程传递文件描述符

如果父进程已经打开文件、管道或 Unix 文件描述符，又不想把内容重新编码到命令行参数里，可以使用 exec.Cmd.ExtraFiles。它的规则很简单：标准输入、输出、错误分别占用 0、1、2，ExtraFiles[i] 在子进程中对应 3+i。也就是说，第一项不是“随机继承”的句柄，而是子进程明确可读取的 fd 3。

实战中最稳妥的做法是：父进程打开资源并放入 ExtraFiles，再通过参数或环境变量约定“子进程读取 fd 3”；子进程用 os.NewFile 接管它，读完关闭，父进程则等到 Wait 返回后再关闭自己的副本。

先把 3+i 的编号关系弄清楚

ExtraFiles 不包括标准流。切片第一项映射到 fd 3，第二项映射到 fd 4。父进程手里的原始 fd 可能是 7 或 11，这个数字不会直接传给子进程；子进程只需要遵守 ExtraFiles 的位置约定。下面的结构图只表达静态关系，不是终端截图或运行证据。

父进程打开文件并绑定 ExtraFiles

下面用同一个可执行文件模拟父子两种角色。父进程打开一个文本文件，把它放在切片第一项；启动子进程后，子进程固定从 fd 3 读取。真实项目中也可以把 socket 或匿名管道的文件对象放到同一位置。

package main

import (
    "fmt"
    "io"
    "os"
    "os/exec"
)

func main() {
    // 用参数区分父进程和子进程，避免再维护一个单独的示例程序。
    if len(os.Args) > 1 && os.Args[1] == "child" {
        child := os.NewFile(uintptr(3), "extra-input")
        if child == nil {
            fmt.Fprintln(os.Stderr, "fd 3 不可用")
            os.Exit(2)
        }
        defer child.Close() // 子进程读取完成后释放自己的描述符副本

        data, err := io.ReadAll(child)
        if err != nil {
            fmt.Fprintln(os.Stderr, "读取 fd 3 失败:", err)
            os.Exit(3)
        }
        fmt.Printf("子进程收到 %d 字节: %s", len(data), data)
        return
    }

    input, err := os.Open("message.txt")
    if err != nil {
        fmt.Fprintln(os.Stderr, "打开输入文件失败:", err)
        os.Exit(1)
    }
    defer input.Close() // 父进程保留到 Wait 返回，随后关闭自己的副本

    cmd := exec.Command(os.Args[0], "child")
    cmd.ExtraFiles = []*os.File{input} // 切片第 0 项在子进程中就是 fd 3
    cmd.Stdout = os.Stdout
    cmd.Stderr = os.Stderr

    if err := cmd.Start(); err != nil {
        fmt.Fprintln(os.Stderr, "启动子进程失败:", err)
        os.Exit(4)
    }
    if err := cmd.Wait(); err != nil { // Start 成功后必须 Wait，回收进程资源
        fmt.Fprintln(os.Stderr, "等待子进程失败:", err)
        os.Exit(5)
    }
}

这段代码的关键不是父进程原始 fd 的数值，而是切片下标。若再传一个文件，写成 cmd.ExtraFiles = []*os.File{input, another}，子进程就要按约定从 fd 3 和 fd 4 分别读取。

子进程读取时，偏移和关闭时机最容易出错

ExtraFiles 传递的是打开文件的继承关系，不会自动把文件内容复制一份。如果父进程在 Start 前已经读过这个文件，子进程看到的文件偏移可能已经变化；需要从头读取时，应在父进程绑定前调用 input.Seek(0, io.SeekStart)，并检查返回错误。

父进程的 defer input.Close() 不会妨碍子进程在启动后读取，但如果父进程在 Start 后立刻关闭并继续依赖复杂的退出协议，就很难判断问题来自描述符还是进程生命周期。把关闭动作放在 Wait 之后更容易排查。子进程侧也应在读取完毕后关闭 os.NewFile 返回的对象。

按证据排查“子进程读不到”的情况

第一，确认运行平台。官方文档明确说明 ExtraFiles 在 Windows 不受支持；这不是路径或权限调整可以解决的问题。第二，确认切片真的非空，且子进程读取的是 3+i，不要把父进程打印出来的原始 fd 直接写死。第三，确认父进程没有提前把共享偏移读到文件末尾；空文件和已经到 EOF 的文件都会表现为“读不到内容”。

第四，确认文件打开模式允许目标操作，读取文件就用只读句柄，写入则让父子进程明确谁负责写入和关闭。第五，确认 Start 成功后执行了 Wait；只调用 Start 会遗留进程和相关资源。对于管道或 socket，还要约定何时关闭写端，否则子进程可能一直等不到 EOF。

一个可复用的检查清单

• 每个额外文件的切片位置是否和子进程约定一致？
• 是否记住第一项是 fd 3，而不是父进程原始 fd？
• 是否在 Start 前处理了需要的文件偏移？
• 父子两侧是否都在职责完成后关闭句柄，并由父进程调用 Wait？
• 是否把 Windows 不支持和管道 EOF 作为明确的平台/生命周期边界？

掌握这几个边界后，ExtraFiles 就适合用来传递文件、管道和 Unix 句柄；它解决的是继承和编号问题，不会替你设计子进程协议，也不会替你处理跨平台抽象。

相关问题

ExtraFiles 能传标准输出吗？

不能把它当作标准输出的替代配置。标准输入、输出、错误应分别使用 Stdin、Stdout、Stderr；额外资源才放进 ExtraFiles。

子进程为什么读取 fd 3 得到 EOF？

优先检查文件是否为空、父进程共享偏移是否已在末尾，以及是否把切片项放错位置。若传的是管道或 socket，再检查所有不需要的写端是否已关闭。