管道符|的本质是将前一个进程的stdout直接连接到后一个进程的stdin，实现字节流并发传输，不经过磁盘；仅读取stdin的命令（如grep、xargs）才能接在|后，且需注意数据格式、错误捕获与特殊字符处理。
管道符 | 的本质是啥
它不是“把前一个命令的输出变成后一个命令的输入”这种模糊说法，而是让前一个进程的 stdout 直接连到后一个进程的 stdin，中间不经过磁盘或临时文件。这意味着：
- 两个命令是并发运行的，不是等左边跑完再启动右边
- 如果右边命令（比如
grep）很快退出，左边命令可能收到SIGPIPE而直接终止 - 管道里传的是字节流，不是“行”也不是“结构化数据”，换行符只是巧合被当成分隔符
所以别指望 ls | echo 能把文件名“传进去”——echo 不读 stdin，它只处理参数。
哪些命令能接在 | 后面？看它是否读 stdin
不是所有命令默认从标准输入读数据。常见误区是以为 cp、mv、touch 这类命令能接管道，其实不能。它们设计上只接受参数（文件路径），不读 stdin。
真正能接在 | 后面的，通常是这些：
-
grep、sed、awk、sort、uniq—— 原生支持流式处理 -
head、tail、wc—— 默认从stdin读，除非给了文件参数 -
xargs—— 把标准输入转成命令行参数，是“管道不可用”时的关键桥梁
验证方法很简单：echo "test" | your_command，没报错且有输出，大概率支持。
xargs 是怎么补上管道短板的
比如你想对 find 找到的每个文件执行 chmod，不能写 find . -name "*.log" | chmod 644 —— chmod 不认管道输入。
这时候用 xargs 中转：
find . -name "*.log" | xargs chmod 644
注意几个坑：
- 文件名含空格或换行时会出错，加
-0和-print0配合：find . -name "*.log" -print0 | xargs -0 chmod 644 -
xargs默认把所有输入拼成一行参数，可能超系统限制；加-n 1可逐个执行：... | xargs -n 1 cp /tmp/ -
echo "a b" | xargs echo "prefix"输出是prefix a b，不是prefix a和prefix b—— 它把整行当一个参数，除非用-n 1
管道链里出错，怎么定位是哪个环节挂了
管道整体返回值是**最后一个命令的退出码**，前面的失败会被吞掉。比如 false | true 返回 0，你以为成功了，其实第一个就失败了。
要检查中间环节，有两个实用办法：
- 启用
set -o pipefail（写在脚本开头或交互式执行）：只要任意一环非零，整个管道就报错 - 用
$PIPESTATUS数组查每个命令的退出码：ls /nope | wc -l; echo ${PIPESTATUS[@]}会输出类似2 0，说明ls失败（2），wc成功（0） - 别依赖
||放管道末尾：cmd1 | cmd2 || echo fail只反映cmd2是否失败
复杂管道里混着 grep、awk、xargs，最容易忽略的是数据格式突变——比如 ps aux | grep nginx 实际会匹配到 grep nginx 自己这一行，得写成 ps aux | grep [n]ginx 或者用 pgrep 更干净。这种细节不试一遍根本想不到。
