Bash中单命令输出供另一命令使用：管道与进程替换孰优？

好问题！我刚好深入研究过这两种写法在Bash中的差异，结合你关注的性能优先+健壮性需求，来拆解下var=$(cmd2 < <(cmd1))相比var=$(cmd1|cmd2)的具体优势：

1. 性能：更少的子进程开销 #

这是最核心的优势：

• 管道写法cmd1|cmd2会创建两个独立的子进程（cmd1和cmd2各占一个），再加上$(...)本身会创建的一个子进程，总共是3个子进程。
• 进程替换写法cmd2 < <(cmd1)中，cmd1是一个后台子进程，而cmd2是在$(...)的子进程中运行——总共只有2个子进程。

少一个子进程意味着减少了一次fork/exec的系统调用开销，在频繁循环调用或者处理大量任务时，这个差异会被放大，明显提升性能。

2. 健壮性：更灵活的退出码处理 #

管道的一个痛点是退出码的获取：

• 默认情况下，$?只会返回管道最后一个命令（cmd2）的退出码。如果要获取cmd1的退出码，必须依赖Bash的PIPESTATUS数组（${PIPESTATUS[0]}），但这个数组只在管道执行后的当前shell环境有效，逻辑稍复杂。
• 进程替换写法中，cmd1作为后台进程，你可以通过$!拿到它的PID，再用wait $!获取它的退出码，同时cmd2的退出码可以直接用$?（在$(...)执行后）获取，两者的状态分离更清晰，便于错误处理。

3. 兼容性与命令行为一致性 #

有些命令在处理普通文件输入和管道输入时行为不同：

• 管道输入是流式的，部分命令可能会因为无法随机读取（比如seek操作）而表现异常。
• 进程替换<()会创建一个临时的文件描述符（本质是/dev/fd下的特殊文件），对cmd2来说，它就像读取一个普通文件，支持随机访问，能兼容那些依赖文件特性的命令，避免意外行为。

4. 与你熟悉的while read写法逻辑统一 #

你已经在使用while read do done < <(cmd)，这种写法的核心优势是避免管道导致的子shell变量丢失问题。而var=$(cmd2 < <(cmd1))和它遵循同样的进程替换逻辑，保持了代码风格的一致性，后续维护起来更顺手。

总结 #

如果你的核心需求是性能，进程替换写法的子进程开销更小，绝对是更优选择；同时它在退出码处理、命令兼容性上也更健壮。对于你提到的多个var=$(cmd1|cmd2)实例，替换成var=$(cmd2 < <(cmd1))完全值得，尤其是在高频调用场景下，性能提升会很明显。

内容的提问来源于stack exchange，提问作者Umm