nginx在linux下固定使用epoll边缘触发（et）模式，不可配置为水平触发（lt）；这是由其事件驱动架构设计决定的——et强制一次性读写至eagain，提升i/o确定性与可控性，而非追求微小性能优势；源码硬编码启用epollet，所有socket设为非阻塞，recv/send/accept均内置循环处理逻辑。
Nginx 在 Linux 下固定使用 epoll 边缘触发（ET）模式，不提供切换为水平触发（LT）的配置选项。这不是性能权衡的结果，而是由其事件驱动架构的设计逻辑决定的——ET 强制一次性处理完就绪数据，让 I/O 行为更可预测、更可控。
ET 是硬编码行为，不是可调参数
Nginx 源码中直接启用 EPOLLET 标志，且未暴露任何开关供用户启用 LT。这意味着无论你的负载特征、硬件配置或业务场景如何，worker 进程始终运行在 ET 模式下。
- 所有 socket 均被设为非阻塞（
O_NONBLOCK），这是 ET 正常工作的前提 -
recv和send相关函数内部已实现循环读写逻辑，直到返回EAGAIN - accept 也采用循环处理，配合
accept_mutex防止惊群并确保新连接不被遗漏
LT 理论上可行，但 Nginx 不采用
虽然 epoll 默认支持 LT，且在简单场景下更容错，但它与 Nginx 的高并发设计目标存在隐性冲突：
- LT 会持续通知同一 fd，若缓冲区未清空，可能引发大量重复事件返回，增加内核到用户态的上下文切换开销
- 在万级连接、小包高频场景下，LT 可能导致
epoll_wait返回事件数膨胀，削弱单 worker 处理效率 - Nginx 已通过 ET + 非阻塞 + 循环 I/O 实现了足够健壮的吞吐能力，无需用 LT 换取开发便利性
真实瓶颈不在触发模式
实测表明，ET 与 LT 在相同配置下的 QPS 差异通常仅 1%~3%，远小于以下因素的影响：
- worker 进程数与 CPU 核心数是否匹配
- keepalive 超时、连接复用率及客户端行为
- SSL/TLS 卸载开销、磁盘 I/O 或后端服务延迟
- 系统级参数如
net.core.somaxconn、fs.file-max是否合理
你真正需要关注的替代点
既然无法切换触发模式，优化方向应落在 Nginx 如何与 ET 协同工作上：
- 确保
worker_connections设置足够，避免连接被拒绝而非事件漏处理 - 检查日志中是否频繁出现
recv() failed (11: Resource temporarily unavailable)，这是 ET 正常行为，非错误 - 避免在 Lua 或第三方模块中阻塞 I/O，否则会拖慢整个 event loop
- 大文件传输或长连接场景下，注意
client_body_timeout和send_timeout的实际影响
