Nginx Worker 处理大文件下载依赖事件驱动、零拷贝与分时让权：启用sendfile on实现内核态直传，配合sendfile_max_chunk 1m控制单次传输量，aio threads与directio 4m异步卸载磁盘I/O，tcp_nopush on合并TCP包，limit_rate限速保障调度公平，并须关闭gzip、sub_filter等破坏零拷贝的配置。
Nginx 的 Worker Process 处理大文件下载时，并不是“直接读完再发”，而是靠事件驱动 + 零拷贝 + 分时让权来实现高效、不阻塞的传输。关键在于避免同步 I/O 占满整个 Worker 的 CPU 时间片和磁盘带宽，否则会卡住其他请求（比如健康检查、API 轮询），造成调度掉帧甚至上游丢包。
核心机制是：让 Worker 在传输中“喘口气”，把控制权交还给事件循环
-
sendfile on是基础：启用内核级零拷贝，跳过用户态内存拷贝，大幅降低 CPU 和内存开销 -
sendfile_max_chunk 1m是节奏控制器：强制每次最多搬运 1MB 数据，完成后立即返回事件循环，处理其他就绪事件（如新连接、定时器、其他请求） -
aio threads+directio 4m是磁盘卸载器：当文件不在 page cache（冷文件）时，用独立线程异步读盘，主线程不等待 -
limit_rate 2m是资源节制阀：防止单个下载吃尽网卡或磁盘吞吐，为轮询、心跳等短时敏感请求留出调度窗口 -
tcp_nopush on是 TCP 整合器：配合 sendfile，攒够一个 MSS 再发包，减少小包数量和协议栈压力
必须关掉干扰项，否则 sendfile 失效
-
gzip off（压缩必须在用户态做，破坏零拷贝） - 下载 location 中禁用
sub_filter、add_header（动态改响应体 → 回退到 read/write） -
proxy_buffering on（反向代理场景下，不能off；否则无法利用缓存和分片优化）
Worker 数量本身不是瓶颈，但配置不当会放大问题
- 不建议盲目设为 CPU 核心数的 2 倍（除非实测 SSL 或 gzip 成为瓶颈）
- 更关键的是：每个 Worker 要能“公平分时”，而不是靠堆进程数硬扛
- 若大量并发大文件下载，优先调优单个 Worker 的 I/O 行为，再考虑是否增加 worker_processes（通常 4–8 足够，配合
worker_cpu_affinity绑核）
验证是否真正生效，不能只看配置
-
strace -e trace=sendfile64 -p $(pgrep -f "nginx: worker")看是否真走 sendfile64 系统调用 -
nginx_stub_status中Writing值长期稳定在 2–5，说明写事件调度健康 - 日志里
status=206占比高（>95%），说明 range 请求被有效分片与缓存，没退化成整文件拉取
本质上，Nginx 的 Worker 不是“下载进程”，而是“调度+传输协作者”。它不追求单次下载最快，而是确保所有请求——无论大小、长短、轻重——都能按时获得服务窗口。
