先说一个我印象特别深的场景。某次帮某团队排查定时任务，脚本里写了run_task > task.log，结果日志文件空空如也，任务本身却明明跑完了。排查到最后才发现，真正的报错信息全被输出到了标准错误，而重定向只抓走了标准输出。这种问题在做开发、做运维、甚至日常用命令行的朋友身上太常见了：没搞懂重定向、管道以及标准输入标准输出之间的关系，日志丢了、数据处理错了、脚本行为诡异，你甚至不知道从哪儿下手。这篇文章就把这三个概念彻底拆开，结合实操场景讲清楚它们到底是什么、怎么配合、以及最容易踩的坑。
1. 三个标准流：0、1、2 到底是什么
1.1 stdin、stdout、stderr 的定位
很多同学把"标准输入、标准输出"当成两个术语，实际上它们是三个：标准输入（stdin）、标准输出（stdout）和标准错误（stderr）。每个进程在启动时，操作系统都会给它预设三根"数据通道"：
- 标准输入（文件描述符 0）：程序默认从这里读取数据。终端下默认读取你的键盘输入；文件、另一个程序、一段字符串都可以给它喂数据。
- 标准输出（文件描述符 1）：程序把正常结果写到这里。默认显示在屏幕上。
- 标准错误（文件描述符 2）：程序把错误信息写到这里。默认也是显示在屏幕上。
关键在于，这是一套进程级的默认机制，不是某个 shell 特有的行为。你在终端执行ls、grep、python、java，底层全都遵守这套约定。比如一个用 .NET 写的后台服务，它用 Console.WriteLine 输出的信息走标准输出，用 Console.Error.WriteLine 输出的内容走标准错误，操作系统不关心你写的代码是什么语言，它只认这三个通道。
用"水管"类比最好理解：标准输入是进水口，标准输出是正常出水管，标准错误是另一根报警出水管。三根管子一开始都接到终端上，键盘往里进水，两根本来出水的管子的水流都显示成屏幕上的字符。重定向和管道做的事情，本质上是把这几个"管子接口"重新接。
1.2 为什么要把正确结果和错误信息分开
分开设计不是闲得无聊，是为了数据可信。如果正常输出和错误信息混在一根管子里，你想把程序结果保存下来，错误也会掺进去；反过来你只想看报错，正常结果又会刷屏。
举一个非常实际的例子：你运行find / -name "*.conf" > result.txt，如果不把标准错误和标准输出分开，权限不足的提示会污染结果文件，后面再用grep处理 result.txt 就会得到一堆根本没权限读到的路径。操作系统把两根出水管分开，就是让你可以独立处理"正常的结果"和"异常的情况"。
从编程视角其实更好理解：任何工具函数建议用返回值和异常机制分离正常路径与错误路径。命令行里的 stdout 和 stderr 就是这种分离思想在进程层面的实现。理解了这一点，你对2>/dev/null这种写法的理解会立刻上一个台阶——它不是玄学，就是"把报警水管接进碎纸机"。
1.3 文件描述符数字的直觉记忆法
Linux 里用数字 0、1、2 代表这三个标准流，很多教程直接让你"记住"，但你可以通过编号顺序建立直觉：
- 0 在最前面，表示输入源头，天然符合"数字扫描顺序从 0 开始"的习惯。
- 1 代表主要的正常出口，也就是最常看到的输出。
- 2 代表次要的额外出口，也就是第二根出水管。
在 shell 中你经常会看到<、>、>>这些符号，它们默认操作的是标准输入和标准输出，而标准错误必须显式加2才能重定向。这个"默认操作 0 和 1，必须点名才操作 2"的规则，恰恰是无数新手处理日志时最迷惑的地方。我的建议是：每次写重定向，心里都默念一遍"我现在接的是哪根管子"，这个习惯能让你避开九成的基础错误。
提示：
<默认对应 fd 0，>默认对应 fd 1，连2>这种写法其实只是从 fd 2 导出数据。理解 fd 概念之后，重定向规则会变得非常清晰。
2. 重定向实操：把数据流精准引到指定位置
2.1 输出重定向的正确姿势
输出重定向是最常用的操作，基本写法就两类：
# 覆盖写入，文件原有内容会被清空 command > file.log # 追加写入，保留原有内容，新内容接在后面 command >> file.log这两个写法的杀伤力差别很大。>会先创建（或清空）目标文件，再写入内容。某次我在测试环境执行du -sh * > 2024_size.txt，结果那个文件名正好是一个子目录的名字，于是一整个目录的统计内容直接被清空重写，原本的旧报告没了。后来我的习惯是：覆盖式重定向之前先确认文件名是不是真的不存在或者确认可以覆盖，尤其是带日期的文件名，很容易因为少打一个字符把一个月的数据全冲了。
还有一个高频细节：重定向的位置。shell 允许你写成> log 2>&1，也允许写成2>&1 > log，但两者含义完全不同。前者把标准错误重定向到标准输出当前指向的地方，再把标准输出引到文件，最终两者都进文件；后者先把标准错误指向当前标准输出（多半是终端），再把标准输出引到文件，最终标准错误还在终端上。所以那句著名的"2>&1 要放在最后"，只是为了方便阅读和避免理解歧义，并不是语法强制，真正的规则是：shell 从左到右处理重定向。
我建议把command > file 2>&1当成标准模板记住，不要轻易调换顺序。
2.2 输入重定向的场景
输入重定向平时用得比输出少，但一旦用到就是关键救场：
# 从文件读取标准输入 program < input.txt # 在这里手动输入多行，直到出现 EOF 标记 program << EOF line1 line2 EOF # Bash 的 here-string，直接喂一段字符串 program <<< "这是一段输入"<最常见的用途是把文件内容喂给只读 stdin 的程序。比如你写了一个交互式 Python 脚本input()接收数据，调试时不想每次都手动敲，就可以准备一个 csv 文件然后python script.py < data.csv。再比如sort < unsorted.txt这种写法，虽然很多人习惯用sort unsorted.txt，但在某些场景下输入重定向能避免命令语法歧义，更稳妥。
<<here-document 在脚本自动化里特别香：可以在 shell 脚本里一次性写入多行内容并喂给某个程序，甚至可以配合 sudo 执行需要输入密码的交互程序，虽然密码这种敏感信息不建议明文写，但批量执行自动化任务时，here-document 比逐个手动输入可靠得多。
<<<是 Bash 扩展，适合给程序喂短字符串。比如md5sum <<< "hello"会输出 hello 加换行的哈希，注意它会默认追加换行，所以跟echo "hello" | md5sum结果一致。这个细节有时候会让结果和你预期不一致，需要留意。
2.3 标准错误重定向与经典组合
标准错误单独重定向也有两种：
# 只把标准错误覆盖写入文件 command 2> error.log # 只把标准错误追加写入文件 command 2>> error.log更常用的是组合运用。比如我想把标准输出和标准错误分别存到两个文件，方便分开排查：
command > normal.log 2> error.log我最常用的组合是> app.log 2>&1，将标准输出与标准错误全部合并进同一个文件。后台跑服务、跑数据任务、跑定时脚本，统一日志文件是首选。同时我也常用> /dev/null 2>&1丢弃所有输出——比如执行一个只关心退出码的命令，在 crontab 里不想收到任何内容时，这会非常干净。
注意 Bash 还提供了一种简短写法&>：
# 等价于 > file 2>&1 command &> file这种写法简洁，但移植性不如> file 2>&1好，因为 POSIX sh 不支持&>。如果你写的脚本需要跑到多种 shell 环境里，建议统一使用> file 2>&1这种兼容性最强的写法。
2.4 /dev/null 与文件描述符的高级腾挪
/dev/null在重定界里扮演"黑洞"角色。我常跟人讲，把不想要的内容送进/dev/null，比在脚本里费力去过滤强得多：
grep -r "pattern" /some/dir 2>/dev/null crontab 命令 >/dev/null 2>&1你也可以自定义文件描述符做更精细的控制：
exec 3> custom.log command 1>&3 2>&1 exec 3>&-这种操作在复杂脚本里可以把指定文件描述符重定向到日志文件，灵活度很高，但日常用不了太多。我的建议是：先在脑子里搞清 0、1、2 三根基本水管，高级 fd 腾挪只是基于同一套规则的扩展。如果一上来就玩3>&1之类的操作，很容易在嵌套重定向里迷失。
3. 管道用法拆解：把命令串成流水线
3.1 管道符的底层语义
管道符|可以理解为：把左边命令的标准输出，接到右边命令的标准输入。这在操作系统层面是一项非常朴素的设计：前一个进程的输出数据流向不落盘，直接进入下一个进程的输入接口。
你可能会问：这和command > temp.txt再执行next < temp.txt有什么本质区别？答案是效率与并发。管道不会在磁盘上产生中间文件，更重要的是，只要数据一产生，右边的进程就可以立刻开始消费，整个链路是并发的，左右两个命令可以同时运行。比如top -b | head不需要等 top 全部跑完才让 head 动起来，top 一边输出，head 一边取前几行。
管道也有自己的生活状态：如果右边的进程处理得慢，左边进程会等待；如果左边进程产生大量数据，而右边进程已经退出，左边进程将收到 SIGPIPE 信号终止掉。这个行为有时候会让你在执行长管道时看到Broken pipe错误，事实上这是正常现象，不是故障。
3.2 最常用的管道组合套路
我列出几组我在日常工作中高频使用的管道组合，直接照着抄基本就能解决大部分数据处理需求：
# 实时过滤日志 tail -f app.log | grep "ERROR" # 统计日志里每个 IP 出现次数并排序 awk '{print $1}' access.log | sort | uniq -c | sort -rn # 找出文件中最占磁盘空间的目录 du -sh /var/log/* | sort -hr | head -10 # 在项目代码里快速搜索关键词，并显示行号 grep -rn "TODO" src/ | lesstail -f加grep的组合特别适合排查线上问题，一边观察日志滚动，一边只保留异常内容。awk加sort加uniq加sort的链条是统计类需求的经典流水线：提取字段、排序、统计次数、按频率逆序排列。真正用熟之后，你会发现这些基础命令唾手可得，完全不用借助大而全的数据处理平台。
还有一组组合我认为是管道进阶的核心，那就是xargs：
find . -name "*.log" | xargs grep "OutOfMemory"find列表通过管道传给xargs作为参数转发给grep，省去手动拼参数。这里有个坑：如果文件名包含空格，xargs默认按空白切分会导致参数错位，需要加上-0配合find -print0或改用xargs -d '\n'。这是我踩过不止一次的坑，处理带空格路径的文件时务必留意。
3.3 管道与重定向的嵌套技巧
管道本身处理的是标准输出，但程序的标准错误并不会自动进入管道。想让标准错误也进入右侧程序，需要这样写：
command 2>&1 | grep "error"这种写法很常用。比如你执行某个脚本，既想捕获 stdout 也想捕获 stderr，然后一起过滤。在 Bash 里还有一个简写|&，等价于2>&1 |，不过同上，为了可移植性我在脚本里倾向于写完整的2>&1。
管道也可以和文件重定向混合：
command 2> error.log | tee output.log这里是：标准错误进 error.log，标准输出一边通过 tee 保存到 output.log 一边继续显示在终端。这种场景非常适合手工排查：既保留运行痕迹，又能实时看到进度。如果不想屏幕显示，只想让数据同时流向两个文件，可以用tee的经典设计，甚至两个 tee 串起来实现"一鱼三吃"。
再一个很多人容易忽略的点：管道里命令的退出状态默认只看最后一个命令。cmd1 | cmd2如果 cmd1 失败而 cmd2 成功，整个管道的退出码是 0。在 shell 脚本里，这会掩盖掉真正的问题。处理方式可以在脚本开头设置set -o pipefail，让管道中任何一环失败都反映在最终退出码上。我个人强烈建议在所有值得维护的脚本里加上它。
4. 踩坑记录：重定向与管道的高频问题
4.1 为什么日志文件里什么都没写
有一次线上定时任务的日志文件是空的，命令在 crontab 里写的是run_task > task.log。实际原因和开头说的类似：输出内容全在 stderr，用>只捕获了 stdout。解决办法是统一使用> task.log 2>&1，让两个输出流都进同一个文件。
另一个常见原因是缓冲机制。程序写 log 时默认会做缓冲区，比如 Python 的 print 重定向到文件后，默认可能进入块缓冲，进程退出前数据没有及时 flush。你看到文件是空的，但等程序结束后数据可能才刷进去。如果需要实时日志，让 Python 脚本用python -u script.py取消缓冲，或者在代码里加flush=True，很多后端服务的日志延迟八成就是这个原因。
4.2 2>&1 的位置陷阱
同样一条命令，只是换一下位置，结果天差地别：
# 正常：stdout 和 stderr 都进 file command > file 2>&1 # 坑：只有 stdout 进 file，stderr 还是会打到终端 command 2>&1 > file原因前面已经提过，shell 从左到右处理。第二种写法先让 stderr 指向当前 stdout（通常是终端），然后再把 stdout 指向 file，结果 stderr 并不会跟着转到 file。我见过不少同事在这里栽跟头，他们把2>&1 > file想当然地理解为"把 2 和 1 都弄进文件"，实际上完全不是。
如果非用2>&1 > file来实现让 stderr 进文件，需要在第二次重定向时也指定 stderr 指向新目标：
command 2>&1 > file 1>&2这种花活我一般不推荐，容易把人绕晕。稳妥的方案就是统一用> file 2>&1。
4.3 管道与重定向的优先级问题
管道与重定向之间的优先级也有讲究。举例说明：
# 管道先建立，把 stdout 连接到 grep 的 stdin，再设置 > result.txt command 2>&1 > result.txt | grep "err"在这个例子里，由于管道先建立，command 的 stdout 已经被交付给 grep，后面> result.txt不会再捕获 stdout，结果只有原来的 stderr 和重定向逻辑相关，极其容易出错。实际调试时遇到"我明明重定向了，为什么没生效"的情况，多半就是管道优先级引起的混乱。
更复杂的情况还会出现在分组命令里：
{ command1; command2; } > log 2>&1用大括号把多条命令包成组，一次重定向全部生效。这个技巧在需要把一组命令统一输出到同一份日志时非常实用，比在每条命令后都追加重定向干净得多。
4.4 缓冲、退出码与并发隐患
标准输出在终端和文件之间的缓冲策略不同。终端通常是行缓冲，打印一行就刷新一行；管道和文件通常是块缓冲（4KB 或更大）。所以同样的程序，直接终端里运行有输出，重定向到文件却迟迟不显示，不是程序出 bug 了，只是数据还在缓冲区里。排查手段是使用stdbuf -oL强制行缓冲，例如：
stdbuf -oL python -u realtime_log.py | tee -a run.log另一个隐患是管道退出码掩盖问题，我在 3.3 节已经提到。脚本里如果既有重定向又有管道，还需要特别留意管道的 sigpipe 现象。比如yes | head -1这条命令，head读完一行就退出，yes随后收到 SIGPIPE 被系统终止，但你不会在终端里看到报错，这很正常。真正要警惕的是在循环中使用管道读取程序输出时，一旦子进程被 SIGPIPE 杀掉，可能导致资源未释放，大数据量处理时需要格外小心。
4.5 个人避坑清单
最后我给出一份我从实际运维中积累的检查清单，基本覆盖上面所有内容：
- 写日志一律使用
> app.log 2>&1，不要只写>，否则 stderr 丢失。 - 覆盖式重定向之前先确认文件名，不要为了省事而清空错误文件。
- 在脚本开头慎重使用
set -e时，记得考虑管道退出码问题：要么加set -o pipefail，要么避免裸管道。 - 处理文件名带空格时优先
find ... -print0 | xargs -0 ...，而不是裸 xargs。 - 要实时日志时，确认待重定向程序的缓冲模式，必要时用
stdbuf、python -u或代码内 flush。 - 组合命令需要统一输出时，用
{}分组加一次重定向，而不是每条命令单独做。 2>&1与>的顺序要形成肌肉记忆：先改 stdout，再让 stderr 跟着走。- 如果你在脚本中看到
|&或&>这种简写，能兼容 Bash 就用，要跨平台就改成2>&1 |和> file 2>&1。
这几年下来我对这三个标准流和重定向管道的体会是：掌握它们不是记住几个符号，而是建立一套关于"数据从哪里来、到哪里去"的心智模型。一旦你习惯用输入输出流的视角去理解命令行和脚本，以后排查问题会快得多，写脚本也更有底气。建议遇到任何看不懂的命令组合，都先拆一拆：左边命令的哪个输出流被接到了哪里，右边命令的哪个输入流在接收数据。搞明白这条链路，重定向和管道基本就没秘密了。
