不管你是刚学 Linux 系统编程，还是写 C/C++ 写了好一阵子却总在printf和write之间犯迷糊，文件描述符（fd）都是一道绕不过去的坎。我们每天都在用ls > out.txt把命令结果存进文件，也见过2>&1把报错信息一起重定向，但再往深问一句——这些 shell 语法背后，操作系统到底做了什么事？答案就是文件描述符。
这篇文章我会从 fd 的视角把 Linux 基础 IO 完整捋一遍：open/read/write/close四个系统调用的真实行为、0/1/2 三个标准描述符的来历、重定向的底层原理，以及新手最容易踩的“stdio 缓冲区和文件描述符互坑”问题。内容偏向底层机制，但不堆砌内核源码，用纸面推演和可运行代码说话。适合刚接触系统编程的人，也适合那些用 C 写过日志库、但一直没搞懂 fd 本质的人。
1. 先想清楚：为什么“打开文件”拿到的只是一个数字
1.1 从一次简单的输出重定向说起
你在终端敲下./demo > file.txt的时候，shell 会做三件事：先创建一个新文件，再把标准输出重定向到这个文件，最后执行你的程序。这句话听起来平平无奇，但“标准输出重定向”在系统调用层面并不是什么魔法，而是对文件描述符的重新绑定。
open()是典型的系统调用，它把文件路径交给内核，内核在磁盘上找到这个文件（或者在目录项层面定位），然后返回一个非负整数给你。你后面所有对这个文件的操作，都不再使用路径，而是使用这个整数。这个整数就是文件描述符（fd）。为什么不直接返回一个指针或者一个句柄结构？因为用户态和内核态之间不能随便传递内核对象地址，内核把文件的管理信息放在自己的内存空间里，用户程序只能拿到一个索引号。
你可以把它想象成图书馆的存包柜：你把包交给管理员，管理员给你一个手牌（fd），之后你说“我要拿 5 号柜里的东西”，管理员就知道去哪个柜子取。你完全不需要知道柜子在走廊的哪个位置、里面怎么排列，只管把手牌递过去就行。
1.2 那个叫“文件描述符表”的进程私有空间
每个进程在内核里都有一张文件描述符表，这张表本质上是数组，下标就是 fd 编号，数组里装的是指向内核文件对象的指针。用户程序每次调用open()，内核做的第一件事就是在当前进程的描述符表里找一个空位，填上新指针，然后返回这个下标。
这里有个非常关键的结论：fd 表是进程私有的。进程 A 里的 fd 3 和进程 B 里的 fd 3 没有任何关系，就算两个进程打开同一个文件，它们拿到的 fd 编号也可能不同。只有父子进程在 fork 时，子进程会拿到父进程描述符表的副本，这时候两边相同编号的 fd 才指向内核里同一个文件对象。
理解了这张表，再看“一切皆文件”就顺了。Linux 里的文件不只是磁盘上的普通文件，还包括管道、socket、设备节点、procfs 里的虚拟文件。它们在内核里都实现了文件操作的接口，所以都能用 fd 管理。你写网络程序时accept()返回的也是一个 fd，操作管道时拿到的也是一个 fd，它们的底层机制和操作普通文件基本一致。
2. 打开、读写、关闭：fd 生命周期里的四个关键调用
2.1 open 的权限位与 umask：一个容易静默坑掉的选择
open的完整签名是：
#include <fcntl.h> #include <sys/stat.h> int fd = open(const char *pathname, int flags, mode_t mode);flags有三组常用值：只读O_RDONLY、只写O_WRONLY、读写O_RDWR。注意这三个值必须且只能选一个，不能同时传O_RDONLY | O_WRONLY。其它常用的标志还有O_CREAT（文件不存在就创建）、O_TRUNC（打开时把文件长度截断为 0）、O_APPEND（追加写）和后面会用到的O_CLOEXEC。
mode参数只在O_CREAT起作用时才有意义。但你别以为传了 0666 就能拿到 0666，内核会把进程的umask叠加上去。默认 umask 是 022，也就是把组和其他用户的写权限抹掉。你传0666，实际创建出来的文件权限是0666 & ~022 = 0644。想确认最终权限，用stat看一眼就知道了。
umask 0022 ./demo # 代码里 open("out.txt", O_CREAT | O_WRONLY, 0666) ls -l out.txt # -rw-r--r-- ... out.txt这个坑通常在写守护进程、写 socket 绑定文件、写临时文件时出现。你期望文件是 0666，结果别的用户读不了。解决办法有两个：要么在程序里显式调用umask(0)（只改当前进程的 umask，不影响其它进程），要么创建完文件后再用fchmod修正。
2.2 read/write 的返回值：EOF、错误、和稀碎的返回值
读写函数的三个返回值必须刻在脑子里：
read返回 0，表示读到了文件尾（EOF），没有更多数据可读。read返回 -1，表示出错，具体原因看errno。write返回实际写入的字节数，这个返回值可能比你请求的字节数小，尤其是写管道、写 socket、或者磁盘空间不足的时候。
新手最容易忽略的是write的短写问题。比如你调用write(fd, buf, 1000)，返回值是 500，那么这 500 字节已经写完了，你还得接着把剩余 500 字节从buf + 500开始再写一次。严谨的代码都会用循环把没有写完的数据补上：
ssize_t write_all(int fd, const void *buf, size_t count) { const char *p = buf; size_t written = 0; while (written < count) { ssize_t n = write(fd, p + written, count - written); if (n < 0) { if (errno == EINTR) continue; // 被信号打断，重试 return -1; } written += n; } return written; }EINTR也是一个值得单独说明的点。当进程在read/write中阻塞时，如果来一个信号，系统调用可能被中断返回 -1，errno是EINTR。这个错不是你程序逻辑的问题，通常直接重试就行。很多线上事故的日志里反复出现“read interrupted by signal”，就是因为代码没处理EINTR。
2.3 不 close 会发生什么：fd 泄漏的连锁反应
进程能同时打开的 fd 数量是有限的，默认值一般是 1024，可以执行ulimit -n查看。这 1024 个名额包括 stdin、stdout、stderr 占掉的 0/1/2，也就是说你的程序理论上还能再打开 1021 个文件。
如果你每次open之后不close，文件描述符表会被慢慢占满。一旦满员，后续所有open、socket、accept都会失败返回 -1，errno是EMFILE（进程级文件表满）或ENFILE（系统级文件表满）。更隐蔽的是，你关闭了一个 fd 之后，这个编号马上可以被新打开的文件复用，如果你不小心把已经关闭的 fd 又write了一遍，数据很可能写进了另一个新打开的文件，这种 bug 极其难查。
写日志系统、写守护进程时尤其要小心。某个模块每秒钟打开一次文件写日志然后忘记关闭，一小时后服务突然报“too many open files”，排查半天才发现是 fd 泄漏。建议养成习惯：每个 open 必须有对应的 close，且用 RAII 或 goto err 的方式保证异常路径也能关闭 fd。
3. 0、1、2 为什么雷打不动：标准流里面藏着的设计
3.1 三个固定编号的具体含义
Linux 有一个约定，每个进程启动时，fd 表的前三个位置默认被占用：
- fd 0：标准输入（stdin），对应 C 库的
STDIN_FILENO - fd 1：标准输出（stdout），对应
STDOUT_FILENO - fd 2：标准错误（stderr），对应
STDERR_FILENO
你在终端跑程序，终端设备驱动会被打开三次填到这三个位置。printf最终写到 fd 1，perror最终写到 fd 2。为什么错误信息要单独占一个 fd？因为如果你把标准输出重定向到文件，程序产生的正常输出进了文件，报错信息如果也跟过去，你在终端上就什么都看不到了。把错误留在 fd 2，用户才能一边把结果写进文件，一边在屏幕上看到异常。
这就是你对2>&1语法一直觉得神秘的原因。2>&1的含义不是“把 2 变成 1”，而是“把 fd 2 变成 fd 1 的副本”，让错误输出和标准输出指向同一个地方。如果命令写成./demo > out.txt 2>&1，正常输出和错误输出都进文件；如果写成./demo 2>&1 > out.txt，顺序不同效果不同，前者先复制 1 再改变 1，后者先改变 1 再复制 1，结果 fd 2 仍指向终端。
3.2 不止磁盘文件：管道、设备、socket 都是文件
这三个标准 fd 指向的不是普通磁盘文件，而是终端设备文件。这说明一个关键点：fd 的处理对象可以是任何实现了读写接口的内核对象。管道也不例外。
ls | wc -l这条命令能跑通，是因为 shell 创建了一个管道，ls的 fd 1 被重定向到管道写端，wc的 fd 0 被重定向到管道读端。管道本质上是一个内核缓冲区，你说它是文件也不是完全准确，但它确实通过 fd 来操作。同理，你写网络程序时：
int client_fd = accept(listen_fd, ...);拿到的client_fd也是一个普通的非负整数，它和打开磁盘文件拿到的东西没有本质区别。这意味着你可以用read/write从 socket 上读数据写数据，也可以用close关闭连接。理解这一点，学习网络编程的曲线会平缓很多。
4. 最小未使用原则：重定向背后的那只“看不见的手”
4.1 先关闭再打开：传统重定向的完整推演
假设我们想让一个程序把它的标准输出写到文件里，最朴素的做法是什么？先关闭 fd 1，然后打开目标文件。内核的 fd 分配遵循一个非常简单粗暴的原则：每次分配当前最小可用的编号。
这个过程可以一步一步推演：
- 进程启动，fd 0/1/2 被终端占用。
- 调用
close(1)，描述符表里的下标 1 变成空闲。 - 调用
open("out.txt", O_CREAT | O_WRONLY, 0644)，内核扫描描述符表，发现 0 和 2 都有人用，1 是空的，就把新文件对象挂到下标 1 上。 - 程序照常
printf，数据通过 fd 1 写进文件。
这就是重定向的底层原理。shell 的>操作符，本质上就是帮被执行的程序先做了第 2、3 步，再启动你的程序。你可以在自己的 C 代码里手动复现：
#include <stdio.h> #include <fcntl.h> #include <unistd.h> int main(void) { close(1); // 释放标准输出 int fd = open("out.txt", O_CREAT | O_WRONLY, 0644); printf("fd = %d\n", fd); // 这时 printf 写到 out.txt puts("hello, output file!"); return 0; }运行完打开out.txt，你会看到：
fd = 1 hello, output file!注意第一行printf("fd = %d\n", fd)本身也被写进了文件。这才是彻底理解 fd 的好实验——你甚至能亲眼看到“内容是写给 fd 1 的”这个事实。
4.2 dup2：比先关后开更安全的重定向
先关后开的做法有两个问题。第一，close(1)和open()中间有一小段窗口期，如果这期间别的线程或信号处理器里碰巧执行了文件操作，可能抢走 fd 1，导致后续重定向失败。第二，操作不是原子的，中间状态不可控。
标准解决方案是dup2：
#include <unistd.h> int fd = open("out.txt", O_CREAT | O_WRONLY, 0644); dup2(fd, 1); // 把 fd 1 变成 fd 的副本 close(fd); // 原 fd 可以关了dup2(fd, 1)的意思是：让 fd 1 和 fd 指向内核里同一个文件对象。如果 fd 1 之前已经打开着，它会先被自动关闭。整个操作由内核保证原子性，不会出现中间态。
之后你对 fd 1 的写入，和直接对旧 fd 的写入效果一样。dup2返回 1 代表成功，返回 -1 代表失败。常见的失败原因是第二个参数太大了（超过RLIMIT_NOFILE）。
4.3 缓冲区插队：重定向前后顺序搞错就等着掉坑吧
很多人在手动做重定向时遇到一个现象：明明printf在重定向前执行，最后输出却出现在新文件里。这段逻辑要看懂，关键是在printf和write的区别。
printf属于 C 标准库，它先把数据写进用户态缓冲区stdout，缓冲区稍后才通过系统调用write真正进入内核。如果stdout连接到终端，通常是行缓冲，遇到换行就 flush；如果重定向到文件，缓冲策略自动变成全缓冲，只有缓冲区满了、程序正常退出、或显式fflush时才真正写出去。
考虑这段代码：
int fd = open("out.txt", O_CREAT | O_WRONLY, 0644); printf("before redirect\n"); dup2(fd, 1); printf("after redirect\n");第一行printf如果因为终端行缓冲已经写到了终端，那没有问题。但如果stdout之前已经被重定向到了文件、变成全缓冲，那“before redirect”还躺在用户态缓冲区里，dup2把这个缓冲区“钉”在进程里，之后flush时，这些陈旧内容就会跟随新 fd 写进out.txt，导致文件里出现“本该出现在终端”的字符串。
正确的做法是在重定向前显式fflush(stdout)，或者干脆用write写标准输出。这个坑在写监护进程、写日志库、手动实现 shell 重定向时经常踩。规律是：如果你要操作 fd，就要清楚 user-space 缓冲区里还残着多少没落地的数据。
5. 从 fd 往里走一步：内核里的文件对象与共享偏移
5.1 同一文件被打开两次：为什么偏移量各走各的
fd 指向的内核对象是struct file，这个结构体里记录了文件的读写偏移、操作函数表、标志位、以及指向inode的指针。文件偏移存在struct file里，而不是存在inode里，这一点让两个独立打开的 fd 可以各自拥有独立的读写位置。
看下面这段代码：
int fd1 = open("record.txt", O_RDWR); int fd2 = open("record.txt", O_RDWR); read(fd1, buf, 10); // 从文件头读到 10 字节，fd1 偏移变成 10 read(fd2, buf, 10); // 也是从文件头读！fd2 偏移还是 0fd1和fd2指向两个不同的struct file，所以偏移互不干扰。这很合理：两个程序同时读同一个日志文件，各自记录各自的进度，总不能让一个进程把另一个进程的读取位置给顶没了。
但如果两个 fd 指向的是同一个struct file，偏移就会共享。什么时候会出现后者？最常见的是fork之后和dup系列函数产生的 fd。
5.2 fork 后父子进程的 fd：共享的那个 file 对象
fork()创建子进程时，内核会把父进程的文件描述符表整体复制一份。注意“复制”的是表本身，不是表里的指针指向的内核文件对象。也就是说，子进程的 fd 0/1/2 和父进程的 fd 0/1/2 最终指到同一个struct file。
这个设计的第一个后果是：父子进程共享同一个文件偏移。如果一个进程读文件读了 100 字节，另一个进程再读同一个 fd，它会从第 100 字节继续，而不是从头开始。这个特性对管道至关重要——父进程往管道写，子进程从管道读，两边用的是同一个管道文件对象，偏移和同步语义才能成立。
第二个后果是引用计数。父进程close(fd)之后，内核不会立刻销毁struct file，因为子进程还引用着它。只有所有引用都关闭了，文件对象才被释放。
这里有个实用的排错经验：如果你 fork 之后，父子进程同时对同一个 fd 进行写操作，要注意它们操作的是同一个文件对象，offset 是共享的，写入数据会互相交错。这不是 bug，而是 POSIX 定义的行为。想避免这种情况，可以在 fork 之后各自重新open文件，得到独立的文件对象。
5.3 O_APPEND 与 O_TRUNC：标志位在内核里怎么生效
O_TRUNC工作在打开时，它会把文件长度截断为 0，前提是你有写权限。这也是为什么很多程序写日志不会加O_TRUNC，否则每次启动都会清空历史日志。你更常见的是O_APPEND。
O_APPEND的行为是：每次write之前，内核自动把文件偏移移到文件末尾，然后执行写入。关键是这个“移到末尾”和“写入”必须是一个原子操作——两个进程同时以追加模式写同一个文件，不会出现互相覆盖的情况，每条日志都会完整地排在文件末尾。
如果你用非追加模式打开同一个文件，两个进程同时write，就会出问题：进程 A 把偏移挪到位置 100，进程 B 也把偏移挪到位置 100，然后 A 写一行，B 再写一行就覆盖了 A 的内容。日常写日志文件，只要不追求极高并发下的强制顺序，用O_APPEND就是最省心的选择。
6. 自己动手：用 read/write 实现一个迷你 cat
6.1 完整实现与运行效果
有了上面的基础，现在可以写一个最小可用的cat命令。cat的核心逻辑非常朴素：循环read，读到多少就write多少，直到read返回 0。把 fd 0（标准输入）里的数据搬到 fd 1（标准输出）。
#include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <errno.h> int main(int argc, char *argv[]) { int fd = 0; // 默认读标准输入 if (argc > 1) { fd = open(argv[1], O_RDONLY); if (fd < 0) { perror("open"); exit(1); } } char buf[4096]; ssize_t n; while ((n = read(fd, buf, sizeof(buf))) > 0) { ssize_t off = 0; while (off < n) { ssize_t w = write(1, buf + off, n - off); if (w < 0) { if (errno == EINTR) continue; perror("write"); exit(1); } off += w; } } if (n < 0) { perror("read"); exit(1); } if (fd != 0) close(fd); return 0; }这段代码已经可以正确读取参数指定的文件，且处理了write短写和EINTR。如果把它编译出来，再用管道把数据喂给它：
echo "hello fd" | ./mcat你会看到数据从管道流进 fd 0，再从 fd 1 流到终端。这等于你自己实现了一个只依赖系统调用的过滤器。
6.2 缓冲区大小对性能的影响：一次 read 到底读多少
我试着把缓冲区从 1 字节改成 32KB，读一个大文件，用strace -c统计系统调用的次数。缓冲区越大，read的次数越少，总耗时下降极快。1 字节时，读 1MB 文件要做超过 100 万次系统调用，而用 32KB 缓冲区只需要 32 次。
这正好引出 C 标准库fread/fwrite存在的意义：fread其实内部维护了一个大缓冲区，第一次调用可能在用户态去读 4KB，之后用户请求小数据时直接从缓冲区拿，不再触发系统调用。这就是“用户态缓存”和“内核态缓存”的区别。你平时用printf不觉着慢，是因为真正的写入已经被延迟且合并了。
从实践角度，自己用系统调用读写数据时，缓冲区设在 4KB 到 64KB 之间都合理。太小的缓冲区会让系统调用过于频繁，太大的缓冲区在多数场景下收益不再增长，没必要为了“大而大”。
6.3 混用 C 库函数和系统调用时，先弄清楚谁在缓存
另一个高频问题：printf和write混用，输出顺序为什么是乱的？
printf("first\n"); write(1, "second\n", 7);printf的数据先进stdout缓冲区，write则不经过缓冲区直接进内核，所以终端上先看到second，等缓冲区 flush 后才看到first。如果你必须混用，要么在printf后fflush(stdout)，要么干脆统一走write。
与此相关的还有fileno(FILE*)和fdopen(fd, "w")这两个接口。fileno从FILE*拿到它所包裹的 fd，fdopen把一个已打开的 fd 包装成FILE*。这两个接口能让你在 C 库函数和系统调用之间切换，但也最容易引发缓冲区问题。我的建议很简单：一个文件对象在同一时间段内，要么用FILE*系列函数处理，要么直接用 fd 系列系统调用处理，不要来回横跳。横跳之前要想清楚缓存里的数据怎么办。
写到这里，其实已经把基础 IO 里和 fd 直接相关的骨架都过了一遍。fd 不是某个神秘的内核概念，它就是一个 int，一个打开的文件对象在你进程描述符表里的下标。后面如果再遇到网络编程时accept返回的句柄、select/poll监听的事件、fork后父子进程读写交错等问题，可以回来想想这张表、这个struct file指针，思路会清晰很多。
