超级爱喝水第一次看到 cat a.log | grep "error" | tee /tmp/err.log 这行命令时，我盯着那根竖线想了很久：它到底是在给 cat 的输出“喂”东西，还是单纯排版好看？后来在云服务器上排查问题多了，我才意识到重定向、管道、tee 这三个基础得不能再基础的能力，其实是整个命令行世界里最值得花时间吃透的“地基”。这是《凡人修云传》系列的第三篇，前两篇聊完登录方式和基础命令，这篇就把三兄弟一次说清：它们各自解决什么问题、底层到底怎么走数据、日常怎么搭配不出错，以及那些不踩一次就永远记不住的坑。
写这篇的契机，是上个月帮朋友看部署脚本时他问的一个问题：日志文件里永远只有正常输出，错误提示全跑到终端上，怎么回事？这个问题的答案恰恰藏在 0、1、2 这三位数的编码里。如果你也想把“命令之间的数据流”彻底理顺，这篇应该能让你少走不少弯路。
1. 先看一幕每天都在发生的“日志飘走”现场
大多数人第一次碰到重定向相关的问题，都是从“想保存日志，结果文件却是空的”开始的。比如你写了这样一条命令：
bash复制./deploy.sh > deploy.log
你以为 deploy.log 里会记录脚本执行期间的所有信息，结果打开一看，里面只有正常的 echo 输出，真正的报错、警告、堆栈全部显示在终端上，一个都没进去。然后你搜到的答案是：加上 2>&1，像这样：
bash复制./deploy.sh > deploy.log 2>&1
确实解决了，但你其实并不清楚为什么。这个疑惑会一直留到下一次你看到 2>&1 和 >file 交换顺序却出现完全不同的结果时才爆发。不把这个层面的逻辑搞懂，你写命令就永远是“照着博客抄”，而不是“自己在设计数据流”。
1.1 这三个符号其实是在描述“数据从哪来、到哪去”
Shell 虽然看起来是一行行输入命令，但本质上它是个小型的“数据搬运系统”。每一条命令都不是孤立存在的，它从某个地方读入内容，再往某个地方吐出内容。我们看到的屏幕只是默认目的地而已。
重定向解决的是“输出到哪里”的问题，管道解决的是“输出直接交给谁”的问题，tee 解决的则是“输出能不能同时走两条路”的问题。三者的关系有点像快递分拣：重定向是决定包裹直接送回家，管道是让包裹顺着传送带进入下一道工序，tee 则是在传送带中间装了个分流器，让同样的包裹既继续往前走，又被复制进暂存区。
1.2 这篇读完后你能带走什么
读完这篇，你会知道文件描述符 0、1、2 到底指向什么，能读懂 >、>>、2>&1、&> 这些符号背后的解析逻辑；能理解 cmd1 | cmd2 时系统内部发生了什么，为什么管道右边经常访问不到左边的变量；还能掌握 tee 的高频实战场景，比如 sudo tee 写系统文件、部署脚本边执行边落盘。另外还会带一个完整的 HTTP 重定向排查案例，以及三个长期踩坑后总结出来的调试习惯。
这一篇不适合那种只想要“复制这行就行”的人，它更适合愿意花半小时把基础打牢、以后遇到诡异问题能自己推理的读者。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 文件描述符：一切重定向的源头是 0、1、2 这三根管道
要说清重定向，绕不开文件描述符这个概念。很多人听到“文件描述符”就头皮发麻，以为是内核教科书里的冷门术语，其实它特别接地气：你可以把每个进程想象成一个正在办公的人，文件描述符就是这个人桌子上固定的三根线，编号 0、1、2。任何程序启动时，这三根线都已经默认接好了。
2.1 0、1、2 每个数字背后是什么
这三个编号在系统里有固定名字，英文分别是 stdin、stdout、stderr，中文就是标准输入、标准输出、标准错误。用人的体感来类比：
- 0 是耳朵，负责听外界说了什么，默认来源是键盘。
- 1 是嘴巴，负责把正常结果说出去，默认去向是屏幕。
- 2 是抱怨通道，负责把错误和警告喊出来，默认去向也是屏幕。
关键点在于，0、1、2 只是“默认”接好了，它们并不是焊死的。你可以随时把 1 这根线从屏幕上拔下来，插到一个文件上，这就是输出重定向。也可以把 2 这根线接到和 1 一样的地方，这就是 2>&1。还可以给进程临时增加 3、4、5 号管线，然后再手动关闭它们。
理解这层逻辑后，很多“语法”就不再是死记硬背了。比如 2>&1 这个写法，读法是从右往左：“把文件描述符 2 重定向到文件描述符 1 当前指向的位置”。很多人把它误读成“把 2 和 1 合并在一起”，这就容易在命令顺序上翻车，后面第 6 章会专门讲。
2.2 常见重定向姿势与结果对照
| 写法 | 实际作用 | 理解方式 |
|---|---|---|
> file |
标准输出写入 file，文件先被清空 | 把嘴巴对准 file，并且把 file 里的旧内容倒掉 |
>> file |
标准输出追加到 file 尾部 | 把嘴巴对准 file，保留原来的内容继续往下写 |
2> file |
标准错误写入 file | 只把抱怨通道接到 file |
2>&1 |
标准错误复制到标准输出当前目标 | 抱怨通道和嘴巴指向同一个地方 |
&> file |
标准输出和标准错误都写入 file | 嘴巴和抱怨通道都对准 file（bash 专属写法） |
从这些写法里你能看出一个通用规律：单独用 > 或 <，只影响一条通道；凡是涉及到把一个通道“复制”到另一个通道的，语法里一定会有 &。这个 & 不是后台运行符，而是“文件描述符”的标志。写 2>&1 时，1 前面必须带 &；如果写成 2>1，系统会认为你想把标准错误写进一个名叫“1”的文件里，后果完全不一样。
2.3 关于 printf 重定向，一次说清两个层面的东西
搜索热词里有“printf 重定向”，这个词其实覆盖了两个层面。第一个层面是 Shell 内建的 printf 命令，它与 echo 最大的区别是格式完全可控，而且不会默认加换行。你完全可以这样把格式化的内容送进文件：
bash复制printf "user=%s\nlogin_count=%d\n" "zhang" 17 > /tmp/stats.txt
printf 之所以比 echo 更适合测试重定向，是因为它支持 %s、%d、\n 等明确的格式符，一旦文件内容和预期不符，你能立刻判断是格式符写错了还是重定向方向错了，不像 echo 那样还要猜换行和转义。
第二个层面是 C 语言 / Go 这类编程语言里的 printf。很多人写个小工具调试时，会习惯性地用 printf 打印信息，然后在终端执行 ./prog > out.txt，结果发现 out.txt 里的输出顺序和终端上看到的顺序不一样，甚至内容少了。这通常不是重定向的问题，而是标准输出缓冲模式变了：当 stdout 连到终端时是行缓冲，遇到换行就刷新；当 stdout 被重定向到文件时可能变成块缓冲，要等缓冲区满或者进程正常退出才会刷新。如果进程中途崩溃，还没来得及 flush 的 printf 内容就会丢掉。处理方式是在程序里显式调用 fflush(stdout)，或者直接把 stdout 设置成无缓冲模式：
c复制setvbuf(stdout, NULL, _IONBF, 0);
这个知识点做日志采集时特别有用，否则你在调试端侧程序时，很容易误判成“重定向把我数据吞了”。
3. 管道：命令和命令之间的一条传送带
重定向解决的是“一条命令的输出要放到哪里”的问题，但它有一个明显的局限：如果命令 A 的输出要成为命令 B 的输入，用重定向就得先写进一个中间文件，然后再让 B 去读。比如：
bash复制ls -l > /tmp/file_list.txt
grep "\.conf" /tmp/file_list.txt > /tmp/conf_list.txt
wc -l < /tmp/conf_list.txt
这段命令能跑通，但很别扭。每一条命令之间都要经过磁盘，既慢又费空间。更重要的是，你不得不为了一次临时筛选专门造两个中间文件，用完还得清理。管道的出现，就是为了消灭这种“中间人”。
3.1 管道在系统内部到底做了什么
当你在 Shell 里写下 ls -l | grep "\.conf" 时，Shell 做了这样几件事：先创建一根管道，这头连着 ls 的标准输出，那头连着 grep 的标准输入。然后它会同时启动两个进程，让左边写、右边读，两边并行运行。
管道并不是一个磁盘上的文件，它是一块由内核管理的缓冲区。缓冲区的大小有限，写多了会阻塞，读空了也会阻塞，所以两边进程天然会形成“你等我、我等你”的节奏。这很像传送带两端有两个工人：左边的工人把零件放上传送带，如果传送带满了，他必须停下来等；右边的工人取走零件，如果传送带空了，他就等着下一个零件送过来。整条流水线里，两个工人都不能不管对方自顾自地干。
从这里你还能理解一个现象：管道两边的命令并不是“先执行完左边再执行右边”，而是同时存在的。ls -l | grep "\.conf" 在 ls 还没跑完时，grep 已经在处理第一批数据了。这也是为什么管道能显著减少整体耗时，它让数据处理变成流式的，而不是批处理式的一棒接一棒。
3.2 管道的两条必须记住的“铁律”
第一条铁律：管道默认只搬运标准输出，也就是 1 号通道的内容，标准错误不经过管道。如果你执行 cmd_that_fails | grep "error"，左边程序往 2 号通道输出的所有错误信息都会直接打到终端，而不会进入 grep。这时候你需要在左边命令后面加上 2>&1，把标准错误合并到标准输出里，才能让 grep 也看到错误内容：
bash复制cmd_that_fails 2>&1 | grep "error"
第二条铁律：管道两侧的命令通常在子 Shell 中执行。这意味着管道右边的命令对变量的修改，不会影响当前 Shell。很多人写 echo hello | read x; echo $x 时发现 x 是空的，就是这个原因。后面第 6 章会详细展开。
3.3 顺着热词走一次：Go 语言如何遍历管道输入
“go 遍历管道”是个挺有意思的搜索关键词，它背后是一类场景：你想写一个小工具，让它可以接收标准输入的数据逐行处理，然后再用管道把它嵌进现有命令行体系里。这也是管道能力最值得借鉴的地方——它不只是 Shell 里的符号，还是程序设计时的通用思路。
下面是一个很简单的 Go 程序，它会从标准输入逐行读取，统计单词出现次数，最后把结果打印到标准输出：
go复制package main
import (
"bufio"
"fmt"
"os"
"strings"
)
func main() {
freq := make(map[string]int)
scanner := bufio.NewScanner(os.Stdin)
for scanner.Scan() {
words := strings.Fields(scanner.Text())
for _, w := range words {
freq[w]++
}
}
for w, n := range freq {
fmt.Printf("%d\t%s\n", n, w)
}
}
把它编译成 wordcount 后，你就能用管道喂数据给它：
bash复制cat notes.txt | ./wordcount | sort -rn | head -n 10
这一串命令里，wordcount 扮演的是中间处理节点：左边有人给它喂文本，它逐行读、逐行处理，然后把统计结果继续往右传。这就是“遍历管道”的真相：程序本身并不知道上游是谁、下游是谁，它只需要老老实实地读 os.Stdin，再写 os.Stdout。这种解耦能力，是命令行工具能被自由组合的根基。
4. tee：三兄弟里最容易被低估的工具
如果说重定向是“单线直送”，管道是“传送带接力”，那 tee 就是那个看起来不起眼、实则能救大命的分流器。
tee 这个名字本身就来自英文 T 形三通管，意思是一根主管道进来，分岔成两路出去。执行 cmd | tee file.txt 后，cmd 的输出会同时流向两个地方：一份继续往标准输出走，让你能在屏幕上看到；另一份被写入 file.txt。注意，tee 默认是覆盖写入，如果文件已存在且你没加 -a 参数，旧内容会被清掉。想保留旧内容要写成 tee -a file.txt。
4.1 为什么要发明这样一个看起来“浪费”的命令
没有 tee 的时候，你很难同时做到“看实时输出”和“留完整日志”。你可能想到用 cmd > log.txt，但屏幕就会变得一片寂静，你只能干等着不知道进度；又或者你只让输出打到屏幕，但事后复盘时又找不到记录。tee 解决了这个两难：你既能实时看到结果，又能留下完整副本。
在调试阶段，tee 还有一个隐藏价值。有时候你会不确定某条命令的输出到底长什么样，又想一边看一边给后续处理，这时 tee 相当于给流水线加了“观察窗口”。比如：
bash复制ls -l | tee /tmp/all_output.txt | grep "\.conf"
all_output.txt 里保留的是 grep 之前的完整结果，你可以事后慢慢翻，确认 grep 有没有过滤掉你想保留的行。
4.2 四个高频组合，后面写脚本基本离不开
第一个场景：给受保护文件写配置。很多人第一次执行类似命令会写成这样：
bash复制sudo echo "hello" > /etc/motd
然后收到 permission denied。原因在于，sudo echo 只是让 echo 以 root 身份运行，但 > 这个重定向是当前 Shell 负责的，它试图以普通用户身份去打开 /etc/motd，自然没权限。正确的写法是用 tee 来承接：
bash复制echo "hello" | sudo tee /etc/motd
这里 echo 以普通身份输出到管道，tee 以 root 身份接收管道内容并写入文件，权限问题就绕过去了。想要追加内容就改成 sudo tee -a /etc/motd。
第二个场景：部署脚本边执行边存档。比如你要跑一个上线脚本，希望既能在终端看到实时进度，又把完整输出留成带时间戳的日志：
bash复制./deploy.sh 2>&1 | tee -a /tmp/deploy-$(date +%F-%H%M).log
加 2>&1 是为了把脚本的错误输出也汇入管道，避免错误只出现在屏幕而日志里缺失。加 -a 是为了避免不小心覆盖当天的历史日志。
第三个场景：输出既要给人看，也要继续给机器处理。例如从服务日志里提取 IP，既要存一份完整结果，又要继续统计 TOP N：
bash复制grep "401" access.log | tee /tmp/hackers.txt | awk '{print $1}' | sort | uniq -c | sort -rn | head
第四种场景：快速做多份归档。tee 可以接收多个文件参数，一份输入同时写好几份副本：
bash复制./backup.sh | tee /tmp/output1.txt /tmp/output2.txt
实际写脚本时，这个特性很适合“同时生成人类可读报告和后续处理需要的数据文件”。
5. 实战排查：当网页提示“重定向次数过多”时，用这三兄弟破局
前面聊的都是文件层面的重定向，但搜热词里还有一批人搜的是“将您重定向的次数过多”。这是完全不同的领域：它不是 Shell 的文件描述符问题，而是 HTTP 协议里的“重定向循环”。
浏览器在处理跳转时会遵循服务器返回的 Location 头，从 A 跳到 B，B 又让你跳回 A，如此反复。浏览器为了避免无限循环，会设定一个最大跳转次数，超过后就报“将您重定向的次数过多”。这种场景下，Shell 三兄弟能帮你快速找到元凶。
5.1 浏览器提示为什么这么含糊，HTTP 重定向到底长什么样
HTTP 里的重定向，是服务器返回一个 3xx 状态码，并在响应头里带上 Location 字段说明“你应该去这里”。比如：
bash复制HTTP/1.1 302 Found
Location: https://b.test/login
如果 b.test 又返回：
bash复制HTTP/1.1 302 Found
Location: https://a.test/login
那就形成了 A 与 B 之间的死循环。浏览器出于安全，只告诉你“重定向次数过多”，却不会把完整跳转链打印出来给你看。这时候，需要我们自己动手追踪。
5.2 用 curl 加管道加 tee 把 Location 链翻出来
假设你的服务地址是 http://a.test/entry，现在先在 Shell 里执行带重定向跟随的请求，但只抓响应头，并把中间过程存一份、过滤一份：
bash复制curl -sIL http://a.test/entry | tee /tmp/redirect_chain.txt | grep -i '^location'
拆解一下这条命令。curl -I 表示只请求响应头，-L 表示自动跟随重定向，-s 表示安静模式不显示进度条。tee 把完整头部过程存到 /tmp/redirect_chain.txt，同时把同一份输出传给 grep，grep 只挑出 Location 行。你最后会在屏幕上看到类似这样的跳转路径：
bash复制Location: http://b.test/login
Location: http://a.test/entry
Location: http://b.test/login
Location: http://a.test/entry
看到两个地址互相咬合，你立刻就能明白是哪里配置出了问题：通常是负载均衡层、网关或应用层各自加了一层重定向逻辑，导致 A 和 B 形成了闭环。
如果 Location 链很长，你想看跳了几次，还能配合统计：
bash复制curl -sIL http://a.test/entry 2>&1 | grep -ci '^HTTP/'
grep -c 会输出匹配行数，这个数字就是实际发生的跳转次数。如果超过了预期，比如明明只配置了一次跳转，却数出来 20 行，那就说明循环已经发生了，不需要等浏览器转 50 次也能提前定位。用 curl 还可以拿到更精确的错误码：
bash复制curl -s -o /dev/null -w "%{http_code}\n" http://a.test/entry
-w 指定输出格式，%{http_code} 是最终响应的状态码。看到 3xx 就知道还没跳出循环，继续加 -L 观察。
这一套流程下来，你会发现重定向、管道、tee 在处理真实网络问题时同样是好用的组合拳，它们从来不只是“文件操作的小技巧”。
6. 最容易翻车的三个细节：顺序、子 Shell 与 SIGPIPE
基础用法掌握后，接下来才是真正的分水岭。Shell 这类工具，表面语法简单，但坑往往藏在“看起来一样的写法，顺序差一点结果完全相反”的地方。我自己踩过不下五次，它们值得单独拿出来说。
6.1 2>&1 和 >file 的顺序为什么不能乱
这是最经典的一个坑。先看两行命令：
bash复制./deploy.sh > /tmp/deploy.log 2>&1
./deploy.sh 2>&1 > /tmp/deploy.log
第一行：先让标准输出指向 deploy.log，再把标准错误复制到“标准输出当前指向的位置”，所以错误也进了 deploy.log。这是正确写法。
第二行：先把标准错误复制到“标准输出当前指向的位置”，此刻标准输出还指向终端，所以到这一步，错误仍然指向终端；随后标准输出才被重定向到 deploy.log。最终结果是标准输出进了文件，标准错误依然打在屏幕上。
解析规则是 Shell 从左往右处理重定向，每一步的 &1、&2 都代表“此时此刻那个文件描述符指向的位置”，而不是最终位置。这也是为什么网上所有日志采集方案都会告诉你要把 2>&1 写在 > 的后面。如果记不住，就死死记住一条：写日志时统一用 > file 2>&1，顺序别换。
6.2 管道右侧的子 Shell 问题：变量为什么丢了
继续看一个非常反直觉的示例：
bash复制echo "hello world" | read first rest
echo $first
在很多 Shell 版本里，第二行输出是空的。原因是 read 在管道右侧执行时，它所在的那个进程是子 Shell，读进去的变量只存在于子 Shell 环境里，当管道结束、子 Shell 退出，变量也随之销毁。主 Shell 里根本看不到 first 这个变量。
这个坑最常见的变体现在循环里：
bash复制count=0
cat numbers.txt | while read line; do
count=$((count + 1))
done
echo $count
你以为 echo 会输出文件行数，实际大概率是 0。解决办法有几个：把循环放到当前 Shell 而不经过管道，比如使用进程替换：
bash复制while read line; do
count=$((count + 1))
done < <(cat numbers.txt)
这里的 < <(...) 把进程替换的结果作为输入重定向给 while，循环本身运行在主 Shell 里，变量修改就会保留。或者最简单粗暴，改用临时文件：
bash复制cat numbers.txt | { while read line; do count=$((count+1)); done; echo $count; }
把要使用变量的所有逻辑都放进子 Shell 的花括号里，也能解决问题，但要小心别让变量跨过整个子 Shell 作用域。
6.3 SIGPIPE：为什么管道有时候“戛然而止”
第三个坑和管道生命周期有关。当管道左侧进程还在拼命输出，但右侧进程已经读完自己想读的部分并退出时，左侧进程会收到一个叫 SIGPIPE 的信号。这个信号的默认行为是直接终止进程。
最经典的例子就是：
bash复制yes | head -n 3
yes 原本会无限循环地输出 y，但因为管道右边是 head -n 3，它读完三行就关掉管道的读端退出了。内核发现管道写端已经没有读端对应，于是给 yes 发送 SIGPIPE，yes 立即终止。你打死也不会看到 yes 无限运行下去，这正是管道设计的自我保护：没有下游消费的数据，上游就不该继续生产。
这个现象在脚本里会引起连锁反应。比如你写一个连续执行的流水线：
bash复制set -o pipefail
grep "keyword" big_file.txt | head -n 10 && echo "done"
默认情况下，管道的退出状态只看最后一个命令。grep 可能因为 SIGPIPE 退出，但 head 成功返回 0，所以整条管道看起来成功了。加了 set -o pipefail 之后，管道的退出状态会变成“所有命令中最后一个非零退出码”，这样 grep 被 SIGPIPE 杀掉时，脚本能感知到异常。写严肃脚本时，建议在文件头部就加上 set -o pipefail。
7. 我长期在用的组合招式和检查方法
最后不写总结，就分享一些我自己每天在用的真实组合和调试习惯，这些都是从大量翻车现场里沉淀下来的。
7.1 三条我高频使用的复合命令
第一条，临时备份加校验。压缩目录后想同时知道文件有没有损坏：
bash复制tar -czf - /etc/nginx 2>/dev/null | tee /tmp/nginx-$(date +%F).tar.gz | sha256sum > /tmp/nginx.sha256
tar 的输出通过管道流进 tee，tee 一边把完整压缩包写入备份文件，一边把同样的数据继续喂给 sha256sum 计算校验值。一次操作同时得到备份和校验和，不用先写临时文件再二次计算。需要恢复时，用校验值先验证再解压。
第二条，长任务日志边看边存。无论跑测试还是部署，我习惯用：
bash复制./run-tests.sh 2>&1 | tee /tmp/test-$(date +%F-%H%M).log | tail -f
这个组合的妙处是：tee 把日志写入了文件，但同时继续往标准输出传；再通过 tail -f 让终端跟着最新内容走。如果觉得 tail -f 太打扰，也可以直接不接最后的尾段，让输出自然打到终端。
第三条，快速清理旧文件时先看后删。用管道把“一个月前的日志”列表存下来再浏览，避免误删：
bash复制find /var/log -name "*.log" -mtime +30 | tee /tmp/old_logs.txt | less
确认列表无误后再用 xargs rm -f 读取那份文件执行，核心原则是：凡是带删除、覆盖、清空等破坏性动作的命令前，都值得加一道 tee。
7.2 用 /proc 检查自己的重定向有没有按预期生效
有时候命令写复杂了，你不确定某个文件描述符到底指向哪里。与其猜，不如直接问内核。Linux 的 /proc 文件系统里，每个进程都有一个 fd 目录，里面列出了这个进程打开的所有文件描述符。当前 Shell 的 PID 可以用 $$ 表示，所以可以这样验证：
bash复制$ exec 3> /tmp/example.txt
$ ls -l /proc/$$/fd/3
lrwx------ 1 user user 64 ... 3 -> /tmp/example.txt
看到 3 号描述符指向 /tmp/example.txt，你就知道当前 Shell 确实开了一个从 3 号流向该文件的通道。用完可以关闭它：
bash复制exec 3>&-
再执行 ls -l /proc/$$/fd/3 就会提示没有这个文件描述符。这种做法比反复看输出结果推导要高效得多，尤其是在调试脚本里的 exec 重定向、处理临时日志句柄时，几乎是确诊工具。
7.3 如果你刚开始学这套技能，我建议你做一件事
不要背命令组合，也不要直接复制网上那一大串“万能模板”。找一台测试用的 Linux 机器，随便造几个文件，然后拿重定向、管道、tee 去组合出不同玩法：把错误和输出分开放到两个文件，观察顺序；用管道把自己的程序接起来；在脚本里故意制造一个变量丢失的场景再解决它。每次组合完，就用 /proc/$$/fd 验证一下当前的通道指向。这个过程重复几次以后，你会发现自己不再害怕那种看起来神秘的长命令，因为你看到的每一段，都会自动在脑海里拆成“某根线接到哪里，某段数据流从哪里走到哪里”的清晰画面。到那时候，所谓“Shell 高手”的光环，其实也就这么回事。