在 Linux 后端开发面试中，epoll 几乎是绕不开的话题。面试官通常会先问你 epoll 和 select/poll 的区别，然后紧接着追问一句：“水平触发和边缘触发有什么区别？实际项目中你怎么选？”很多人能背出定义，却在“怎么选”这个问题上卡壳。这篇文章就从原理到实战，把 LT 和 ET 的选择逻辑彻底讲清楚。
先搞清楚 LT 和 ET 的本质区别
epoll 有两种事件触发模式：
水平触发（Level Triggered，LT）：只要文件描述符上还有未处理的数据，epoll_wait 就会持续通知你。换句话说，它关心的是“缓冲区里有没有数据”这个状态。
边缘触发（Edge Triggered，ET）：只有当文件描述符的状态发生变化时（比如从无数据变为有数据），epoll_wait 才会通知你一次。之后如果你没把数据读完，它也不会再通知，直到下一次新数据到达。
用一个类比来理解：LT 就像一个一直响的闹钟，你不按掉它就一直响；ET 则像门铃，按一次响一次，你开不开门它不管，下次有人来才会再响。
一个关键细节：ET 必须配合非阻塞 IO
这是面试中的高频考点。使用 ET 模式时，你必须一次性把数据读干净，否则剩余数据不会再触发事件，导致连接“饿死”。而要做到“读干净”，就必须循环 read，直到返回 EAGAIN 或 EWOULDBLOCK。
这就带来一个问题：如果文件描述符是阻塞的，最后一次 read 会卡住整个线程。所以 ET 模式下文件描述符必须设置为非阻塞。LT 模式则没有这个强制要求，阻塞和非阻塞都能工作。
// ET 模式下的标准读法
while (1) {
ssize_t n = read(fd, buf, sizeof(buf));
if (n == -1) {
if (errno == EAGAIN || errno == EWOULDBLOCK) {
break; // 数据读完了
}
// 真正的错误
break;
} else if (n == 0) {
// 对端关闭
break;
}
// 处理数据
}
性能差异：ET 真的更快吗？
很多人认为 ET 比 LT 快，理由是“通知次数少”。这个说法对，但不完整。
LT 的问题在于：如果数据没读完，每次 epoll_wait 都会返回这个 fd，造成大量重复的系统调用和事件分发开销。在高并发场景下，这种“惊群式”的重复通知会浪费 CPU。
ET 的优势在于：每个事件只通知一次，减少了 epoll_wait 的返回次数和事件拷贝开销。但代价是应用层必须写更复杂的循环读取逻辑，而且一旦漏读就会出 bug。
实际测试中，两者的性能差距并没有想象中那么大。在连接数极高、活跃连接比例低的场景下，ET 的优势更明显；在连接数适中、逻辑简单的场景下，LT 完全够用。
实际项目到底怎么选？
这才是面试官真正想听的。答案不是“ET 更高级所以选 ET”，而是要根据场景权衡。
优先选 LT 的场景：
- 业务逻辑复杂，读事件和写事件处理耦合度高，难以保证一次读干净
- 团队经验不足，LT 的容错性更好，漏读不会导致连接挂死
- 使用成熟的网络库（如 libevent 默认 LT），没必要自己造轮子
- 连接数不大，性能瓶颈不在 epoll 通知上
考虑选 ET 的场景：
- 高并发网关、代理服务器，连接数动辄几十万，需要榨干每一分性能
- 应用层能严格控制读写循环，保证 EAGAIN 才退出
- 使用 Redis、Nginx 这类已经验证过的 ET 实现作为参考
- 对延迟敏感，希望减少不必要的事件分发
一个常见的误区是：小项目也强行上 ET，结果因为没处理好 EAGAIN 导致偶发的连接卡死，排查半天。LT 是默认的安全选择，ET 是性能优化手段，不是必选项。
面试中的加分回答
如果面试官追问“Redis 和 Nginx 为什么用 ET”，你可以这样回答：
Redis 的单线程 Reactor 模型下，ET 能减少 epoll_wait 的返回次数，让单线程处理更多连接；Nginx 的 worker 进程同样采用 ET，配合非阻塞 IO 和完整的读写循环，在高并发下表现优异。但它们的共同点是：都有严格的读写循环和错误处理机制，这是用 ET 的前提。
反过来，如果你说“我们项目用 LT，因为逻辑简单、容错好、性能也够”，这同样是一个成熟的工程判断，不会减分。
总结
LT 和 ET 没有绝对优劣，只有适不适合。LT 是“状态驱动”，简单可靠；ET 是“事件驱动”，高效但要求高。面试时不要只背定义，要能说出：ET 必须配非阻塞、必须循环读到 EAGAIN、漏读会挂连接；选型时要看并发规模、团队能力和业务复杂度。能把这几点讲清楚，这道题就稳了。
未经允许不得转载：任鹏个人博客 » Linux 面试中 epoll 的水平触发与边缘触发到底怎么选
