Cmd.StdoutPipe()不能直接连shell管道，因os/exec.Cmd不解析shell语法，需用exec.Command("/bin/sh", "-c", "cmd1 | cmd2")显式调用shell解释器，并注意Start后读取、分别处理stdout/stderr、读完pipe防阻塞。
Cmd.StdoutPipe() 不能直接连 shell 管道
Go 的 os/exec.Cmd 本身不解析 shell 语法，StdoutPipe() 返回的是进程自己的 stdout，不是管道左侧命令的输出流。你写 cmd := exec.Command("ls | grep main")，实际会去执行一个叫 ls | grep main 的程序——它不存在，直接报 exec: "ls | grep main": executable file not found。
常见错误现象：exit status 127 或 panic：failed to start command。
- 正确做法是显式调用
/bin/sh并传入-c参数 - 不要把多个命令拼成一个字符串后直接塞给
exec.Command() - 如果只是单个命令（如
ls -l），不用 pipe 也能用StdoutPipe()拿输出
用 /bin/sh -c 配合 StdoutPipe() 实现管道
要让 ls | grep main 这类组合生效，得把整个管道表达式作为字符串传给 shell 解释器：
cmd := exec.Command("/bin/sh", "-c", "ls | grep main")
stdout, err := cmd.StdoutPipe()
if err != nil {
log.Fatal(err)
}
if err := cmd.Start(); err != nil {
log.Fatal(err)
}
// 此时 stdout 是管道最终输出（grep 后的结果）
buf, _ := io.ReadAll(stdout)
fmt.Println(string(buf))
注意点：
立即学习“go语言免费学习笔记（深入）”；
-
/bin/sh更便携；/bin/bash功能多但非所有系统默认安装 -
-c后第一个参数是命令字符串，第二个起才是$0,$1…，别漏掉 - 必须先调用
cmd.Start()才能读StdoutPipe()，否则ReadAll会阻塞或立即 EOF
想捕获 stderr 或同时处理多路输出？别只管 StdoutPipe()
很多场景下，命令出错时 stderr 里有关键信息（比如 grep 没匹配到任何行不会报错，但 ls /noexist | grep x 的错误在 stderr），而 StdoutPipe() 完全收不到。
- 用
cmd.StderrPipe()单独获取 stderr 流 - 若需合并 stdout/stderr，设
cmd.Stderr = cmd.Stdout（但会丢失区分能力） - 更稳妥的做法：分别 pipe，用 goroutine 并发读取，避免某一路卡住导致死锁
- 别在没 Start 前就去 Read —— pipe 是惰性连接，Start 才真正建立管道
Cmd.StdoutPipe() 的生命周期和资源泄漏风险
StdoutPipe() 返回的 io.ReadCloser 必须被读完或显式 Close，否则子进程可能卡在 write 端，后续调用 cmd.Wait() 会永久阻塞。
- 即使命令已退出，未读完的 pipe 缓冲区仍占用内存，尤其大输出时明显
- 用
io.Copy(ioutil.Discard, stdout)或io.ReadAll清空是常见做法 - 如果只关心是否成功、不关心输出内容，改用
cmd.Run()更安全 - 在 defer 中 Close pipe 没用 —— Close 是关读端，不影响写端阻塞；关键是“读完”或“取消读”
管道不是黑盒胶水，它是内核级通道，每一步连接、读取、等待都得对上节奏。少一步，就卡在那儿了。
