Go exec.Cmd 怎样安全合并子进程环境变量

Go exec.Cmd 合并子进程环境变量时，应先取继承环境的副本，再追加受控的覆盖项，例如 cmd.Env = append(cmd.Environ(), "APP_MODE=preview")。非 nil 的 Env 是完整环境列表，不是增量补丁；直接赋值成只有一项的切片会丢失其他继承项。这里的“安全”指避免误改父进程和意外丢项，不代表继承所有变量就适合运行不受信任的程序。

官方文档：https://pkg.go.dev/os/exec

只改一次任务，我会先把配置留在 Cmd 上

设想一个批处理服务：同一个父进程发起两个任务，一个使用 preview 模式，另一个使用 live 模式。我会优先把 APP_MODE 放在各自的 Cmd.Env 中，而不是在启动前后修改 os.Setenv。这个选择来自作用范围：父进程环境是进程级共享状态，不能靠“设置、启动、恢复”的顺序自然实现并发任务隔离。

最容易误解的地方是 Env 的名字。它看起来像一组额外配置，实际上只要被显式赋值，就承担完整环境列表的角色。对我来说，把变量来源先区分清楚，比写一个复杂的合并器更重要。

环境从哪里来：nil 和空切片不是一回事

os.Environ() 返回当前进程环境，而 cmd.Environ() 返回命令按当前配置将使用的环境副本。若 Cmd 已经显式设置 Env，再调用 Environ 得到的是该命令配置的副本，不会神奇补回先前丢掉的父进程变量。Windows 上还存在 SYSTEMROOT 的特殊补充规则，因此不要把显式空环境理解成所有平台都必然一个变量不剩。

设置工作目录后，再生成命令环境副本

// 配置片段：所在文件需导入os/exec；worker应换成受信任的程序路径。
cmd := exec.Command("/trusted/bin/worker")
cmd.Dir = "/trusted/work" // 按实际工作目录替换，先于Environ设置。
cmd.Env = append(cmd.Environ(), "APP_MODE=preview")
// 启动与错误处理由调用方负责；这里只构造单个命令的环境。

cmd.Environ 自 Go 1.19 提供。使用支持它的工具链时，我会先设置 Dir，再获取环境副本，这样在使用 PWD 的平台上，副本能反映当前命令配置。若提前取副本再改 Dir，显式环境里已有的 PWD 可能与新目录不一致。这里不需要手写 PWD，更不该把它当作任务私有变量复用。

Cmd.Env 对重复键使用切片中最后的值，所以追加固定覆盖项很简洁。但该行为只解决冲突选择，不负责检查变量是否应该交给子程序。APP_MODE 这类值应来自明确的允许集合，而不是将任意请求字段全部转成环境项。

空值不是删除，我会把这两种需求拆开

APP_MODE= 表示键存在但值为空；删除则要求从继承切片中移除对应项。仅在末尾追加空值并不等于删除。子程序使用 LookupEnv 时可以区分这两种状态，用 Getenv 则二者都会得到空字符串。

环境项采用 key=value 形式，值里可以继续有等号，拆分时应只找第一个等号。普通业务键不应为空、不应包含等号或 NUL，值也不能包含 NUL。本文使用固定 APP_MODE，不接受外部任意键名；若需要构造通用配置入口，应先限制允许键和值，并把非法输入作为配置错误处理。

Windows 的环境键名比较需要考虑大小写，不能用 Unix 的严格同名过滤直接套用。还可能有以等号开头的特殊环境条目；下面的辅助函数保留这些条目，只处理普通业务键。若改成从零构造的最小允许列表，平台必需项和目标程序依赖仍需单独考虑。

完整例子：给自身子进程一个固定覆盖值

这个例子让当前程序以 --env-child 参数作为子进程启动，不依赖外部 worker，也不打印父进程的完整环境。辅助函数先过滤 APP_MODE 的旧项，再添加唯一的新项。为保持主题集中，程序只演示环境构造；生产任务仍需按自己的要求配置取消、超时和退出码策略。

package main

import (
    "fmt"
    "os"
    "os/exec"
    "runtime"
    "strings"
)

// 删除指定键；Windows按不区分大小写比较，其他平台按原样比较。
func withoutKey(env []string, target string) []string {
    out := make([]string, 0, len(env))
    for _, item := range env {
        // Windows特殊的=开头条目原样保留，不把它当作普通业务键。
        if strings.HasPrefix(item, "=") {
            out = append(out, item)
            continue
        }
        pos := strings.IndexByte(item, '=')
        if pos 

读者执行后，子进程中 APP_MODE 应存在且值为 preview，这是根据代码给出的预期，不是本机运行记录。父进程没有调用 Setenv，因此不会因本例而改变自己的 APP_MODE。可把追加项替换成 APP_MODE= 观察空值存在；删除过滤后的追加语句，则该业务键不再显式出现在给子进程的环境中。

便利的继承，也有我不愿忽略的代价

继承整套环境适合受信任工具，但其中可能包含凭据、代理配置或其他影响目标程序行为的设置。面对不受信任程序，我不会把“保留所有继承项”当成安全目标，而会采用明确的最小允许列表。也不要把完整 Env 打入排错日志；本例只展示非敏感 APP_MODE，即使配置失败，也不回显未知值。

每个任务应使用独立 Cmd 和独立切片，不要在启动期间并发修改同一个 Cmd.Env。环境副本只是某一时点的配置，父进程之后的更改不自动同步到已经显式设置的列表。用完后让临时副本不再被引用即可，不要为了“清理子进程配置”去删除父进程变量；这也不意味着内存里的敏感字符串已被可靠擦除。

常见问题

只给子进程设置 PATH，能改变 exec.Command 找程序的位置吗？

Command 处理不带路径的程序名时会先进行路径查找。随后设置 Cmd.Env 的 PATH 不应被当作重新选择程序的机制；需要确定程序身份时使用受信任的明确路径。

旧工具链没有 cmd.Environ 怎么办？

可以以 os.Environ 作为继承来源，但它是父进程副本，不能等价宣称已经融合了 Dir 对 PWD 的影响。需要支持的版本与目录语义应在项目中明确。

环境变量能替代权限隔离吗？

不能。Env 控制配置项，不限制子进程访问文件、网络或其他系统资源。本文的合并方法不是沙箱。

我的取舍是：受信任子程序需要兼容父环境时，用命令环境副本追加受控覆盖；涉及敏感继承时，用允许列表另行构造。把来源、覆盖、删除和日志范围分清楚，才能让单次任务配置保持可解释。