REECHO大鱼总舵搞Linux命令行的人，早晚都会撞上重定向这三个符号：>、>>、<。我见过刚转过来用Linux的同事对着 ls > list.txt 发愣——屏幕上明明什么都没显示，文件里却多了一串内容；也见过写了几年脚本的人，栽在 2>&1 和 > 的先后顺序上，半夜对着空日志挠头。重定向本身不复杂，核心就三件事：把标准输出写进文件、把内容追加到文件末尾、把文件内容喂给命令当输入。可真正理解它，需要先搞清楚Shell启动命令时那三股数据流是从哪来、往哪去。
这篇文章写给两类人：一是刚入门、想系统弄明白重定向原理的；二是已经会用但只会死记硬背、一换场景就懵的。我会从数据流讲起，把 >、>>、< 三种方式逐个拆开，再补上 2>、2>&1、heredoc、/dev/null 这些一定会遇到的衍生用法，最后用一个完整的排查场景展示它们怎么组合。看完你至少能做到：不仅知道每个符号是干什么的，还能在出问题时自己推一遍它到底把数据送去了哪。
1. 先分清三股数据流：标准输入、标准输出、标准错误
在讲重定向之前，必须先把“门”认清楚。Linux里每一个进程启动时，内核都会默认给它打开三个通道，这三个通道在编程视角里就是文件描述符0、1、2。很多教程直接让你背“0是输入、1是输出、2是错误”，背是背下来了，可一旦遇到 2>&1 这种组合，照样抓瞎，原因就是不明白这三个号码到底代表什么。
1.1 0、1、2 究竟是哪三扇门
你可以把每个正在运行的命令想象成一个带着三根管子的盒子：
- 0号管是标准输入（stdin），默认插在键盘上，命令需要读数据时从这里拿；
- 1号管是标准输出（stdout），默认接在终端屏幕上，正常结果从这里吐出来；
- 2号管是标准错误（stderr），默认也接在终端屏幕上，报错信息从这里冒出来。
这里最关键的一点是：Linux里“一切皆文件”，你用的终端本身也是一个文件。所以所谓重定向，本质上就是“拔掉某根管子，把它重新插到另一个文件上去”。> 是把1号管从屏幕挪到文本文件，< 是把0号管从键盘挪到文本文件，仅此而已。
为什么系统要特意把错误和正常输出分开？这是Unix设计里一个很聪明的决定：程序跑出来的核心数据是要被下一个程序继续处理的，而警告和报错是给人看的“诊断信息”。让这两股数据混在一起，下游程序解析数据时就会莫名奇妙地断掉。所以宁可多开一根管子，也不要互相污染。
一个最直观的例子：
bash复制echo "hello" # 走1号，显示在屏幕
ls /no/such/path # 走2号，也显示在屏幕
直接跑时根本看不出区别，因为默认都落在终端上。一旦重定向，立刻分家：只重定向1号，错误照样从屏幕蹦出来；只重定向2号，正常结果还在屏幕。新手第一次遇到“怎么我把输出存文件了，屏幕上还有东西在刷”，多半就是没意识到自己看到的是2号管的内容。
1.2 没有终端时，这三根管子往哪插
平时在交互终端里敲命令，三根管子的去向一目了然。但脚本一旦被丢进后台、写进定时任务，情况就变了：没有终端给它们当默认目标，程序往1号或2号管写东西时，可能写到空设备，也可能直接失败。这就是为什么凡是放进定时任务里的脚本，开头几乎都有一堆重定向。
我自己习惯在写这类脚本时先把全套重定向摆好，而不是等到出问题再补。比如：
bash复制#!/bin/bash
./run_task.sh > /tmp/task_out.log 2>&1
就算脚本内部什么都不写，“跑完有没有成功、报了什么错”这个信息也不会丢。理解了三根管子的存在，再回头看 >、>>、<，你会发现它们都只是“换插孔”的动作。下面逐个拆。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 输出重定向（>）：先截断再写入的机制
> 是最常用的一个，也是最容易被误用的一个。很多人只记住了“把命令的结果存到文件里”，却没注意到它背后其实有两个动作：清空文件和接管输出。
2.1 一个符号，两个动作：创建或清空，然后接上输出
执行这条命令：
bash复制ls -l > listing.txt
Shell在做 ls 之前就已经做了两件事：第一，如果 listing.txt 不存在，就创建一个；第二，如果它已经存在，就把它原有的内容全部清空（专业术语叫截断）。然后才把1号管插到这个文件上，让 ls 的输出流进去。
你可以做个实验验证这个顺序：
bash复制echo "old data" > test.txt
> test.txt # 前面不带任何命令，只写一个重定向
cat test.txt # 什么都没有了
> test.txt 单独一行，虽然没有命令，但Shell照样先执行了“截断”这个动作。这个特性在某些场景是刻意利用的——比如你想把日志文件清空但又保留它的inode和权限，> app.log 就比 rm 再 touch 省事得多。但更多时候，它是个坑。
2.2 输出文件不能同时是输入文件：一个经典的清空事故
我见过不止一个人写出这种命令：
bash复制grep "key" config.txt > config.txt
本意是想在配置里筛出含 key 的行，覆盖写回文件。但按刚才的顺序推一遍就懂了：Shell先打开 config.txt 并截断，然后 grep 才启动，这时候 config.txt 已经是空文件，grep 什么都没读到，等你反应过来，配置已经没了。
同样的事故还发生在 cat 身上：
bash复制cat file.txt > file.txt
推演结果完全一样：文件先被清空，cat 读到的还是那个文件，但内容已经没了。这类错误的根源是“命令读文件”和“Shell重定向写文件”发生在不同的阶段，Shell先动作、命令后动作。所以有一条铁律一定要记住：永远不要让命令的输出文件，同时又是它的输入文件。想过滤内容还要写回原文件，你得用临时文件或者 sed -i 这类专门设计的原地编辑工具。
2.3 加一道保险：noclobber 与强行覆盖
既然 > 这么容易误伤已有文件，Shell提供了一个保险开关：
bash复制set -C # 开启 noclobber
set +C # 关闭
开启之后，再执行 > existing.txt 会直接报错，提示不能覆盖已有文件。这时候如果你确实想覆盖，得用 >| 这个变体，感叹号相当于强制：
bash复制>| existing.txt
这个开关非常适合那种跑在深夜、又对路径很敏感的后台任务。路径一旦写错，> 可能把遥远目录里的同名文件瞬间清空；有了 set -C，至少会停下来报警，而不是默默毁掉数据。代价是脚本里所有正常的覆盖写入都得改用 >|，所以更适合在关键脚本里局部使用。
3. 追加重定向（>>）：写日志的刚需姿势
> 是把内容“倒空再灌”，而 >> 只做一件事：在文件末尾接着写。符号只差一个，语义天差地别。
3.1 打开标志不同：O_TRUNC 与 O_APPEND
系统层面看，> 打开文件用的是“只写+创建+截断”，>> 用的是“只写+创建+追加”。一个是把文件长度归零再写，一个是永远从当前末尾接着写。用一小段命令就能看得清清楚楚：
bash复制echo "第1行" > log.txt
echo "第2行" >> log.txt
cat log.txt
结果自然是两行都在。如果第二行也用了 >，那log.txt里只会留下“第2行”。追加重定向解决的核心问题是“积累”——历史不能丢，每次运行都要在完整轨迹上续写。
3.2 循环任务与多轮实验：为什么这里必须用追加
跑实验或处理批量任务时，我几乎不用 > 写日志，原因很简单：跑的过程可能持续很久，如果中途某个环节崩溃，> 的结果是被截断前的旧日志，还是崩溃前最后一次写入的零散片段？两种都不好看。用追加就稳得多：
bash复制for i in $(seq 1 20); do
echo "run $i start: $(date)" >> experiment.log
./job.sh >> experiment.log 2>&1
done
每一轮开始都带时间戳，每一轮的输出都接在文件末尾。哪怕跑到第17轮挂掉，也可以从尾部看到最后发生了什么，前面的记录一分不少。这在回溯问题时是救命级别的价值。
另一个容易被忽略的点：多进程同时追加时，>> 的 O_APPEND 特性让每次写入先定位到当时末尾再写，相比 > 对同一文件反复截断造成的混乱，安全得多。当然这不代表它可以替代正经的日志系统，锁和轮转还是得有，但它已经足够应付日常脚本。
3.3 错误信息单独追加：2>>
追加同样适用于2号管：
bash复制./run_task.sh >> result.log 2>> error.log
这个写法在跑数据处理、长时间计算时特别常见：正常的结果积在 result.log，异常全部进 error.log。排查时只看 error.log 就行，不用在几千行正常输出里翻错误。如果你连程序本身的标准输出也只想留尾部摘要，还可以配合 tail -f 边跑边看。
4. 输入重定向（<）：把文件变成命令的“喂食口”
如果说 > 和 >> 是改输出方向，那 < 就是改输入来源：命令不再从键盘读，而是直接从文件里拿内容。
4.1 基本用法与 wc、sort 的输出差异
最常见的组合是排序和统计：
bash复制sort < names.txt > sorted.txt
wc -l < big.log
注意一个细节：wc -l < big.log 和 wc -l big.log 的输出不一样。前者只输出一个数字，因为 wc 看到的是标准输入流，并不知道文件名；后者会输出“数字+文件名”。在脚本里如果只想取行数继续运算，前者干净得多，少了一次文本切割。
还有个新手常问的问题：cat names.txt | sort 不是也可以吗？能，但没必要，多启动了一个 cat 进程，数据也多走一次管道拷贝。管道有自己的适用场景（比如多个命令串联、中间结果不想落盘），但单纯把文件内容喂给一个命令时，< 是更直接高效的做法。
4.2 heredoc（<<）：不读文件，直接把段落塞进输入
heredoc 是输入重定向的变体，不读外部文件，而是把脚本里的一段文本当作标准输入。写法是用两个分界标记夹住内容：
bash复制cat <<EOF
第一行
第二行
EOF
这里的 EOF 只是一个标记词，你可以换成 END、MARK、XYZ，什么都可以，前后一致即可。实际用途非常广：
- 快速生成多行配置文件；
- 给交互式命令批量喂入指令序列；
- 在远程机器上执行一组命令时，把整个命令块通过标准输入传过去。
有一个细节值得单独记：分界标记加不加引号，行为完全不同。
bash复制cat <<'EOF'
$HOME 原样输出
EOF
加引号后，里面的变量不会被展开，$HOME 会以字符串形式原样出现，适合生成脚本模板；不加引号则会先展开变量，适合生成包含当前环境信息的配置。搞混这个，你可能会得到一份写着 $HOME 的配置，然后排查半天为什么路径不对。
4.3 here string（<<<）与逐行读取的 while 循环
<<< 是bash的扩展，把后跟的字符串整体作为输入：
bash复制grep -o '[0-9]\+' <<< "订单号 2024001"
和 echo "订单号..." | grep 效果相近，但少一个管道进程，也更直观。
更实用的是逐行读取文件的循环模式：
bash复制while read ip; do
ping -c 1 "$ip" > /dev/null && echo "$ip ok" || echo "$ip down"
done < ip_list.txt
注意最后一行 done < ip_list.txt，这就是输入重定向。这里有个很隐蔽的坑：如果你改写为 cat ip_list.txt | while read ...，循环会跑在子shell里，循环内改动的变量在循环结束后读不到。而 done < file 的形式，循环和当前shell在同一个进程里执行，变量改动能保留下来。我处理过不止一次因为“管道后的循环里变量改完没用上”而导致的脚本bug，根源都在这里。
5. 合流与分流：2>&1 的顺序和 /dev/null 的用法
讲到这里，三根管子已经都认识了，但实际脚本里见得更多的反而是组合操作——把1号和2号合到同一处，或者把某个出口彻底堵掉。组合操作的第一个大坑就是 2>&1 的位置。
5.1 从左到右处理，先看的先改
bash 对重定向是从左到右逐条处理的，每次处理都是以“当前各管子的指向”为基准。这就是 2>&1 放前面和放后面结果完全不同的原因。
先看正确写法：
bash复制command > file 2>&1
执行顺序是：第一步把1号管指向 file；第二步把2号管指向“当前1号管的位置”——也就是 file。结果两股输出全进了文件。
再看坑人写法：
bash复制command 2>&1 > file
第一步先把2号管指向“当前1号管的位置”，可这一刻1号管还指着终端，所以2号管指向终端；第二步才把1号管改成 file。结果正常输出进了文件，错误信息还是打在屏幕上。
用个具体命令验证：
bash复制ls /etc/passwd /no/such > out.txt 2>&1
cat out.txt # 有两条：一条正常结果，一条错误消息
ls /etc/passwd /no/such 2>&1 > out.txt
cat out.txt # 只有正常结果，错误刚才已经在屏幕上了
为什么这么容易写错？因为人的直觉是“2>&1 就是把错误并给输出嘛”，可它并给的是“执行那一瞬间的输出指向”，不是永久绑定。想看住所有人的日志，必须把 2>&1 放在 > file 之后。
5.2 &> 与 &>>：简写与可移植性的取舍
bash 提供两个简便写法：
bash复制command &> file # 等价于 command > file 2>&1
command &>> file # 等价于 command >> file 2>&1
写起来短，看着也明白。但 &> 不是POSIX标准，如果你的脚本要跑在 sh 或其他类Unix shell上，最好老老实实写全 > file 2>&1。这也是为什么很多开源项目的脚本里你看到的都是长写法，而不是 &>——作者要照顾老sh。性能上两者没有区别，纯粹是口径问题。
顺带说一句，1> 和 2> 这种带数字的写法，其实就是显式指定修改哪根管子。默认不带数字时，> 等价于 1>。
5.3 /dev/null：把输出丢进黑洞
/dev/null 是Linux里的黑洞字符设备，写进去的内容直接消失，可以看作“无限容量的垃圾箱”。三个常见组合：
bash复制command > /dev/null 2>&1 # 全部静音
command 2> /dev/null # 只丢错误，正常输出还留着
command > /dev/null # 只丢正常输出，错误照样上报
最常用的场景是遍历大目录时静音权限报错：
bash复制grep -r "pattern" /usr 2>/dev/null
系统目录里大量“权限不足”的报错会被过滤掉，只留下真正匹配的内容。这里先提醒一点：2>/dev/null 和 >/dev/null 2>&1 不是一回事，前者只是堵住错误，正常输出仍然会打到屏幕上。想让命令安静跑完，三个红字要连起来写：> /dev/null 2>&1。
6. 实战组合：边看边存、分文件留存与一次记忆犹新的排错
单看每个符号都简单，真正的价值在组合。这一节放几个我日常会直接套用的模板，外加一次真实遇到过的指令顺序事故。
6.1 tee：既要文件又要屏幕
> 和 >> 都会把输出从屏幕上“夺走”，那有没有办法一边落盘一边实时看？有，用 tee：
bash复制./run_task.sh 2>&1 | tee run.log
2>&1 先把错误合到1号管，管道里传输的就是全部输出；tee 收到后一份写进 run.log，一份原样打回屏幕。如果想积累而不覆盖，用 tee -a run.log。这个命令特别适合“任务在跑，我想盯进度，又想把完整输出留档”的场景。
值得留意的是，tee 接收的是标准输入，所以它只认1号管里的东西。想让错误也进tee，必须在管道之前先把2号并到1号，也就是上面那个 2>&1。少了这一步，错误会绕过tee直接蹦到终端，日志文件里却什么都没有。
6.2 按日期分文件、按类型分流的模板
我处理多阶段任务时有个固定习惯：正常结果和错误日志分文件保存，文件名带上日期。模板大概是：
bash复制today=$(date +%Y%m%d)
./task.sh \
> "result_${today}.log" \
2> "error_${today}.log"
status=$?
echo "exit=$status" >> "result_${today}.log"
好处是回溯时非常爽快：某天出了问题，直接按日期找 error 文件；想还原当天的完整结果，看 result 文件。退出码单独追加进日志，也能快速判断那次运行是正常结束还是中途崩了。
如果任务是严格分阶段跑的，我还会在每阶段开始时追加一行时间戳分隔符：
bash复制echo "======== stage2 start: $(date) ========" >> run.log
这样一份日志里，几次运行、几个阶段之间划得清清楚楚，不会看到一半不知道是哪个时间点。
6.3 一个典型的顺序事故：错误到底去哪了
最后讲一个我印象深刻的排查经过。开发环境里有个定时任务，跑完以后主程序该输出的内容全在日志，唯独没有错误记录。任务本身跑得很快，也没有人盯着终端看，大家只是隔几天核对一下日志。
查了一会儿，问题锁定在脚本里的这一行：
bash复制command 2>&1 > task.log
按前面推演：2号先指向终端，1号再指向 task.log。任务运行期间的报错全都打在了没人看的终端上，屏幕滚过几行红色异常后消失，而 task.log 里只留下正常输出。写脚本的人以为自己在“把错误也收进日志”，实际上是把错误丢给了不存在的观众。
改成 > task.log 2>&1 之后，第二天再跑，所有输出都完整落盘。那次之后我们约定了一条不成文的规矩：凡是涉及合流的重定向，一律写 > file 2>&1 或者 >> file 2>&1，并且组内review时就盯着这个顺序看。这个坑之所以经典，是因为它完全违背直觉——符号写得越像“把错误并进去”，越容易把顺序写反。
关于重定向，我还有一个压箱底的习惯：在改脚本或敲长命令之前，先用 echo 配合重定向试一遍，确认目标文件路径和顺序没有写歪，再放真正的任务上去跑。这种测试花不了三秒钟，却能帮你避开绝大多数“日志没写进去”“文件被清空”之类的惨案。三根管子认清了，符号顺序记牢了，绝大部分重定向问题都能在动手之前自己先推演出来。