ET模式下必须使用非阻塞socket，否则recv在缓冲区变空后会阻塞，导致线程卡死且epoll不再通知；listenfd须用LT避免丢连接，cfd推荐ET并循环读写至EAGAIN。
ET模式下必须用非阻塞socket，否则会卡死
边缘触发只在状态变化时通知一次，比如接收缓冲区从空变为非空。如果 socket 是阻塞的，recv 在读完当前数据后、缓冲区变空时会挂起，后续新数据到来前整个线程就卡住了——而 epoll 不会再通知你，因为状态没变（仍是“空→非空”之后的“非空”状态）。这直接导致连接假死。
所以 ET 模式下必须提前调用 fcntl(fd, F_SETFL, O_NONBLOCK) 设置非阻塞。实操建议：
- 所有注册到 epoll 的 fd（包括
listenfd和已连接的cfd）都应设为非阻塞 -
accept也要用非阻塞方式循环调用，直到返回-1且errno == EAGAIN或EWOULDBLOCK -
recv/send必须循环处理，直到返回-1并检查errno是否为EAGAIN或EWOULDBLOCK
LT模式可以容忍单次读写不完整，但容易引发高频唤醒
水平触发只要缓冲区有数据就持续返回 EPOLLIN，哪怕你只读了 1 字节，下次 epoll_wait 还会立刻返回。这对初学者友好，但代价是：当一个连接持续有小包到达（如 HTTP/1.1 keep-alive 场景），epoll 可能每毫秒都唤醒一次，CPU 花费大量时间在系统调用和上下文切换上。
常见错误现象：strace -e epoll_wait,read,write ./server 会看到 epoll_wait 频繁返回 1，但实际业务处理很轻。这不是 bug，而是 LT 的固有行为。
性能影响取决于场景：
- 连接数少、单连接吞吐高（如文件传输）→ LT 开销可忽略
- 连接数多、单连接交互频繁（如 IM、HTTP 短连接）→ LT 明显比 ET 多 20%~50% 的
epoll_wait调用次数 - 使用
EPOLLET后，同样负载下epoll_wait返回次数通常减少 60% 以上
ET模式下漏读数据是静默故障，调试困难
ET 模式不会提醒你“还有数据没读完”。比如客户端发了 8KB，你只 recv 了 4KB 就停了，剩余 4KB 会一直留在内核接收缓冲区，直到对端再发新数据（触发下一次上升沿）或连接关闭。中间这段时间，你的程序完全感知不到那 4KB 的存在。
这种问题在测试环境很难暴露——只有压测时出现偶发粘包、超时或协议解析失败才可能被发现。排查路径通常是：
- 先确认 socket 确实设为非阻塞
- 检查
recv是否循环到EAGAIN才退出 - 用
ss -i查看对应连接的rcv_rtt和rcv_space，若rcv_space长期远小于窗口大小，说明数据堆积在缓冲区没被读走
listenfd 必须用 LT，否则可能丢连接
监听套接字的就绪条件是“完成连接队列不为空”，但内核只维护一个固定长度的队列（由 listen() 的 backlog 参数决定）。ET 模式下，如果一次 accept 没把队列清空，后续新连接到达时不会再次触发 EPOLLIN——因为队列状态始终是“非空”，没有新的“边沿”。
结果就是：高并发瞬间建立大量连接时，LT 模式下你能反复 accept 直到队列空；ET 模式下可能只处理第一个，其余连接被丢弃（表现为客户端 connect 超时或 RST）。
所以正确做法是：
-
listenfd始终用EPOLLIN（默认 LT），不要加EPOLLET - 所有
cfd可以按需选择 LT 或 ET，但推荐统一用 ET 提升吞吐 - 如果混用，注意
epoll_ctl修改事件时要显式带上原 flag，比如从 LT 切 ET 需传EPOLLIN | EPOLLET，不能只传EPOLLET
真正难的是边界控制：ET 要求你对每个 fd 的 I/O 状态有精确把握，而 LT 把状态管理交给了内核。选哪种不是看文档里的“高性能”标签，而是看你能不能守住“每次读写都必须耗尽缓冲区”这条线。
