go中实现shell管道需先调用stdoutpipe/stdinpipe再start命令，用goroutine异步io.copy连接，并显式关闭写端；pipe方法必须在start前调用，否则读不到数据。
Go 里没有 shell 那种 | 管道符语法，但可以用 exec.Cmd 的 StdoutPipe 和 StdinPipe 手动拼出等效效果——关键不是“怎么写符号”，而是“怎么连 stdin/stdout”。
exec.Command 怎么链式调用两条命令（类似 shell 的 cmd1 | cmd2）
shell 的 | 实际是把前一个进程的 stdout 指向后一个进程的 stdin。Go 中需手动建立这个连接：
- 先创建两个
exec.Command：比如cmd1 := exec.Command("cat", "input.txt")、cmd2 := exec.Command("grep", "pattern") - 调用
cmd1.StdoutPipe()得到一个io.ReadCloser，它就是cmd1的输出流 - 调用
cmd2.StdinPipe()得到一个io.WriteCloser，它就是cmd2的输入流 - 用 goroutine 把前者读出的数据写入后者：
io.Copy(cmd2.Stdin, cmd1.Stdout)（注意顺序！不能反过来） - 必须先
Start()两个命令，再做io.Copy；否则cmd2可能因没输入而阻塞或退出
为什么 cmd1.StdoutPipe() 要在 Start() 前调用
StdoutPipe() 不是“打开管道”，而是“预约一个将来可用的输出句柄”。如果在 Start() 后调用，进程已启动但 stdout 未被接管，输出会直接刷到终端或丢失，StdoutPipe() 返回的句柄也无效。
- 错误写法：
cmd.Start(); pipe, _ := cmd.StdoutPipe()→pipe读不到任何数据 - 正确顺序：声明命令 → 调用
StdoutPipe()/StdinPipe()→Start()→ 处理数据流 - 所有
Pipe()方法都必须在Start()前调用，包括StderrPipe()
处理大文件时容易卡死或丢数据？检查缓冲和关闭时机
用 io.Copy 连接管道看似简单，但实际中常因 goroutine 协作不当导致 hang 住或提前关闭：
- 别用
cmd.Wait()等待子进程结束再处理输出——Wait()会阻塞直到进程退出，而输出可能还没读完 - 应该用
go func() { io.Copy(dst, src); dst.Close() }()异步搬运，并确保目标端（如cmd2.Stdin）在搬运结束后显式Close() - 若目标命令（如
head -n 10）提前退出，它的 stdin 写入会返回broken pipe错误，此时应停止搬运，避免 goroutine 挂起 - 对大文件，避免用
bytes.Buffer全量读取；优先用io.Copy流式转发
Windows 下命名管道（Named Pipe）不等于 os.Pipe()
os.Pipe() 创建的是匿名管道，仅限父子进程间通信；Windows 的命名管道（如 \.pipemyapp）需要额外依赖 github.com/Microsoft/go-winio，且服务端必须设好安全描述符才能被普通权限客户端访问。
- 跨用户/跨权限场景下，
os.Pipe()完全不可用，别硬套 -
go-winio.ListenPipe创建的服务端默认拒绝非管理员连接，需传入&winio.PipeConfig{SecurityDescriptor: "..."} - Linux/macOS 没命名管道原生支持，FIFO（
mknod）是文件系统级对象，与 Go 的os.Pipe()无关
真正难的不是连通两个命令，而是控制数据流边界：什么时候该关写端、什么时候该停读端、错误发生时哪边先退出、是否要等全部子进程 Wait() ——这些细节不处理好，程序就卡在 Read 或 Write 上不动了。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
