管道性能优化核心是减少冗余数据处理与缓冲阻塞：用head/sed/tail截断输入、避免cat冗余进程、awk替代多级管道、sort必须前置uniq、stdbuf调控缓冲策略。
管道里 grep 太慢？先用 head 或 sed 截断再过滤
很多同学一看到日志或大文件就直接 cat huge.log | grep "ERROR"，结果卡住半天——grep 本身不慢，但得等前序命令把全部数据吐完才开始处理。管道是流式执行，但如果你只关心前 1000 行里的错误，没必要读完几个 GB。
实操建议：
- 用
head -n 1000 huge.log | grep "ERROR"，比全量grep快一个数量级 - 如果目标行有固定位置（比如第 5 行起才有有效日志），用
sed -n '5,100p' huge.log | grep "timeout"，避免无谓解析 -
tail -n 1000同理适用，但注意它要先定位到文件末尾，对超大文件可能略慢于head - 别在管道开头用
cat：写grep "foo" file比cat file | grep "foo"少启一个进程，也少一次内存拷贝
awk 替代多级 cut | sed | grep 组合
常见写法：ps aux | grep nginx | grep -v grep | cut -d' ' -f2 | xargs kill ——看着短，实际启动了 4 个进程，字段分割还依赖空格宽度，极易崩。
实操建议：
- 用
awk一次性完成匹配、字段提取、条件判断：ps aux | awk '$11 ~ /nginx/ {print $2}' | xargs kill，$11是命令列，$2是 PID，稳定不漂移 - 加
-F'指定分隔符更安全，比如处理 CSV：awk -F',' '$3 > 100 {print $1}' data.csv - 避免在
awk里调用 shell 命令（如system("date")），会显著拖慢吞吐，真要时间戳优先用strftime()（gawk）或date +%s预生成
管道中 sort 和 uniq 的顺序与去重陷阱
想统计访问 IP 数量，写成 awk '{print }' access.log | uniq -c | sort -nr，结果发现次数全是 1——因为 uniq 只对相邻重复行计数，没排序就去重等于白干。
实操建议：
- 必须先
sort再uniq：awk '{print $1}' access.log | sort | uniq -c | sort -nr - 如果只是去重不计数，
sort -u比sort | uniq少一次遍历，也省 pipe 缓冲区 - 大数据量时，
sort默认用内存+临时文件，可通过SORT_BUFFER_SIZE环境变量或--buffer-size=1G控制，否则可能因磁盘 IO 成瓶颈 -
uniq -c输出格式是5 192.168.1.1（前面有空格），后续用awk '{print $1, $2}'提取时要注意字段对齐
用 stdbuf 解决管道卡顿或输出乱序
某些命令（比如 python -c "for i in range(5): print(i); time.sleep(1)"）在管道里不实时输出，而是攒满 4KB 才刷出，导致你用 tail -f 或 grep --line-buffered 也看不到实时进展。
实操建议：
- 强制行缓冲：
stdbuf -oL python script.py | grep "done"，-oL表示 stdout 使用行缓冲 - 如果上游是 C 程序且没调用
fflush()，stdbuf -o0（禁用缓冲）有时是唯一解，但注意性能下降 -
grep --line-buffered只影响grep自己的输出行为，不能解决上游不刷 buffer 的问题，别指望它“修复”所有延迟 - 不是所有命令都支持
stdbuf（比如bash内建命令），遇到无效时得改程序逻辑或换工具
管道优化最易被忽略的点：每个进程的默认缓冲策略和输入流是否真正“流式”。你以为在实时处理，其实数据正堵在某个 stdio 缓冲区里睡大觉。
