Go exec.Command 找不到程序的环境修复

我第一次遇到 exec.Command 找不到程序时，直觉是“子进程的 PATH 没配好”，于是只给 cmd.Env 填了一行 PATH，结果问题依旧。后来把排查拆成两层才发现：程序名能不能被 Go 进程解析，和子进程启动后能不能继续找到别的命令，是两件事。

这篇只处理 PATH 和执行环境。实用结论是：先用 exec.LookPath 或绝对路径确认第一个可执行文件，再用继承后的 os.Environ() 覆盖子进程 PATH；不要把完整环境替换成只有一条 PATH。

先确认错误发生在哪一层

exec.Command("tool") 的参数没有路径分隔符时，Go 会按照当前 Go 进程的 PATH 去解析 tool。这一步还没有使用你后来赋给 cmd.Env 的子进程环境。因此，如果程序只存在于一个自定义目录，单纯给 cmd.Env 增加 PATH，未必能解决“第一个程序找不到”。

先把错误分成三类：创建命令时已经无法解析，通常接近 exec.ErrNotFound；命中了当前目录相关的安全限制，可能是 exec.ErrDot；已经进入 Run 之后才失败，则要看程序自己的 stderr 和退出码。

用 LookPath 看清真正执行的文件

排查时不要只打印传入的程序名。先把解析结果记下来，可以判断是 PATH 没包含目录，还是程序本身启动后才报错：

package main

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

func main() {
    // LookPath 使用当前 Go 进程的 PATH，先确认入口程序能否被解析。
    path, err := exec.LookPath("tool")
    if err != nil {
        // ErrNotFound 表示 PATH 中没有可执行文件；ErrDot 需要单独理解安全边界。
        if errors.Is(err, exec.ErrNotFound) {
            fmt.Println("PATH 中找不到 tool")
        } else if errors.Is(err, exec.ErrDot) {
            fmt.Println("命令解析到了当前目录，请改用明确路径")
        }
        return
    }

    // 用已解析的路径创建命令，日志中的 Path 比原始名称更有诊断价值。
    cmd := exec.Command(path, "--version")
    fmt.Println("准备执行:", cmd.Path)
}

如果日志显示的路径不是预期目录，先修正父进程的 PATH 或直接传入绝对路径。Go 官方文档还说明，当前目录中的相对命令可能触发 ErrDot；确实要运行当前目录文件时，应显式写成 ./tool，而不是依赖 PATH 的隐式匹配。

继承原环境，再覆盖子进程 PATH

当第一个程序已经能被解析，但它启动后还要调用 helper、读取 HOME 或依赖语言环境时，才需要调整 Cmd.Env。Env 非 nil 后不会自动补回父进程变量，所以更稳妥的写法是复制环境，再替换同名 PATH：

package main

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

func main() {
    // 入口程序用绝对路径，避免把子进程 PATH 误当成 Go 进程的解析路径。
    cmd := exec.Command("/opt/tools/bin/report", "--format=json")

    // 先继承完整环境，再只覆盖 PATH，保留 HOME、LANG 等已有变量。
    env := append([]string(nil), os.Environ()...)
    inheritedPath := os.Getenv("PATH")
    childPath := "/opt/tools/bin"
    if inheritedPath != "" {
        childPath += string(os.PathListSeparator) + inheritedPath
    }
    env = setEnv(env, "PATH", childPath)
    cmd.Env = env

    // 这里用 Cmd.Env 反向打印最终配置，便于发现 PATH 是否真的被替换。
    fmt.Println("子进程 PATH:", strings.TrimPrefix(findEnv(env, "PATH"), "PATH="))
}

func setEnv(env []string, key, value string) []string {
    // 先删除同名键，再追加唯一值，避免两个 PATH 同时存在造成误判。
    prefix := key + "="
    kept := env[:0]
    for _, item := range env {
        if !strings.HasPrefix(item, prefix) {
            kept = append(kept, item)
        }
    }
    return append(kept, prefix+value)
}

func findEnv(env []string, key string) string {
    // 从后往前读取最终值，方便排查外部拼接导致的环境覆盖。
    prefix := key + "="
    for i := len(env) - 1; i >= 0; i-- {
        if strings.HasPrefix(env[i], prefix) {
            return env[i]
        }
    }
    return ""
}

这里的关键不是“把 PATH 写得更长”，而是确认入口程序和它的后续依赖分别在哪个环境里解析。若要完全控制 PATH，应该先在配置层生成唯一的 PATH 键，避免手工追加造成两个 PATH 同时存在。

最后用反向检查确认修复

修复完成后，我会按下面的顺序复查：第一，cmd.Path 是否是预期的绝对路径；第二，环境切片里是否只有一个最终 PATH；第三，入口程序是否把自己的 stderr 和退出错误保留下来；第四，如果入口程序内部还要调用其他命令，再确认那些命令位于子进程 PATH 的目录中。

不要用“本机终端能执行”作为唯一证据。IDE、服务管理器、定时任务和容器启动时，父进程环境可能不同。把解析路径和最终 PATH 写入受控调试日志，比在代码里盲目重试更容易定位问题。

常见追问

给 cmd.Env 设置 PATH 后，为什么 tool 还是找不到？

因为 exec.Command 解析入口名称时使用的是当前 Go 进程的 PATH，而不是后来赋值的 cmd.Env。用父进程可见的绝对路径，或在创建命令前解决好入口路径。

为什么不能只写 cmd.Env = []string{"PATH=..."}？

这会让子进程只看到这一组环境变量，可能丢失 HOME、临时目录、区域设置或程序自身需要的配置。通常应从 os.Environ() 复制后再覆盖 PATH。

总结一下：先定位入口，再配置子进程。LookPath 负责看清当前进程能找到什么，Cmd.Path 负责固定要执行的文件，Cmd.Env 负责决定子进程启动后看到什么；把三者分开，exec.Command 的“找不到程序”就不会再靠猜。