Unix把IO藏成3个数字，程序员用了30年才发现真相

1973年，Ken Thompson在PDP-11上写下第一行Unix内核代码时，做了一个让后世程序员集体懵圈的设计：所有输入输出，不管来源是键盘、磁盘、网络还是/dev/null，统统塞进一张表，用整数编号。

这个设计简单到近乎粗暴。你打开一个文件，内核返回3。打开第二个，返回4。没有对象，没有句柄，没有流。就是3和4。

但就是这个"简陋"的抽象，撑起了半个世纪的计算基础设施。从嵌入式设备到云计算集群，从Python的print()到Docker的容器隔离，底层全是这张表在运转。

0、1、2：三个数字统治所有程序

每个Unix进程启动时，内核已经偷偷塞给它三个打开的文件。0指向标准输入，1指向标准输出，2指向标准错误。这三个数字不是约定，是写死在ABI里的铁律。

你写print("hello")，Python层层剥开，最终变成系统调用write(1, "hello\n", 6)。内核拿到数字1，查表，找到对应的内核对象，把6个字节扔过去。完事。

这个过程的抽象层级有多厚？print() → sys.stdout.write() → os.write() → write(2) syscall。四层包装，就为了把"hello"送到整数1。

你可以亲手拆掉这些包装。在Python里执行os.close(1)关掉标准输出，再用os.open("/dev/tty", os.O_WRONLY)重新打开终端。返回值是1，因为内核总是给最小的可用编号。然后os.write(1, b"I'm back\n")，屏幕照常输出。

标准输出不是魔法，只是文件描述符1碰巧指向了终端。

ls命令判断要不要输出彩色文本，调用的是isatty(1)——"1号描述符连着终端吗？"程序崩溃时往2写错误信息，read()阻塞等待输入时盯着0。这三个整数是Unix世界的通用语言。

文件描述符到底是什么

内核为每个进程维护一张表，索引就是那些小整数。表项指向真正的内核对象：文件描述结构（file description）。注意拼写：descriptor是进程层面的编号，description是内核层面的对象。一个description可以被多个descriptor指向，这就是dup()和fork()能工作的根基。

调用open()时，内核做三件事：创建或查找底层的文件系统对象，新建一个file description包装它，在进程表里找个空位塞进去。返回的就是那个空位的索引。

这个设计的一个副作用是：关闭文件描述符不会立即释放资源。只有当最后一个指向该description的descriptor被关闭，内核才真正清理。fork()之后父子进程共享description，各自持有独立的descriptor编号——但底层是同一个文件偏移量。父子交替写同一个文件，字节会交错，就是这个机制在作祟。

文件描述符能指向的东西远超字面意义的"文件"。套接字（socket）、管道（pipe）、终端、信号量、计时器、epoll实例、inotify实例、eventfd、timerfd、signalfd……在Unix眼里都是字节流，都塞进同一张表。

/dev/null是个文件。/dev/zero是个文件。/proc/self/mem是个文件。甚至进程间的通信管道，创建时也是返回两个文件描述符。这种"一切皆文件"的统一抽象，让select/poll/epoll能用同一套接口监视所有IO事件。

那些让你踩坑的边界

文件描述符有上限。ulimit -n默认是1024，旧系统上常见。现代服务器调到几十万也不稀奇。但每个进程能用的编号范围是0到OPEN_MAX-1，超过就返回EMFILE错误。

更隐蔽的是"文件描述符泄漏"。程序打开文件后忘记关闭，编号被占满，后续open()失败。这类bug在长生命周期的服务里尤其致命。valgrind的fd追踪、strace的-e trace=desc参数，都是诊断这类问题的利器。

非阻塞IO和文件描述符纠缠很深。fcntl(fd, F_SETFL, O_NONBLOCK)改变的不是文件本身，而是该descriptor的访问模式。同一个文件被两个descriptor打开，一个设为非阻塞，另一个仍阻塞——它们指向同一个description，但各自有独立的flag。

close-on-exec标志（FD_CLOEXEC）是另一个经典陷阱。fork()+exec()是Unix创建新进程的标准套路，但子进程会继承父进程的所有文件描述符。如果子进程exec()执行外部程序，那些descriptor就泄漏给了完全无关的程序。设置close-on-exec让descriptor在执行新程序时自动关闭，是现代程序的防御性编程标配。

Go语言的net/http包曾经因为这个标志吃过亏。某个版本里，HTTP keep-alive连接的文件描述符没有设置CLOEXEC，子进程继承后，父进程关闭连接，子进程仍然持有，导致TCP半开连接堆积。这个问题在2017年的一个issue里被揪出来，修复就是一行fcntl调用。

从select到io_uring：一张表的进化史

文件描述符的编号机制决定了IO多路复用的基本形态。select()接受三个fd_set，分别监视可读、可写、异常事件。但fd_set是固定大小的位图，默认1024位，想监视更多就得重新编译内核。

poll()改进了接口，用数组替代位图，没有数量限制。但两者都有根本缺陷：每次调用都要把监视列表从用户空间拷进内核，返回时再把结果拷出来。fd数量上去，开销线性增长。

epoll()是Linux的终极答案。epoll_create()返回一个特殊的文件描述符——对，文件描述符可以指向另一个文件描述符的监视器。epoll_ctl()把感兴趣的fd注册进这个epoll实例，epoll_wait()阻塞等待事件。监视列表常驻内核，无需重复拷贝，复杂度从O(n)降到O(1)。

Redis的单线程高性能，Nginx的十万并发，底层都是epoll在驱动。那个epoll实例本身也是文件描述符，可以被另一个epoll监视——这种嵌套能力让事件驱动架构有了无限组合的可能。

但epoll仍是同步接口。程序调用epoll_wait()，内核阻塞，有事件时唤醒。真正的异步IO需要io_uring。2019年Linux 5.1引入的这个子系统，让程序一次性提交一批IO请求，内核完成后通过环形缓冲区通知结果。文件描述符仍是核心抽象，但交互模式从"拉"变成了"推"。

Linus Torvalds在io_uring的pull request下评论：「这是Linux IO的未来」。截至2024年，PostgreSQL、Nginx、QEMU都已支持io_uring作为可选后端。

容器时代的文件描述符战争

Docker和Kubernetes把文件描述符玩出了新维度。容器启动时，守护进程创建一组命名空间（namespace），其中PID namespace让容器里的1号进程以为自己独享系统。但文件描述符的继承链条穿透了这些边界。

docker run的--init标志注入一个微小的init进程，主要工作之一就是接管僵尸进程，以及正确管理文件描述符的传递。没有它，容器主进程收到的信号和文件描述符行为会出现微妙偏差，调试时让人抓狂。

更深层的是/proc/self/fd。这个虚拟目录把进程的文件描述符表暴露为符号链接，/proc/self/fd/0指向标准输入的实际文件。ls -la /proc/self/fd是诊断IO问题的常用技巧：你能直接看到每个编号指向什么，是管道、套接字、还是普通文件。

systemd作为现代Linux的init系统，把文件描述符管理推到了极端。socket激活（socket activation）机制让服务在真正需要时才启动，但socket提前由systemd创建，通过文件描述符传递给子进程。systemd的源码里，fd的传递和重新编号逻辑占了相当篇幅——这是守护进程编程的暗面，文档稀少，坑却极深。

2021年，systemd 247版本引入了一个争议改动：默认限制服务可继承的文件描述符数量。某些依赖大量fd继承的传统程序突然崩溃，社区花了数月才理清兼容方案。这个事件暴露了Unix遗留抽象在现代规模下的张力。

那些藏在编号里的历史债务

文件描述符的设计并非没有代价。整数编号的稀疏性让某些场景变得别扭。比如你想监视100万个并发连接，epoll确实能处理，但每个连接对应一个fd编号，内核要维护巨大的查找表。某些高性能网络框架开始探索绕过传统fd抽象，直接用内存映射的环形缓冲区——但那是另一个故事。