Nginx的非阻塞IO是API网关运行底座而非加速器，依托epoll/kqueue实现单worker万级并发，需配合worker_processes auto、worker_connections 10240、multi_accept on及合理超时与buffer策略协同优化。
Nginx 的非阻塞 IO 不是 API 网关性能的“加速器”，而是它的运行底座——它不加快单次请求，但让网关在万级并发下依然保持低延迟、稳吞吐、少抖动。
让单 worker 同时扛住成千上万个 API 连接
传统网关每处理一个连接就开一个线程，API 请求一多，线程调度和内存开销就迅速拖垮系统。Nginx 用 epoll（Linux）或 kqueue（BSD）监听所有 socket，连接空闲时不占 CPU，只在数据就绪时才介入。一个 worker 进程轻松维持 10240+ 并发连接，4 核服务器配 4 个 worker 就能支撑 4 万+ 活跃 API 连接，且内存占用可控（主要消耗在连接结构体和请求池，而非线程栈）。
- 确保 worker_processes auto; 自动匹配 CPU 核心数
- worker_connections 设为 8192 或 10240，同时检查系统 ulimit -n ≥ 该值
- 开启 multi_accept on;，允许一次事件批量接收多个新连接，减少唤醒次数
避免慢客户端拖垮整个网关
API 调用中常有移动端弱网、长轮询或大文件上传场景。非阻塞 IO 让 Nginx 不会因某个客户端发包慢而卡住——recv() 立即返回 EAGAIN，连接挂起，转头处理其他就绪请求。只要配合合理的超时控制，就能隔离异常连接，保障其余请求正常流转。
- client_header_timeout 15s; 和 client_body_timeout 60s; 防止恶意或故障客户端长期占用连接槽位
- 上传类 API 可适当放宽 client_body_timeout，但必须设 client_max_body_size 与业务实际匹配，避免小文件反复落盘
- 对 JWT 或 Cookie 较大的登录接口，若日志频繁出现 400 错误，调大 large_client_header_buffers 4 8k;
缓冲策略必须贴合 API 流量特征
非阻塞 IO 的效率高度依赖缓冲区是否“刚刚好”：太小触发频繁磁盘写入，太大浪费内存并增加首次分配延迟。API 多为短小 JSON 请求，缓冲应精简、确定、可预测。
- 标准 REST 接口：client_header_buffer_size 1k;、client_body_buffer_size 8k; 足够覆盖 95% 以上请求
- 反向代理后端微服务时：proxy_buffer_size 12k;（存响应头）、proxy_buffers 8 16k;（存响应体），避免 upstream 分块返回时因缓冲不足导致同步等待
- 纯透传或流式响应（如 SSE、gRPC-Web）：proxy_buffering off; 关闭缓冲，配合 sendfile off; 和 tcp_nodelay on; 减少小包延迟
协同系统参数，堵住性能断点
非阻塞 IO 发挥作用的前提，是整个链路没有隐性阻塞点。哪怕内核收包快，若应用层或网络栈卡住，照样拉高延迟。
- 启用 sendfile on; + tcp_nopush on; 提升静态资源或小响应体传输效率
- 关闭 access_log 或改用 buffer+flush，QPS 过万时可显著降低 I/O 延迟
- 避免在 Lua 脚本中做阻塞操作（如同步 DNS 查询、文件读写），改用 cosocket 或异步 resolver
- 反向代理下游务必复用 keepalive 连接：proxy_http_version 1.1; + proxy_set_header Connection ''; + keepalive 32;
