cmd.stdoutpipe()不能直接执行shell管道命令，因os/exec.cmd不解析shell语法，需用exec.command("/bin/sh", "-c", "ls | grep main")显式调用shell解释器，并注意start后读取、分别处理stdout/stderr、及时读完pipe防阻塞。
cmd.StdoutPipe() 不能直接执行 shell 管道命令
直接写 exec.Command("ls | grep main") 会报错：exec: "ls | grep main": executable file not found。因为 os/exec.Cmd 不解析 shell 语法，它只找名为 ls | grep main 的可执行文件——显然不存在。
常见错误现象是 exit status 127 或 panic：failed to start command。根本原因是 StdoutPipe() 返回的是该进程自身的 stdout，不是管道左侧命令的输出流。
- 单个命令（如
ls -l）可用StdoutPipe()直接读取 - 含
|、&&、>等 shell 特性的组合命令，必须显式调用 shell 解释器 - 别把多个命令拼成一个字符串后直接塞给
exec.Command()
正确启动带管道的命令：用 /bin/sh -c
要让 ls | grep main 生效，得把整个管道表达式作为字符串传给 shell：
cmd := exec.Command("/bin/sh", "-c", "ls | grep main")
/bin/sh 比 /bin/bash 更便携；-c 后第一个参数是命令字符串，第二个起才是 $0、$1 等变量占位符，别漏掉。
- 必须先调用
cmd.Start()才能读StdoutPipe()，否则io.ReadAll()会阻塞或立即返回 EOF -
StdoutPipe()返回的是最终管道输出（即grep过滤后的结果），不是ls的原始输出 - 如果命令出错（如
ls /noexist | grep x），错误信息在 stderr，StdoutPipe()完全收不到
同时捕获 stdout 和 stderr 的必要性
很多场景下，命令失败时关键信息只出现在 stderr。比如 grep 没匹配到内容不会报错，但 ls 访问不存在路径的错误只发到 stderr。
只管 StdoutPipe() 就等于主动丢弃错误线索。正确做法是分别处理：
stdout, _ := cmd.StdoutPipe() stderr, _ := cmd.StderrPipe() // 启动后，用 goroutine 分别读取 stdout 和 stderr
- 用
io.Copy或bufio.Scanner并发读取两路输出，避免任一 pipe 堵塞导致子进程挂起 - 若只需重定向到文件或终端，直接赋值
cmd.Stdout = someFile或cmd.Stderr = os.Stderr更简洁可靠 - 不要等
cmd.Wait()再读 pipe —— pipe 可能已满，子进程会被内核暂停写入
实时读取时 stdout 缓冲导致的“卡住”问题
用 StdoutPipe() + bufio.Scanner 读长时间运行命令（如 ping 或自定义进度输出）时，常发现输出堆积到最后才刷出。这不是 Go 的 bug，而是子进程的 stdout 缓冲策略切换所致。
当 stdout 连接到终端时默认行缓冲（遇 \n 就 flush），但连到管道时自动切为全缓冲（等满 4–8KB 或进程退出才写）。所以 Go 端看似没数据，其实是子进程还没把内容真正写进 pipe。
- 优先在子进程源码里加
fflush(stdout)（C）或sys.stdout.flush()（Python） - 若无法改子进程，可用
os/exec配合script命令模拟 TTY：如exec.Command("script", "-qec", "your_cmd", "/dev/null") -
bufio.NewReader配合ReadBytes('\n')比Scanner更底层，但依然受缓冲限制，不能替代子进程端修复
真正容易被忽略的是：管道命令的错误流、缓冲行为、以及 Start/Wait 与 pipe 读取的时序关系——这三者不协同，StdoutPipe() 就只是个不可靠的空管道。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
