Go中无系统级IPC管道，所谓“管道”实为channel协程通信或os.Pipe/exec.Cmd模拟；channel是进程内内存队列，os.Pipe返回Unix管道fd，二者不可混淆。
Go 里没有操作系统级的 IPC 管道（如 Linux 的 pipe(2)），所谓“管道通信”实际指 channel 协程间通信，或用 os.Pipe / exec.Cmd 模拟 shell 管道行为。混淆这两者是绝大多数初学者 panic 和死锁的根源。
区分 channel 通信和系统级 pipe
很多人搜“golang 管道 IPC”，默认以为 Go 有类似 C 的 pipe() 系统调用直通内核——其实没有。channel 是 Go 运行时实现的内存队列，只在进程内有效，不跨进程、不持久、不与文件描述符互通。
-
channel：用于 goroutine 之间同步/异步数据传递，类型安全，带阻塞语义，close()后可读尽剩余值 -
os.Pipe()：返回一对*os.File（readEnd,writeEnd），是真正的 Unix pipe fd，可用于子进程通信，但需手动管理生命周期和 close -
exec.Command链式调用：必须靠StdoutPipe()+io.Copy或sh -c实现，不能写cmd1 | cmd2
用 exec.Command 实现 shell-style 管道（两段）
想跑 ls | grep main？别试图用两个 exec.Command 直接拼，Go 不支持运算符重载式的管道语法。
- 必须先调用
cmd1.Start()，再用cmd1.StdoutPipe()获取 reader - 把该 reader 赋给
cmd2.Stdin，且cmd2.Stdout显式设为&bytes.Buffer{}或os.Stdout，否则输出丢失 -
cmd1.Wait()必须在cmd2.Run()之后调用；若提前 Wait，reader 可能被关闭，cmd2读不到 EOF - 错误示例：
exec.Command("ls").Run(); exec.Command("grep", "main").Run()—— 这是顺序执行，不是管道
多级管道（≥3 命令）优先用 sh -c
手动串联 ps | grep | awk 容易卡死：某一级没及时读 stdin、某一级提前退出、goroutine 泄漏、io.Copy 阻塞未处理超时……真实项目中几乎没人手撸。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- Linux/macOS：直接
exec.Command("sh", "-c", `ps aux | grep go | awk '{print $2}'`) - Windows：换
exec.Command("cmd", "/c", "tasklist | findstr \"go\"")，注意语法不兼容（无原生|） -
sh -c方式无法单独捕获中间命令退出码，但胜在简洁、健壮、符合直觉 - 只有当你需要审计每条命令的 stderr、精确控制每个子进程生命周期、或禁用 shell 解析（如沙箱环境）时，才考虑手动 pipe 链
channel 关闭时机与 range 死锁
协程链式处理（比如 gen → filter → print）里，close(ch) 位置错一毫秒，下游就永远卡在 for range ch 上。
- 必须由**最后一个发送方**关闭 channel，且仅一次；接收方绝不关
- 所有消费者（包括中间环节）必须用
for range ch，不是for { select { case x := ，否则关了也收不到 EOF - 如果某个环节可能提前退出（比如过滤空值后不发），仍要确保后续环节能收到关闭信号——常见做法是加一个
done chan struct{}配合select - 缓冲 channel 关闭后仍可读尽缓存值，但无缓冲 channel 关闭瞬间，若无人在等接收，
range会立刻退出
最常被忽略的一点：channel 生命周期和 goroutine 存活是绑定的。一个没被 range 的 channel，哪怕关了，只要还有 goroutine 在 ，它就永远阻塞——这不是 bug，是设计。你得自己决定谁负责 cleanup，而不是指望 GC。
