企业官网建设流程全解析

前后几年我在服务端排查性能问题，十次有八次都得先问一句：你这边的网络I/O是阻塞还是非阻塞？用了多路复用没有？用的是select还是epoll？不是面试官爱问，而是这些问题直接决定了你的服务是轻松扛住十万连接，还是连接稍多就CPU飙红、线程池爆炸。这篇就来把Linux的五种I/O模型和I/O多路复用机制从头到尾梳理一遍，不讲那种背完就忘的八股文，而是结合我实际排障、写压测、调内核参数的经验，把每个模型“为什么要存在”“适合什么场景”“坑在哪里”讲透。

不管你是刚接触Linux网络编程的初学者，还是写过几年服务端但一直没把I/O模型抠细的开发/运维，这篇都值得花二十分钟慢慢读。看完你能做到两件事：第一，别人再问你“阻塞非阻塞、同步异步到底啥区别”，你能三句话讲明白；第二，遇到线上大量TIME_WAIT、高并发下CPU占用异常这类问题，你脑子里会有一张清晰的排查地图，而不是靠猜。

1. 先搞清楚I/O模型到底在讲什么

1.1 一次网络读取，到底发生了什么

很多人学I/O模型觉得抽象，是因为没想明白底层那点事。一次典型的网络读操作，比如调用recvfrom接收客户端数据，在内核里其实分成两个独立阶段：

• 第一阶段：等待数据准备好。数据还在网卡上、还在协议栈缓冲区里漂着，内核需要等它完整到达接收队列。
• 第二阶段：将数据从内核空间拷贝到用户空间。内核把收到的数据从自己的缓冲区复制到你分配的应用程序内存里。

这两个阶段是整个I/O模型理论的锚点。所谓“阻塞”或“非阻塞”，说的只是第一阶段的表现；“同步”或“异步”，说的是第二阶段是否由你的线程亲自参与。

我用一个生活化的类比：你在餐厅等一桌菜。阻塞I/O就是你坐在椅子上死等，菜不上来你什么都不干；非阻塞I/O就是你每过一分钟去厨房门口看一眼，没做好就回去继续玩手机；I/O多路复用就是你干脆跟服务员说“有菜好了叫我”，然后一个人盯着十几个桌子的下单屏，哪桌好了处理哪桌；异步I/O则是你把点菜、等菜、上桌全部交给餐厅，做好之后连菜都帮你端好放到面前，你只管张嘴吃。

这个类比不完美，但足够让你在第一遍接触时建立直觉。实际编码中，前面三种模型都要求你自己的线程参与“把数据搬到应用程序”这一步，所以严格说它们都是同步I/O。只有真正的异步I/O模型（如Linux的io_uring、Windows的IOCP）才让你发完请求就彻底撒手。

1.2 为什么C10K问题逼出了多路复用

回到互联网服务早期，一个服务撑住一万个并发连接（C10K）就是巨大挑战。最朴素的做法是：一个连接开一个线程/进程去处理。阻塞I/O配合多线程，模型简单、写起来顺，但一万个连接就需要一万个线程，每个线程默认栈空间8MB，光是虚拟内存就让人头大；线程切换频繁，CPU时间全耗在上下文切换上；线程增多后锁竞争、调试难度、内存占用全部恶化。

于是大家开始想：能不能一个线程盯着成千上万个连接，哪个连接有数据来了，我就去处理哪个？这就是I/O多路复用（I/O Multiplexing）的核心思想——用单个线程同时监视多个文件描述符，内核帮忙提供“哪些fd可读、可写、有异常”的状态通知。

注意，多路复用本身依然是同步阻塞式的：你调用select/poll/epoll_wait时线程照样会被挂起等待事件，但它等待的对象从“某一个连接的数据”变成了“这上万个连接里任何一个有动静”。这是质的飞跃——等待的单位从单个连接升级到了整个连接集合。后面讲的具体代码会证明这一点。

2. 五种I/O模型逐个拆解

2.1 阻塞式I/O（Blocking I/O）

这是最传统、也是大多数人写的第一版网络代码。

int n = recvfrom(sockfd, buf, len, 0, NULL, NULL); // 线程卡在这里，直到数据到达并且复制完成

调用recvfrom后，如果你的socket缓冲区空空如也，调用线程就进入睡眠状态，内核把线程挂到等待队列上，直到数据写入socket缓冲区，再把数据从内核空间拷贝到用户空间，然后唤醒线程返回。

优点是什么？代码逻辑无比直观，出错可能性低。写个demo、写个串口工具、写个低并发的管理通道，我都推荐直接用阻塞式，省心。

缺点呢？一个线程在同一时刻只能等一个fd。高并发场景下，要么疯狂开线程，要么连接排队，吞吐量上不去。另外还存在“惊群”问题的一个变种——多个线程各自阻塞在不同fd上时，负载均衡全靠运气。

注意：阻塞I/O不等于效率低。在后端服务里，如果你用线程池限制并发数，每个线程处理一个连接，连接数可控，阻塞I/O的性能其实是五种模型里最稳定的。真正出问题的场景是“连接数巨大但活跃度不高”的情况——大量线程占着内存，等一个不知道何时才来的包。

2.2 非阻塞式I/O（Non-blocking I/O）

非阻塞I/O把socket设置为O_NONBLOCK后，recvfrom的行为彻底改变：如果内核缓冲区没有数据，它不会让线程睡觉，而是立刻返回一个错误码EWOULDBLOCK（在Linux下和EAGAIN值相同，都是11）。

int flags = fcntl(sockfd, F_GETFL, 0); fcntl(sockfd, F_SETFL, flags | O_NONBLOCK); while (1) { int n = recvfrom(sockfd, buf, len, 0, NULL, NULL); if (n < 0 && errno == EWOULDBLOCK) { // 没数据，干别的去，隔一会儿再来问 continue; } // 处理数据 }

第一眼看过去，非阻塞I/O比阻塞高级，能“边等边干”。但注意，上面这个while循环实际上就是忙轮询——你的线程一直在用户态空转，疯狂调用系统调用，CPU占用率极其难看。你是不是真的“干别的了”？并没有，你只是在疯狂问“好了没，好了没，好了没”。

所以我的看法是：非阻塞I/O单独使用，几乎没有任何实际工程价值。它的真正价值在于“配合多路复用”——把socket设置为非阻塞，然后交给select/epoll去等事件，等到了事件之后，再用非阻塞模式去读取，保证不会因单次读取阻塞住整个事件循环。这个组合拳非常重要，3.2节会讲。

2.3 信号驱动式I/O（Signal-driven I/O）

这个模型很多教材都只是提一嘴，因为Linux下用得极少。思路是：给socket注册一个SIGIO信号处理函数，内核在数据到达时发送这个信号，你的进程收到信号后在处理函数里调用recvfrom读取数据。

听起来挺美——等待阶段不阻塞，有数据了内核主动通知。但实际工程里这个模型基本被抛弃了，原因很现实：

• 信号处理函数里能干的活极其有限，不能调用不保证异步安全的函数，标准库一半函数都不敢在里面用；
• 信号可能丢失、可能排队，Linux对标准信号的排队机制并不可靠；
• 在高并发下，频繁信号带来的上下文切换开销，比自己轮询还大。

所以你在真实项目中几乎见不到这种写法。面试里知道它的位置即可：它处在“多路复用与异步I/O”之间的过渡地带，属于有理论价值、缺工程价值的模型。

2.4 I/O多路复用（I/O Multiplexing）

重点来了。多路复用本质上是一种“批量等待”机制：你一次性把一批fd告诉内核，然后阻塞等待，内核把其中任何一个fd的就绪状态汇报给你。

Linux下有三个典型实现，族谱关系很清楚：

select最原始，用三个fd_set位图分别表示读、写、异常事件，每次调用都要把整个位图从用户空间拷贝到内核空间，内核逐一遍历全部fd检查状态。两个明显问题：fd数量上限1024（FD_SETSIZE），以及每次都全量扫描+全量拷贝，连接数一多性能断崖下跌。

poll解决了上限问题，用pollfd动态数组替代位图，不再受1024限制。但每次调用依然要全量拷贝用户态到内核态，依然全量遍历扫描，所以复杂度依然是O(n)。对几千个连接还够用，到了几万、几十万就不行了。

epoll则完全是另一套思路，详细拆解见下一章。它把“维护关注列表”和“等待就绪事件”两件事解耦，靠内核事件回调机制实现真正意义上的可扩展。这也是C10K、C100K问题的经典答案。

2.5 异步I/O（Asynchronous I/O）

最后是异步I/O。前面说过，阻塞、非阻塞、多路复用都是同步的，因为数据从内核拷贝到用户空间的那一步，都得你的线程来做。而异步I/O模型里，你发起aio_read之后立刻返回，整个等待数据、拷贝数据的过程全由内核完成，完成之后内核通过信号、回调或事件通知你“数据已经在你的buffer里了”。

Linux的异步I/O演进分两条线：

• 老牌的POSIX AIO（libaio）：只对设置了O_DIRECT标志的文件I/O支持较好，网络I/O上支持一直不完整，实际用得少。
• 新一代io_uring：从内核5.1开始引入，通过共享内存环形队列在用户态和内核态之间高效交换请求与完成事件，配合liburing使用非常顺手。它不只支持网络I/O，磁盘I/O同样支持，是目前Linux异步I/O的绝对主流方向。

重要提示：io_uring的API层比较新，生产环境使用前先确认内核版本（5.1以上才能编译，建议5.10以上），还要确认云主机的内核是否支持、容器是否有限制。我见过有人在内核4.15的老机器上编io_uring程序，编完了直接系统调用失败，白折腾一晚上。

3. epoll登场：多路复用中的绝对主力

3.1 select/poll的痛点与epoll的破局

为什么epoll能成为高并发服务的标配？因为它从三个层面解决了select/poll的结构性问题。

第一个问题：全量拷贝与全量遍历。select和poll每次调用都让用户把完整fd列表搬进内核，内核再线性扫描全部fd。假设你管理10000个连接，活跃的只有10个，select依然要为10000个fd付出完整代价。而epoll只需要注册一次（epoll_ctl），内核把关注的fd存下来，之后你调用epoll_wait时，内核只要把“就绪链表”上的fd返回给你就行。代价与连接总数无关，只与活跃连接数有关。这是质的区别。

第二个问题：事件回调机制。select/poll是“主动查询”，每次都要问一遍所有fd“你好了吗”；epoll是“被动通知”——每个被监控的fd上挂了一个回调函数，数据到达时，协议栈触发回调，内核把对应的fd直接加入就绪链表。注意，这一设计让epoll复杂度稳定在O(1)，因为就绪事件到来时插入链表是O(1)，用户取走就绪事件时也不用扫描无关fd。

第三个问题：fd生命周期管理。select/poll把fd数组单纯看成位图/数组，内核不关心fd什么时候关闭了。epoll内部用红黑树维护所有fd的注册信息，配合一个“等待队列”管理阻塞在epoll_wait上的线程。fd关闭时，内核会检查它是否在红黑树中注册过，自动做清理，避免悬垂指针——这个细节在长期运行的服务里非常重要，省掉了一类极难排查的use-after-free崩溃。

3.2 Level-trigger与Edge-trigger的差异

这是epoll最容易被忽略、一忽略就在线上踩坑的点。

• 水平触发（LT，Level-Triggered）：只要fd还有数据没读完，每次epoll_wait都会返回这个fd。这是epoll的默认模式，写起来最省心——你不用担心漏掉数据，没读完下次继续读就行。
• 边缘触发（ET，Edge-Triggered）：只有当fd状态从“无数据”变为“有数据”的那一刻，epoll_wait才返回一次该fd。如果这次没把数据读完，剩余数据会一直躺在缓冲区里，但内核不会再通知你，直到下一次有新数据到达——新数据会再次触发“边缘变化”，你才有机会把残留数据一起读完。

ET模式的高明之处在于减少系统调用次数：LT模式下，如果缓冲区一直有数据，epoll_wait会不断地返回同一个fd，每次你都要想办法把它读完，结果往往在最后一小块数据上反复唤醒；ET模式下，一次通知对应“一轮数据到来”，逼着你把缓冲区一口气读干净，效率更高。

但ET模式对代码要求非常苛刻：

• socket必须设为非阻塞，否则读最后一点数据时recvfrom会卡死你的事件循环；
• 必须用循环一直读到返回EAGAIN，才算把这波数据彻底处理完；
• 必须处理好部分读、半包、粘包等问题，容易引入bug。

我的建议是：新手先老老实实用LT，把业务逻辑跑通，再考虑ET优化。Redis、Nginx都使用ET模型是因为它们的事件循环足够复杂、对性能锱铢必较，而你写的业务服务往往瓶颈根本不在这一层，先追求正确，再追求快。

3.3 epoll的调用接口与数据结构

epoll核心就三个系统调用：

// 创建epoll实例，返回epoll专用的fd int epollfd = epoll_create1(0); // 注册/修改/删除被监听的fd int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event); // 等待事件发生 int epoll_wait(int epfd, struct epoll_event *events, int maxevents, int timeout);

epoll_event结构体长这样：

struct epoll_event { uint32_t events; // EPOLLIN / EPOLLOUT / EPOLLERR / EPOLLET / EPOLLONESHOT ... epoll_data_t data; // 是一个联合体，常用 data.fd 或 data.ptr }; typedef union epoll_data { void *ptr; int fd; uint32_t u32; uint64_t u64; } epoll_data_t;

内核维护的关键结构主要有三块：

• eventpoll：epoll实例的根结构，包含一棵红黑树rbr、一个就绪链表rdllist、一个等待队列wq；
• epitem：每个被注册fd对应的节点，以红黑树节点的形式挂在这棵树上，保证插入、删除、查找都是O(log n)；
• ep_pqueue：fd就绪后回调入口，把对应epitem挂到就绪链表尾部。

用红黑树存注册关系，是因为你需要快速判断“这个fd有没有被注册”“注册信息在哪”。线性表就做不到高效。这个细节面试时可以提一嘴，瞬间跟背八股的人拉开差距。

4. epoll实战：从代码到配置的一次到位

4.1 一个可复现的epoll服务端示例

这里给一个最小但完整的epoll服务端程序骨架，保留了核心逻辑，你照着写就能跑通。

#include <stdio.h> #include <stdlib.h> #include <string.h> #include <unistd.h> #include <errno.h> #include <sys/epoll.h> #include <sys/socket.h> #include <netinet/in.h> #include <fcntl.h> #include <arpa/inet.h> #define MAX_EVENTS 64 #define PORT 9000 static int set_nonblock(int fd) { int flags = fcntl(fd, F_GETFL, 0); if (flags == -1) return -1; return fcntl(fd, F_SETFL, flags | O_NONBLOCK); } int main() { int listen_fd = socket(AF_INET, SOCK_STREAM, 0); if (listen_fd < 0) { perror("socket"); return 1; } int reuse = 1; setsockopt(listen_fd, SOL_SOCKET, SO_REUSEADDR, &reuse, sizeof(reuse)); struct sockaddr_in addr; memset(&addr, 0, sizeof(addr)); addr.sin_family = AF_INET; addr.sin_addr.s_addr = INADDR_ANY; addr.sin_port = htons(PORT); if (bind(listen_fd, (struct sockaddr *)&addr, sizeof(addr)) < 0) { perror("bind"); return 1; } if (listen(listen_fd, 128) < 0) { perror("listen"); return 1; } int epfd = epoll_create1(0); if (epfd < 0) { perror("epoll_create1"); return 1; } set_nonblock(listen_fd); struct epoll_event ev; ev.events = EPOLLIN; // 默认LT模式，新手先别加EPOLLET ev.data.fd = listen_fd; epoll_ctl(epfd, EPOLL_CTL_ADD, listen_fd, &ev); struct epoll_event events[MAX_EVENTS]; while (1) { int n = epoll_wait(epfd, events, MAX_EVENTS, -1); if (n < 0) { if (errno == EINTR) continue; perror("epoll_wait"); break; } for (int i = 0; i < n; i++) { int fd = events[i].data.fd; if (fd == listen_fd) { // 处理新连接 struct sockaddr_in client_addr; socklen_t client_len = sizeof(client_addr); int conn_fd = accept(listen_fd, (struct sockaddr *)&client_addr, &client_len); if (conn_fd < 0) { if (errno != EAGAIN && errno != EINTR) perror("accept"); continue; } set_nonblock(conn_fd); ev.events = EPOLLIN; ev.data.fd = conn_fd; epoll_ctl(epfd, EPOLL_CTL_ADD, conn_fd, &ev); } else { // 处理客户端数据 char buf[1024]; ssize_t rn; while ((rn = read(fd, buf, sizeof(buf))) > 0) { // 这里简单回显，实际业务中解析协议、分发给工作线程等 write(fd, buf, rn); } if (rn == 0) { // 对端关闭 epoll_ctl(epfd, EPOLL_CTL_DEL, fd, NULL); close(fd); } else if (rn < 0 && errno != EAGAIN) { epoll_ctl(epfd, EPOLL_CTL_DEL, fd, NULL); close(fd); } } } } close(epfd); close(listen_fd); return 0; }

这个示例有几个刻意设计的细节，我说说用意：

• SO_REUSEADDR必须设置。否则服务端重启时会因为TIME_WAIT状态的连接而bind失败，报Address already in use。看我开头说的线上排查，一半“服务起不来”的问题都能追到这儿。
• accept之后立即把连接fd设为非阻塞。即使你用LT模式，这个习惯也值得保留——万一某次数据量巨大，读循环卡在最后一次read上，事件循环就废了。
• epoll_wait处理EINTR中断。信号来了会打断阻塞，不处理会让服务被信号搞得莫名退出。很多新手服务“跑一会儿就挂了”，其实是被SIGCHLD或定时器信号打断又没重试。

4.2 LT模式与ET模式的代码差异对比

把上面代码从LT切到ET，只改一处远远不够。我曾经给同事review代码，他说“我加了EPOLLET就完事了”，结果压测时大量连接卡住，就是这个原因。ET模式的正确读法：

// 正确写法：循环读直到EAGAIN while (1) { ssize_t rn = read(fd, buf, sizeof(buf)); if (rn > 0) { process(buf, rn); } else if (rn == 0) { // 对端关闭 close(fd); break; } else { if (errno == EAGAIN) { break; // 数据读完了，退出 } // 其他错误 close(fd); break; } }

如果用LT模式，上面这种循环也可以，但如果某次只读了缓冲区现有数据、后面还有数据再来，epoll_wait会再次返回这个fd，所以LT模式下即使一次只读一个包也不会漏数据。这是LT对新手最友好的地方：不需要追求每次把缓冲区读空，内核会反复提醒你。

ET模式下，内核只在“无数据→有数据”的瞬间提醒你一次。如果你这次只读了一小块，剩下的数据只能等下次新包到达才会再次触发。靠“等下一个包再带出旧数据”这种事，一旦流量模型不满足，就是永久坑。

4.3 几组容易搞混的系统参数

生产环境调优时，这几个参数经常被问到，也经常被背错：

注意，tcp_tw_reuse只对主动连接方（客户端）生效，服务端大量TIME_WAIT靠它解决不了问题，正确方向是应用层协议设计（减少服务端主动关闭），或者开启SO_LINGER、把长连接做足。这个理解误区，我见过不止三个运维踩过。

5. 行业场景选型与常见问题排查

5.1 Redis、Nginx如何选型

聊理论不谈落地就是空中楼阁。看几个真实产品的选择，你对I/O模型的理解会立刻立体起来。

Redis：单线程事件循环，核心就是epoll（在Linux上）。它用ET模式，配合非阻塞socket，在事件循环里一次性把所有可读数据读进内存。所以Redis能做到单线程支撑十万级QPS，本质不是它运算多快，而是它几乎没有I/O等待开销——CPU一直在做有用的事。

Nginx：master进程管理worker，每个worker进程跑一个epoll事件循环，用ET模式处理连接。多worker之间通过accept_mutex互斥锁解决“惊群”问题——即多个进程同时被epoll唤醒，但只有一个连接要accept，其余白醒。后来Linux 4.5引入了SO_REUSEPORT，多个进程可以各自bind同一个端口，由内核做负载均衡，Nginx也支持了这个模式。

Netty/Java的Selector：Java NIO在Linux上底层就是用epoll实现的，但Java的Selector.select()默认“只通知一次”的语义，对应到epoll就是LT模式，所以Netty做了很多优化来模拟ET行为。这说明一个坑：框架封装过的I/O模型，和纯系统调用的语义之间，存在各种抽象损耗和语义偏差，排查问题时要分清你是在跟框架打交道还是跟内核打交道。

5.2 新手常犯的三个典型错误

错误一：用阻塞socket注册到epoll。有些教程没强调这点，导致新人在事件循环里用阻塞socket读数据。如果是LT模式，通常还能勉强工作；但如果正好加到EPOLLET，这个fd一旦没读完，后续数据再也不会触发事件，连接僵死。正确做法见上面代码，accept后马上set_nonblock。

错误二：忽视epoll_ctl失败。epoll_ctl返回-1时，很多人不看errno继续跑。最常见的错误是EEXIST——同一个fd重复添加，ENOENT——fd没注册就删除或修改。这两种错误在连接复用、fd被关闭重开时极容易出现。我建议每个epoll_ctl调用后都打日志，哪怕只打一次，上线后能救回无数排查时间。

错误三：把事件当成数据。EPOLLIN事件并不代表“一次完整的数据包”，也不代表“一个完整的业务请求”。TCP是字节流，没有消息边界。你必须自己做缓冲区和分包处理。否则高并发下，一次事件可能只读到半个包，解读逻辑直接错乱。这个问题在epoll出现前就有，但epoll的高效反而让更多人踩到——因为事件获取太容易，大家下意识忽略了协议处理。

5.3 高频面试题与追问实战

这里把面试里常见的几个问题列出来，同时给出应对追问的深度答案。

问：select和epoll的区别？

基础答法：select轮询、有上限、效率低；epoll回调通知、无上限、效率高。深度答法：select每次将fd集合从用户态拷贝内核态遍历，复杂度O(n)；epoll通过注册时红黑树存储、事件就绪时回调挂链表、epoll_wait只返回就绪链表，复杂度O(就绪数)。然后再补一句“LT和ET模式下，epoll通知策略也不同，ET更适合高性能场景但要求非阻塞+循环读”。

问：epoll是不是异步I/O？

这是考察你是否真懂概念的区别。答案：不是。epoll本质上仍是同步I/O，它只是让你在“等待多个fd就绪”这件事上高效了，但数据从内核拷贝到用户空间的操作，必须由你调read/recvfrom线程自己完成。真正的异步I/O要等io_uring这类机制，发起后由内核完成全部拷贝并通知你。

问：为什么Redis用单线程还那么快？

答案核心是：Redis的性能瓶颈不在CPU，而在网络I/O和内存操作。单线程避免了锁竞争、避免上下文切换开销，配合epoll事件循环，CPU绝大多数时间都在处理业务而不是等待。加上Redis操作都是内存级微秒延迟，单线程完全够用。这个问题的“为什么”回答好了，说明你对I/O模型的理解不是背出来的。

问：线上服务连接数很多但CPU飙升，怎么排查？

先把止损做完，再一步步来：先看是不是有大规模轮询代码在忙等（比如把非阻塞socket放在while(1)里手动轮询）；再看select是否在管理大量fd，如果是，换poll或epoll；再看是否频繁创建/销毁线程，线程切换开销是否主要矛盾；最后看是否触发大量软中断（网络包过多导致ksoftirqd占CPU）。按这个顺序，绝大多数“高并发CPU飙升”能定位到具体原因。

5.4 故障案例：一次典型的epoll连接泄漏

分享一个我实际排过的问题，非常典型。

现象：一个网关服务运行两天后，响应越来越慢，最后几乎无响应。ss -s一看，连接数两万多，但业务侧看每秒请求量并不高。top里进程CPU不高，但epoll_wait返回的事件数激增。

排查路径：先怀疑是不是有人恶意连接不关闭。抓到客户端IP后确认，有些是正常业务连接，没有异常。再看服务端代码，发现一个隐蔽问题——accept新连接后，某个分支在业务异常时直接continue，没有把新连接fd加入epoll，也没有close它。fd泄漏了，每次异常就漏一个。两天时间积了两万多个文件描述符，进程fd数逼近ulimit -n上限，注意：fd耗尽时，accept并不会立刻报错，而是慢慢开始失败，最终服务假死。

解决方法是：给所有新连接建立路径加上统一收口，异常分支也要保证close(fd)；同时给进程设置ulimit -n监控告警，fd使用率超过70%就通知。这类问题的根源不是epoll设计缺陷，而是错误处理路径不谨慎。写网络服务时，每条路径都要想到fd的归宿，这句话值得刻在工位上。

最后分享一点我的习惯

这几个模型其实不是并列选择题，而是层层递进的工程演进。我日常写服务时，默认技术栈就是“非阻塞socket + epoll(LT) + 显式缓冲区管理”，只有确认某条路径热到需要用ET极致优化时，才会切换边缘触发。优先正确，其次优雅，最后才拼极限性能。

再分享一个调试小技巧：写完epoll服务后，用strace -p <pid>看看系统调用序列。如果能看到频繁的epoll_wait返回空事件后立刻重入，说明你的事件循环空转严重；如果看到大量EAGAIN，说明非阻塞读写得没问题。观察epoll_ctl的调用频率和fd数量增长，也能快速判定连接管理是否正确。这套观测方法，不需要额外装任何工具，最适合初学者培养对I/O模型的感觉。