🔑 为什么
很多人第一次学 Shell 重定向时，会以为这两句命令只是写法顺序不同，结果应该一样。错了。它们的区别不在“语法长得像不像”，而在 Shell 是按从左到右依次处理重定向的，而文件描述符本质上只是进程手里的一组“编号好的出口”。
这就是设计上最容易被忽略的一点：重定向操作不是声明式配置，不是最后统一结算；它更像一连串立即生效的接线动作。比如
这套设计一点也不神秘，因为 Unix 从一开始就把“一切都当成文件接口来处理”。进程不需要知道对面是终端、文件还是管道，它只往编号 1 和 2 写数据。Shell 的工作只是提前把这些编号接到合适的位置上。这种设计非常实用：简单、统一、可组合。代价就是你必须理解“复制的是指向关系，不是名字本身”。
真正踩坑的时候，通常不是在课堂例子里，而是在日志和脚本里。你以为自己把错误输出也收进日志了，结果 CI 里报错还在控制台飞，日志文件里却干干净净；或者你把管道和重定向混着写，最后发现
🧪 课后一题：命令
💡 易混淆点：
#CS
2>&1 >out.log 和 >out.log 2>&1 结果不一样？很多人第一次学 Shell 重定向时，会以为这两句命令只是写法顺序不同，结果应该一样。错了。它们的区别不在“语法长得像不像”，而在 Shell 是按从左到右依次处理重定向的，而文件描述符本质上只是进程手里的一组“编号好的出口”。
1 是标准输出，2 是标准错误，2>&1 的意思不是“把错误也写进某个文件”，而是“让 2 指向当前 1 正在指向的地方”。这就是设计上最容易被忽略的一点：重定向操作不是声明式配置，不是最后统一结算；它更像一连串立即生效的接线动作。比如
cmd >out.log 2>&1，Shell 先把 1 接到 out.log，再把 2 接到“当前的 1”，所以最后标准输出和标准错误都进了文件。可如果你写成 cmd 2>&1 >out.log，Shell 会先把 2 接到“当前的 1”，而这时候 1 还指向终端；然后再把 1 改接到 out.log。结果就是标准输出进文件，标准错误还留在屏幕上。这套设计一点也不神秘，因为 Unix 从一开始就把“一切都当成文件接口来处理”。进程不需要知道对面是终端、文件还是管道，它只往编号 1 和 2 写数据。Shell 的工作只是提前把这些编号接到合适的位置上。这种设计非常实用：简单、统一、可组合。代价就是你必须理解“复制的是指向关系，不是名字本身”。
真正踩坑的时候，通常不是在课堂例子里，而是在日志和脚本里。你以为自己把错误输出也收进日志了，结果 CI 里报错还在控制台飞，日志文件里却干干净净；或者你把管道和重定向混着写，最后发现
stderr 根本没有进入下游命令。很多“日志丢了”的问题，不是程序错了，是 Shell 重定向顺序写错了。🧪 课后一题：命令
python app.py 2>&1 | tee run.log 里，标准错误会不会进入 tee？为什么？答案：2>&1tee💡 易混淆点：
2>&1 复制的是“当下 1 的去向”，不是永远跟着 1 一起变化；它不是绑定关系，只是一次接线动作。#CS
