Go os/exec.Cmd.ExtraFiles 怎样把已打开文件传给子进程

我在把一份已经打开的中间文件交给子进程时，最初也想过直接把文件路径放进参数里。后来发现，路径方案会把临时目录、权限和跨进程约定一起暴露出来；如果父进程已经拿到了正确的文件句柄，os/exec.Cmd.ExtraFiles 反而更直接。

官方地址：https://pkg.go.dev/os/exec#Cmd

在 Unix-like 环境中，把文件放进 ExtraFiles 后，子进程按约定的文件描述符读取即可：ExtraFiles[0] 对应 fd 3，ExtraFiles[i] 对应 fd 3+i。关键不是“把路径传过去”，而是让父子进程共享一份清晰的编号和关闭约定。Windows 不适用这套字段。

先划定目标：传文件句柄，不是传路径

Cmd.ExtraFiles 接收的是已经打开的 *os.File。父进程可以先完成打开、写入、定位和权限处理，再把这个文件放进切片；子进程只需要知道它会从哪个文件描述符读取，不需要知道父进程的临时路径。

这条边界适合管道前置处理、一次性导出、父进程负责权限检查而子进程负责解析等场景。它不等于通用的进程守护方案，也不替代标准输入、标准输出或跨平台句柄抽象。

完整工作流总览

父进程：打开、定位并绑定 ExtraFiles

下面的单文件示例用自身可执行文件再次启动一个 child 模式。这样示意代码同时包含父子两侧，重点是句柄边界，不是制造一个完整的命令行框架。

package main

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

func main() {
    if len(os.Args) > 1 && os.Args[1] == "child" {
        runChild()
        return
    }
    if err := runParent(); err != nil {
        log.Fatal(err)
    }
}

func runParent() error {
    // 父进程先创建并打开文件，子进程不需要知道这个临时路径。
    file, err := os.CreateTemp("", "extra-files-*.txt")
    if err != nil {
        return err
    }
    path := file.Name()
    defer os.Remove(path) // 删除目录项，文件句柄的关闭由下面的逻辑负责。

    if _, err := file.WriteString("来自父进程的内容\n"); err != nil {
        file.Close()
        return err
    }
    if _, err := file.Seek(0, io.SeekStart); err != nil {
        file.Close()
        return err
    }

    // ExtraFiles[0] 会在 Unix-like 子进程中对应文件描述符 3。
    cmd := exec.Command(os.Args[0], "child")
    cmd.ExtraFiles = []*os.File{file}
    cmd.Stdout = os.Stdout
    cmd.Stderr = os.Stderr

    if err := cmd.Start(); err != nil {
        file.Close()
        return err
    }
    // Start 成功后，子进程已经拿到自己的副本；父侧句柄可以关闭。
    if err := file.Close(); err != nil {
        return err
    }
    return cmd.Wait()
}

func runChild() {
    // ExtraFiles[0] 的约定编号是 3，子进程不依赖父进程的路径。
    file := os.NewFile(uintptr(3), "extra-input")
    if file == nil {
        log.Fatal("无法接收 fd 3")
    }
    defer file.Close() // 子进程只负责关闭自己的文件描述符副本。

    data, err := io.ReadAll(file)
    if err != nil {
        log.Fatal(err)
    }
    if _, err := fmt.Print(string(data)); err != nil {
        log.Fatal(err)
    }
}

这里有三个容易混淆的点：第一，ExtraFiles 的索引从 0 开始，但 Unix 子进程的额外描述符从 3 开始；第二，Start 之前不能把父侧文件提前关闭；第三，父子两侧各有自己的关闭责任，父侧关闭不会替子进程关闭 fd 3。

ExtraFiles 的编号约定到底是什么

官方约定是：切片中的第 i 个文件，在 Unix 子进程中成为文件描述符 3+i。因此单个文件使用 ExtraFiles[0] 时，子进程读取 fd 3；如果再放入第二个文件，它就是 fd 4。

这个编号必须成为父子程序之间的接口约定。不要让子进程“猜”哪个 fd 有数据，也不要因为某个环境里恰好出现了其他打开的描述符，就把 3 改成一个未经约定的数字。

父子进程的关闭边界

我实际使用时会把 Start 看成一个很明确的边界：在它之前，父进程要保证所有传入文件都有效；在它成功之后，父进程可以关闭自己的句柄，而子进程继续使用它收到的描述符。子进程读取完成后，再关闭自己的副本。

如果使用 cmd.Run()，关闭父侧句柄的时机通常放在 Run 内部已经完成启动之后难以单独表达，所以更适合用 Start 加 Wait 清楚地写出边界。无论选择哪种调用方式，都要确保子进程启动前文件没有被关闭。

我踩过的几个坑

把 ExtraFiles 当成标准输入

如果只是传一段连续数据，标准输入往往更简单；ExtraFiles 更适合子进程需要一个有独立编号、可按文件语义访问的已打开文件。不要为了“看起来高级”而替换更合适的接口。

忘记调整读取偏移

父进程写完文件后，如果当前偏移已经在末尾，子进程从继承来的文件描述符读取时可能只看到空内容。示例中的 Seek(0, io.SeekStart) 就是在绑定前把读取位置放回开头。

把平台边界藏起来

ExtraFiles 的文档明确说明它不适用于 Windows。跨平台程序应在架构层选择标准输入、临时路径、命名管道或平台专用实现，并在代码入口处显式表达这个条件，而不是让调用者在运行时才遇到空数据或启动异常。

只关父侧，不关子侧

父进程关闭自己的句柄并不等于子进程完成清理。子进程拿到 fd 3 后仍然要把它当作自己的资源处理，尤其是在提前返回、读取失败或解析器抛错的分支中。

一张速查表

最后的判断

如果父进程已经完成了文件打开和权限判断，且子进程只需要读取这份句柄，Cmd.ExtraFiles 是一条边界清楚的 Unix-like 进程协作路径。我的建议是先把 fd 编号、Start 边界和两侧关闭责任写进接口约定，再决定是否需要它；如果目标是 Windows 或真正的跨平台交付，就不要把这个字段当成唯一方案。

相关问题

ExtraFiles[1] 会映射到哪里？ 映射到 fd 4，规则是 fd 3+i。

必须把文件路径也传给子进程吗？ 不需要。子进程按约定的文件描述符取得已打开文件，但它必须知道这个编号和文件用途。

为什么不直接使用标准输入？ 单路连续数据可以用标准输入；需要多个独立文件或明确的文件描述符接口时，ExtraFiles 更贴合问题。