企业官网建设流程全解析

1. 这不是概念辨析，而是生产环境里必须踩过的坑

“Epoll水平触发（Level Triggered）和边缘触发（Edge Triggered）区别”——这句话在面试题库、技术博客标题栏里反复出现，但绝大多数人只记住了“LT是只要就绪就通知，ET是只在状态变化时通知”这句教科书定义。我带过三届后端开发新人，在某次压测故障复盘会上，一个线上服务在高并发下CPU飙到95%，连接堆积却无日志报错，最后定位到epoll_wait()调用逻辑里混用了LT语义写法去处理ET模式的fd。那一刻我才意识到：这不是理论选择题，而是Linux I/O多路复用底层机制与应用层代码契约的一次硬性对齐。LT和ET根本不是“两种可选模式”，而是两套完全不同的编程范式——LT像老式电铃，门一开就一直响；ET像智能门禁，只在门从关到开那一瞬间滴一声。你用按电铃的方式去等门禁提示，永远等不到下一次响声。本文不讲源码注释，不画状态转换图，只说我在某高并发消息网关、某实时风控引擎、某自研RPC框架中真实踩过的7个坑、3种必须配套的缓冲区策略、2类不可绕过的系统调用组合，以及为什么你在用libevent/libuv时其实早已被封装层替你做了关键决策。如果你正在写网络库、调试连接超时、优化单机QPS，或者刚被面试官问懵了“ET为什么必须配合非阻塞IO”，请把这篇文章当操作手册来读。

2. 核心设计逻辑：为什么Linux要硬生生拆出两种触发模式？

2.1 LT模式的本质：状态轮询的友好封装

LT模式的设计哲学非常朴素：让应用层代码尽可能接近传统阻塞I/O的思维惯性。它的核心契约是——只要内核缓冲区有数据可读（或有空间可写），epoll_wait()就一定会返回该fd。这意味着你哪怕只读了一半数据，下次调用epoll_wait()时它还会立刻再次通知你。这种“懒人模式”极大降低了初学者的入门门槛。我最早写的TCP回显服务器就是LT模式，代码结构清晰得像伪代码：

// LT典型写法：一次读不完？没关系，下次还通知你 while (1) { int nfds = epoll_wait(epoll_fd, events, MAX_EVENTS, -1); for (int i = 0; i < nfds; i++) { if (events[i].data.fd == listen_fd) { // 处理新连接 } else { // 处理已连接fd ssize_t n = read(events[i].data.fd, buf, sizeof(buf)-1); if (n > 0) { // 只读了1024字节，但缓冲区还有200字节？ // 没关系，下次epoll_wait()还会返回这个fd write(events[i].data.fd, buf, n); } else if (n == 0) { close(events[i].data.fd); } } } }

这种写法的底层支撑是内核对每个就绪fd的状态快照机制。每次epoll_wait()返回前，内核会扫描所有注册fd的socket接收队列长度、发送队列剩余空间等指标，只要满足就绪条件（如sk_receive_queue不为空），就将其加入就绪链表。这就带来一个隐含成本：LT模式下epoll_wait()的返回时间与当前就绪fd总数强相关。当你的服务同时维持10万个连接，其中9.9万个处于半关闭状态但接收队列仍有残留数据时，每次epoll_wait()都要遍历全部10万项做状态判断——这就是为什么某些LT模式服务在连接数暴涨时出现“epoll_wait延迟突增”的根本原因。某次我们做长连接推送服务压测，连接数从5万升到8万，平均延迟从12ms跳到47ms，最终发现是LT模式下内核态遍历开销呈线性增长。

2.2 ET模式的底层动机：为百万级连接而生的减法设计

ET模式诞生于2004年Linux 2.6.12内核，直接动因是解决C10K问题向C100K/C1M演进时的性能瓶颈。它的设计哲学是彻底反直觉的：内核只保证在文件描述符状态发生“跃变”时通知一次，之后无论状态是否持续就绪，都不会重复通知。所谓“跃变”，特指从“不可读”到“可读”、从“不可写”到“可写”、从“无错误”到“有错误”这三个瞬时事件。这个设计砍掉了LT模式中最耗时的“全量状态扫描”环节，转而采用更轻量的事件标记+单次投递机制。内核只需维护一个“状态变更标记位”，当socket接收队列从空变为非空时，置位并投递事件；之后即使队列一直有数据，也不会再置位。

但这个性能红利是有严苛前提的：应用层必须一次性把所有可用数据读完，否则就会永久丢失后续通知。这直接导致ET模式强制要求两个配套措施：第一，fd必须设为非阻塞（O_NONBLOCK）；第二，必须使用循环读写直到返回EAGAIN/EWOULDBLOCK。我见过最典型的反模式是在ET模式下这样写：

// ❌ ET模式下的致命错误：只读一次就结束 ssize_t n = read(fd, buf, sizeof(buf)-1); if (n > 0) { process_data(buf, n); // 错误！如果内核缓冲区还有剩余数据， // 且没有再次触发epoll_wait()，这个fd将永远沉默 }

正确的ET处理必须是：

// ✅ ET标准写法：循环读取直到阻塞 while (1) { ssize_t n = read(fd, buf, sizeof(buf)-1); if (n > 0) { process_data(buf, n); } else if (n == 0) { // 对端关闭 close_connection(fd); break; } else { if (errno == EAGAIN || errno == EWOULDBLOCK) { // 缓冲区已空，本次处理完成 break; } else { // 真实错误 handle_error(fd); break; } } }

这个看似简单的while循环，背后是应用层主动承担了原本由内核代劳的状态跟踪职责。ET把“状态感知”的复杂度从内核下放到用户空间，换来的是epoll_wait()调用时近乎常数级的响应时间——无论你注册了1000个还是100万个fd，只要就绪事件只有3个，内核就只处理这3个标记位。某金融行情网关在切换ET模式后，epoll_wait()平均耗时从15μs降至0.8μs，这是LT模式永远无法达到的天花板。

2.3 为什么不能“混合使用”？一个被低估的系统级约束

很多开发者试图在同一个epoll实例中对不同fd设置不同触发模式（比如监听fd用LT，业务连接fd用ET），这是被内核明确禁止的。epoll_ctl()的EPOLL_CTL_ADD操作中，events字段的EPOLLET标志位是fd级别的属性，但epoll实例本身具有模式一致性约束。当你对一个已添加的fd执行EPOLL_CTL_MOD修改事件类型时，内核会校验新旧事件的ET/LT属性是否一致。若不一致，系统调用直接返回EINVAL错误。

这个限制的深层原因是内核数据结构的物理隔离。LT模式下，就绪fd存储在rdllist（ready list）中，每次epoll_wait()返回后不清空，下次继续扫描；ET模式下，就绪fd存入rbr（red-black tree）的就绪节点，一旦投递即从就绪集合移除。两种模式对应完全不同的内存布局和锁竞争模型。强行混合会导致内核无法统一管理就绪状态，可能引发竞态条件。我们在某次重构中曾尝试对HTTP短连接fd用LT（减少小包处理开销）、对WebSocket长连接fd用ET（提升吞吐），结果在高并发下出现epoll_wait()随机丢失事件的现象，最终确认是内核版本（2.6.32）对混合模式的支持存在未公开的bug。从此所有项目都严格遵循“单实例单模式”铁律。

3. 实操细节解析：从系统调用到缓冲区策略的完整链条

3.1 ET模式下非阻塞IO的不可替代性：不只是建议，而是生存法则

在ET模式中，将fd设为非阻塞（O_NONBLOCK）不是最佳实践，而是内核强制要求的生存条件。这里的关键在于read()/write()系统调用的行为差异。阻塞模式下，当socket接收缓冲区为空时，read()会挂起当前线程直至有数据到达；而非阻塞模式下，read()立即返回-1并置errno为EAGAIN。ET模式的“只通知一次”特性，决定了我们必须依赖EAGAIN作为“数据读尽”的信号。

我曾在一个实时音视频转发服务中犯过致命错误：为简化逻辑，对UDP socket保持阻塞模式，仅在epoll中启用ET。结果在弱网环境下，某个客户端突发大量丢包，服务端UDP接收缓冲区被填满后，recvfrom()调用开始阻塞。由于ET只在缓冲区从空到非空时通知一次，这次阻塞导致整个事件循环卡死——其他999个正常连接的事件再也无法被处理。排查时用strace看到进程卡在recvfrom()系统调用上，而epoll_wait()再无返回。解决方案极其简单：fcntl(fd, F_SETFL, O_NONBLOCK)一行代码，但代价是整晚的线上故障。

非阻塞IO带来的另一个连锁反应是应用层缓冲区管理策略的根本性重构。LT模式下，你可以依赖epoll的“温柔提醒”来分批处理数据；ET模式下，你必须预判单次read()能获取的最大数据量，并设计环形缓冲区（ring buffer）来应对突发流量。我们自研的物联网设备接入网关采用双缓冲区策略：主缓冲区（4KB）用于快速接收，溢出数据自动转入扩展缓冲区（64KB）。当read()返回EAGAIN时，主缓冲区数据送入协议解析器，扩展缓冲区则通过splice()系统调用零拷贝转发至下游。这种设计使单机处理能力从LT模式的12万TPS提升至28万TPS。

3.2 边缘触发的“边缘”究竟指什么？三次握手与四次挥手中的状态跃变

“边缘触发”中的“边缘”常被误解为网络包边界，实际它精确对应TCP状态机中的特定状态转换事件。理解这一点对调试连接异常至关重要。以TCP连接建立为例，LT模式下，当三次握手完成，socket进入ESTABLISHED状态时，epoll会通知；此后只要连接保持活跃，每次epoll_wait()都会返回该fd。而ET模式下，只有从SYN_RECV到ESTABLISHED的这一次状态跃变才会触发通知。这意味着：如果你在accept()后没有立即处理新连接，而是先去做其他耗时操作，这个新连接fd将永远不会被再次通知——除非它后续发生读写事件。

同样，在连接关闭阶段，ET模式只在FIN包到达导致socket从ESTABLISHED变为CLOSE_WAIT时通知一次。如果此时你没有调用read()读取剩余数据（触发EOF），这个fd就会滞留在CLOSE_WAIT状态，成为TIME_WAIT风暴的源头。某次我们发现服务端TIME_WAIT连接数暴增，用ss -s查看发现大量连接卡在CLOSE_WAIT。追踪代码发现，ET模式下对新连接的read()调用被放在了业务逻辑处理之后，而业务逻辑平均耗时80ms，期间对端已发送FIN包。由于ET只通知一次状态跃变，这个FIN事件被彻底错过，socket永远停在CLOSE_WAIT。

解决方案是严格遵循ET的“事件驱动即时处理”原则：在epoll_wait()返回新连接fd的瞬间，必须立即accept()并设置非阻塞，然后马上read()检查是否有初始数据。我们为此抽象出标准初始化模板：

// ET模式下新连接的标准处理流程 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 == EWOULDBLOCK) return; // 无新连接 else handle_accept_error(); } // 立即设置非阻塞 int flags = fcntl(conn_fd, F_GETFL, 0); fcntl(conn_fd, F_SETFL, flags | O_NONBLOCK); // 立即尝试读取，防止FIN丢失 char dummy[1]; ssize_t n = read(conn_fd, dummy, 1); if (n == 0) { // 对端已关闭，立即清理 close(conn_fd); return; } else if (n < 0 && (errno == EAGAIN || errno == EWOULDBLOCK)) { // 正常，等待后续读事件 } else if (n > 0) { // 有初始数据，放入接收缓冲区 append_to_buffer(conn_fd, dummy, n); }

这个模板现在是我们所有网络项目的准入检查项，任何违反都将被CI流水线拒绝合并。

3.3 写就绪事件的特殊陷阱：EPOLLOUT的“虚假唤醒”与流控反模式

EPOLLOUT事件在ET模式下存在一个极易被忽视的陷阱：它会在socket发送缓冲区有可用空间时立即触发，但这个“可用空间”可能远小于应用层期望发送的数据量。例如，TCP发送缓冲区默认128KB，当应用层要发送2MB文件时，第一次EPOLLOUT通知后，write()可能只成功写入16KB（受拥塞窗口限制），此时缓冲区仍有112KB空间，ET模式不会再次通知——因为“有空间”这个状态并未发生跃变（从无到有），只是空间量在减少。

更危险的是“虚假唤醒”：当socket刚创建或连接刚建立时，发送缓冲区默认是空的，但内核会立即触发一次EPOLLOUT事件（因为从“未连接”到“已连接”发生了状态跃变）。如果此时应用层未做连接状态校验就盲目write()，会触发SIGPIPE信号导致进程崩溃。我们在某RPC框架中就因此出现过批量core dump，日志显示write()返回-1且errno为EPIPE。

正确做法是：永远不要单独依赖EPOLLOUT事件来驱动发送，而应将发送逻辑与业务数据就绪状态解耦。我们采用“发送队列+就绪标记”双机制：

1. 所有待发送数据先进入环形发送队列；
2. 当队列非空且socket发送缓冲区有空间时，启动发送循环；
3. write()返回EAGAIN时，停止发送并等待下一次EPOLLOUT；
4. 连接建立后首次EPOLLOUT，必须先getsockopt()检查SO_ERROR确认连接成功。

// ET模式下安全的发送逻辑 void safe_send(int fd) { while (!send_queue_empty(fd)) { struct iovec iov[2]; int iovcnt = build_iovec(fd, iov); // 构建iovec数组 ssize_t n = writev(fd, iov, iovcnt); if (n > 0) { consume_from_queue(fd, n); } else if (n == 0) { // 对端关闭，清理 close_connection(fd); break; } else { if (errno == EAGAIN || errno == EWOULDBLOCK) { // 缓冲区满，等待EPOLLOUT enable_epollout(fd); // 重新注册EPOLLOUT break; } else if (errno == EPIPE || errno == ECONNRESET) { close_connection(fd); break; } else { handle_write_error(fd); break; } } } }

这个设计使我们的RPC框架在千兆网卡下达到98%的带宽利用率，而LT模式下因频繁EPOLLOUT通知导致的上下文切换开销使其峰值仅72%。

4. 完整实操流程：从零构建一个ET模式HTTP服务器

4.1 环境准备与基础配置：绕不开的内核参数调优

在动手写代码前，必须调整三个关键内核参数，否则ET模式的性能优势将大打折扣：

1. net.core.somaxconn：控制listen()的backlog上限。默认值128在高并发场景下会导致连接被内核丢弃。我们设为65535：

   echo 65535 > /proc/sys/net/core/somaxconn

2. net.ipv4.tcp_max_syn_backlog：SYN队列长度，需与somaxconn匹配：

   echo 65535 > /proc/sys/net/ipv4/tcp_max_syn_backlog

3. fs.file-max：系统级文件描述符上限。ET模式下每个连接至少占用2个fd（socket+epoll），10万连接需20万fd：

   echo 200000 > /proc/sys/fs/file-max

提示：这些参数需写入/etc/sysctl.conf永久生效，否则重启后失效。某次线上发布后连接成功率骤降，排查发现是容器环境未继承宿主机sysctl配置，导致somaxconn仍为128。

4.2 核心代码实现：137行完成ET模式HTTP服务骨架

以下是一个精简但生产可用的ET模式HTTP服务器核心（基于Linux 3.10+）：

#include <sys/epoll.h> #include <sys/socket.h> #include <netinet/in.h> #include <fcntl.h> #include <unistd.h> #include <string.h> #include <stdio.h> #include <stdlib.h> #define MAX_EVENTS 1024 #define BUFFER_SIZE 8192 struct connection { int fd; char recv_buf[BUFFER_SIZE]; size_t recv_len; char send_buf[BUFFER_SIZE]; size_t send_len; size_t send_off; }; int set_nonblocking(int fd) { int flags = fcntl(fd, F_GETFL, 0); return fcntl(fd, F_SETFL, flags | O_NONBLOCK); } int create_listen_socket(int port) { int sock = socket(AF_INET, SOCK_STREAM, 0); if (sock < 0) return -1; int opt = 1; setsockopt(sock, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt)); setsockopt(sock, IPPROTO_TCP, TCP_NODELAY, &opt, sizeof(opt)); 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(sock, (struct sockaddr*)&addr, sizeof(addr)) < 0) { close(sock); return -1; } if (listen(sock, 65535) < 0) { close(sock); return -1; } set_nonblocking(sock); return sock; } int main() { int listen_fd = create_listen_socket(8080); if (listen_fd < 0) { perror("create_listen_socket"); return 1; } int epoll_fd = epoll_create1(0); if (epoll_fd < 0) { perror("epoll_create1"); close(listen_fd); return 1; } // 注册监听fd，ET模式 struct epoll_event ev; ev.events = EPOLLIN | EPOLLET; ev.data.fd = listen_fd; if (epoll_ctl(epoll_fd, EPOLL_CTL_ADD, listen_fd, &ev) < 0) { perror("epoll_ctl listen_fd"); close(listen_fd); close(epoll_fd); return 1; } struct epoll_event events[MAX_EVENTS]; struct connection *conns = calloc(65535, sizeof(struct connection)); while (1) { int nfds = epoll_wait(epoll_fd, events, MAX_EVENTS, -1); if (nfds < 0) { if (errno == EINTR) continue; perror("epoll_wait"); break; } for (int i = 0; i < nfds; i++) { if (events[i].data.fd == listen_fd) { // 处理新连接 while (1) { 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 == EWOULDBLOCK) break; else { perror("accept"); break; } } set_nonblocking(conn_fd); conns[conn_fd].fd = conn_fd; // 注册新连接fd，ET模式 ev.events = EPOLLIN | EPOLLET; ev.data.fd = conn_fd; if (epoll_ctl(epoll_fd, EPOLL_CTL_ADD, conn_fd, &ev) < 0) { perror("epoll_ctl conn_fd"); close(conn_fd); continue; } } } else { // 处理已连接fd int fd = events[i].data.fd; if (events[i].events & EPOLLIN) { // 循环读取直到EAGAIN while (1) { ssize_t n = read(fd, conns[fd].recv_buf + conns[fd].recv_len, BUFFER_SIZE - conns[fd].recv_len); if (n > 0) { conns[fd].recv_len += n; // 简单HTTP解析：检测\r\n\r\n if (conns[fd].recv_len >= 4) { char *pos = memmem(conns[fd].recv_buf, conns[fd].recv_len, "\r\n\r\n", 4); if (pos) { // 构造HTTP响应 const char *resp = "HTTP/1.1 200 OK\r\nContent-Length: 12\r\n\r\nHello World!"; memcpy(conns[fd].send_buf, resp, strlen(resp)); conns[fd].send_len = strlen(resp); conns[fd].send_off = 0; // 启用写就绪监控 ev.events = EPOLLIN | EPOLLOUT | EPOLLET; ev.data.fd = fd; epoll_ctl(epoll_fd, EPOLL_CTL_MOD, fd, &ev); } } } else if (n == 0) { // 对端关闭 close(fd); conns[fd].fd = -1; break; } else { if (errno == EAGAIN || errno == EWOULDBLOCK) { break; // 读取完成 } else { perror("read"); close(fd); conns[fd].fd = -1; break; } } } } if (events[i].events & EPOLLOUT) { // 循环发送直到EAGAIN while (conns[fd].send_off < conns[fd].send_len) { ssize_t n = write(fd, conns[fd].send_buf + conns[fd].send_off, conns[fd].send_len - conns[fd].send_off); if (n > 0) { conns[fd].send_off += n; } else if (n < 0) { if (errno == EAGAIN || errno == EWOULDBLOCK) { break; // 缓冲区满 } else { perror("write"); close(fd); conns[fd].fd = -1; break; } } } if (conns[fd].send_off >= conns[fd].send_len) { // 发送完成，关闭连接 close(fd); conns[fd].fd = -1; } } } } } free(conns); close(listen_fd); close(epoll_fd); return 0; }

这段代码虽仅137行，但已包含ET模式所有关键要素：非阻塞设置、循环读写、EPOLLOUT安全启用、连接生命周期管理。编译命令：

gcc -o http_server http_server.c -O2

4.3 性能压测对比：LT vs ET的真实数据

我们使用wrk对同一台机器上的LT/ET版本进行压测（4核8G，千兆网卡）：

关键发现：当连接数超过1万时，LT模式因内核态遍历开销导致QPS不升反降，而ET模式保持线性增长。延迟方面，ET模式在高并发下优势更为明显——这正是ET设计的初衷：为海量连接而生。

注意：压测时务必关闭TCP延迟确认（echo 1 > /proc/sys/net/ipv4/tcp_delack_min），否则ET模式下小包延迟会因ACK延迟而失真。

5. 常见问题与实战排障：那些文档里不会写的血泪教训

5.1 “epoll_wait()永不返回”问题的三层排查法

当ET模式服务突然停止响应，epoll_wait()长时间阻塞，按以下顺序排查：

1. 检查fd是否真的就绪：用ss -i查看socket接收队列长度

   ss -i state established '( dport = :8080 )' | head -20

   如果rcv_rtt为0且rcv_space极小，说明对端未发数据或网络中断。

2. 验证fd是否被意外关闭：用lsof -p <pid>检查目标fd是否存在。ET模式下，若fd被其他线程close()，epoll实例不会自动移除，导致epoll_wait()永远等待一个已销毁的fd。

3. 确认事件注册是否正确：用cat /proc/<pid>/fdinfo/<fd>检查epoll注册详情：

   cat /proc/12345/fdinfo/3 # 查看flags字段是否含0x20000000（EPOLLET标志）

我们曾在线上遇到一个诡异问题：epoll_wait()在凌晨3点固定超时。最终发现是监控脚本每小时执行lsof导致文件描述符泄漏，第3次执行后耗尽了fd资源，新连接无法accept()，而旧连接因ET特性不再触发读事件。

5.2 ET模式下惊群效应的规避方案

在多进程模型中，多个worker进程共用一个epoll实例时，ET模式可能引发惊群效应：当一个新连接到达，所有worker的epoll_wait()同时返回，但只有一个能accept()成功，其余进程陷入忙等。解决方案是使用SO_REUSEPORT（Linux 3.9+）：

int opt = 1; setsockopt(listen_fd, SOL_SOCKET, SO_REUSEPORT, &opt, sizeof(opt));

开启后，内核在收到SYN包时直接哈希分发到某个worker，避免惊群。某CDN边缘节点采用此方案后，进程间锁竞争下降92%。

5.3 调试工具链：比strace更高效的ET模式诊断

针对ET模式的特殊性，我们构建了轻量级诊断工具集：

• epoll-trace：LD_PRELOAD劫持epoll_ctl()，记录每次事件注册/修改的fd和events
• fd-state-dump：定时dump/proc/<pid>/fdinfo/中所有epoll相关fd的状态
• buffer-peek：利用process_vm_readv()在运行时读取应用层接收缓冲区内容

这些工具帮助我们在某次SSL握手失败排查中，发现是ET模式下read()未处理SSL_ALERT消息，导致握手卡在SSL_read()阻塞。通过buffer-peek直接看到缓冲区中残留的alert帧，30分钟定位根因。

6. 工具选型与生态适配：别再自己造轮子了

6.1 libev/libuv的ET模式封装真相

大多数开发者认为libuv默认使用ET模式，这是严重误解。libuv在Linux上实际采用LT模式+边缘事件模拟的混合策略。其uv__io_poll()函数中，对每个就绪fd执行read()/write()时，会检查返回值是否为EAGAIN，若是则认为“事件已处理完毕”，不再重复通知——这本质上是用LT内核接口模拟ET语义。这种设计牺牲了纯ET的极致性能，但换取了跨平台一致性（Windows IOCP无ET概念）。

我们在某跨平台RPC框架中测试发现：libuv在Linux下的QPS比原生ET低18%，但在macOS上反而高12%（因为kqueue天然支持类似ET的EV_CLEAR语义）。因此，若服务仅部署在Linux，原生ET仍是首选；若需跨平台，libuv的兼容性收益大于性能损失。

6.2 生产环境推荐架构：ET模式的最佳实践组合

经过数十个项目的验证，我们总结出ET模式生产部署的黄金组合：

某支付网关采用此架构后，P99延迟稳定在8ms以内，GC暂停时间从LT模式的120ms降至7ms。

7. 最后的经验之谈：什么时候该坚持LT？

尽管ET模式性能卓越，但并非万能钥匙。根据我们的项目经验，以下场景强烈建议回归LT模式：

• 协议解析复杂且耗时：如XML/JSON深度解析，单次处理可能耗时50ms以上。ET模式下，这期间所有新事件都被阻塞，而LT模式允许分片处理。
• 需要精细流控：LT模式下可通过控制epoll_wait()超时时间实现软性限流；ET模式必须依赖应用层令牌桶，实现更复杂。
• 调试阶段：LT模式的“宽容性”让新手更容易发现逻辑错误，ET模式的“零容错”会掩盖底层问题。

我个人在做技术选型时，会用一个简单测试：写一个模拟10万连接的压测脚本，分别跑LT/ET，观察在连接数突增50%时，哪个模式的延迟抖动更小。过去三年，这个测试在7个项目中帮我们避开了4次线上事故。技术没有银弹，只有对场景的敬畏。