Go os/exec 怎样让子进程继承环境变量

在 Go 里让 os/exec 启动的子进程继承父进程环境，最简单的做法是不要给 cmd.Env 赋值，保持它为 nil。如果既要继承原有变量，又要增加或覆盖某个变量，就从 os.Environ() 复制一份，再追加 KEY=value。

常用写法如下：

cmd := exec.Command("your-program")
cmd.Env = append(os.Environ(), "APP_MODE=production")
err := cmd.Run()

其中，Env == nil 表示使用当前进程的环境；一旦把 Env 设置成非 nil 的切片，子进程就只会看到这份切片里的变量。本文围绕这个选择比较三种方案，重点解决“追加一个变量后，为什么原来的 PATH 或代理配置不见了”这类问题。

先看 Env 的两种状态

exec.Cmd.Env 的每个元素都应是 key=value 形式。官方文档定义了两个关键行为：

• Env 为 nil 时，子进程使用当前进程的环境。
• Env 非 nil 时，子进程使用这份显式环境，不会自动把父进程的其他变量再补回来。

所以，下面的写法不是“在继承基础上增加一个变量”，而是把子进程环境限制成只有一个键：

cmd := exec.Command("sh", "-c", "printf '%s\\n' \"$APP_MODE\"")
// 显式环境只有 APP_MODE，父进程的 PATH 等变量不会自动复制过来。
cmd.Env = []string{"APP_MODE=production"}
if err := cmd.Run(); err != nil {
    log.Fatal(err)
}

如果子进程还要调用其他程序，缺少 PATH 可能让后续命令解析失败；如果程序依赖代理、区域或语言变量，也会出现“本机直接执行正常，Go 启动后行为不同”的现象。

三种写法怎么选

方案一：原样继承，保持 Env 为 nil

只需要让子进程使用当前运行环境时，不要为了“明确继承”而手动拼切片：

cmd := exec.Command("your-program", "--input", "data.txt")
// Env 保持 nil，子进程直接继承当前进程环境。
if err := cmd.Run(); err != nil {
    log.Fatal(err)
}

这是最少出错的选择，适合本地工具调用、需要沿用 PATH 的构建命令，以及不需要改变运行配置的辅助进程。

方案二：继承后追加或覆盖，优先使用 os.Environ

大多数业务代码属于这一类：保留父进程环境，同时给子进程传入一个开关、工作模式或临时目录。

package main

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

func main() {
    // 使用类 Unix shell 读取变量；Windows 项目应替换为对应的命令和参数。
    cmd := exec.Command("sh", "-c", "printf 'APP_MODE=%s\\n' \"$APP_MODE\"")

    // 先复制父进程环境，再追加业务变量，避免丢失 PATH 等已有配置。
    cmd.Env = append(os.Environ(), "APP_MODE=production")

    // Run 会等待子进程结束，并把启动或退出错误返回给调用方。
    if err := cmd.Run(); err != nil {
        log.Fatal(err)
    }
}

如果追加的键在父进程环境中已经存在，Go 文档规定重复键时使用切片中最后一个值。因此，把覆盖项放在 os.Environ() 后面，表达更清楚：

env := append([]string{}, os.Environ()...)
// 同名键放在后面，用新的值覆盖父进程中的旧值。
env = append(env, "APP_MODE=staging")
cmd.Env = env

方案三：只传白名单，明确隔离运行环境

当子进程不应该看到父进程的完整配置时，显式白名单才是合适方案。例如只传一个公开的区域设置：

cmd := exec.Command("your-program")
// 只传递明确允许的变量；不要把密钥、代理等父进程变量顺手带入。
cmd.Env = []string{"APP_REGION=cn"}
if err := cmd.Run(); err != nil {
    log.Fatal(err)
}

这种写法的代价是需要自己考虑命令运行所需的变量。它适合构建沙箱边界、减少配置泄漏，或需要让同一个程序在稳定、可复现的环境中运行的场景；不适合“只是临时增加一个变量”的需求。

追加变量时最容易忽略的两个细节

重复键看最后一个值

os.Environ() 返回的是当前进程环境的副本。追加同名键不会报错，而是由切片后面的值生效。可以把它理解为“后写入的配置覆盖先写入的配置”，但不要在同一个切片中堆积大量重复键，否则排查时很难看出最终值。

Env 非 nil 时不要期待 PATH 自动补回

如果使用白名单环境而子进程还需要执行外部命令，应把必要的 PATH 或其他运行变量显式加入。更稳妥的做法是直接传可执行文件的明确路径，或者使用 exec.LookPath 先解析路径，再把运行环境作为独立问题处理。

命令选择和平台边界

os/exec 不会自动调用系统 shell，也不会替你展开通配符、管道或重定向。上文用 sh -c 只是为了让示例中的子进程读取环境变量；在 Windows 上应换成目标平台可用的程序和参数，不能把 sh 当成跨平台抽象。

如果设置了 cmd.Dir，它会影响子进程的工作目录；在 Unix 系统中，Go 还会根据该目录处理子进程的 PWD。工作目录、可执行文件路径和环境变量是三个独立配置，不要只改 Env 来解决路径问题。

另外，一个 Cmd 在调用 Run、Start、Output 或 CombinedOutput 后不能再次复用。需要运行两次时重新创建命令对象，并为每次调用准备清晰的环境切片。

一张表做最后决策

因此，标题问题的直接答案是：默认继承就让 Env 保持 nil；需要在继承基础上增加变量时使用 append(os.Environ(), "KEY=value")；只有确实需要隔离时，才设置最小白名单。

相关问题

给 cmd.Env 赋值后为什么找不到命令？

常见原因是显式环境没有包含子进程或其后续命令需要的 PATH。如果只是追加变量，改用 append(os.Environ(), ...)；如果是隔离环境，则显式提供必要变量或使用明确的可执行文件路径。

可以直接修改 os.Environ 返回的切片吗？

可以把它当作当前环境的副本来拼接，但为了表达“不会改动原切片”，通常写成 append([]string{}, os.Environ()...) 后再追加，尤其适合后续还要复用这份基础环境的代码。

cmd.Env 中同名变量会怎样？

同名键重复出现时，切片中最后一个值生效。追加覆盖值时把它放在父环境副本之后，并尽量避免在多个函数层反复追加同一个键。

os/exec 会自动执行 shell 语法吗？

不会。管道、重定向、通配符和变量展开都不是 exec.Command 自动提供的能力；需要 shell 语法时要显式启动对应 shell，并自行评估参数边界。