sendfile 是静态资源服务的底层通路开关，启用后将数据传输路径从4次拷贝+4次上下文切换简化为2次拷贝+2次上下文切换，大幅提升性能；但需配合 gzip_off、tcp_nopush on、open_file_cache 等配置并避开 gzip、etag、range 请求等退化场景才能真正生效。
sendfile 指令不是性能“加分项”，而是静态资源服务的底层通路开关。它直接决定数据是否走内核态直传路径，进而影响 CPU 占用、延迟和并发承载能力。
sendfile 如何改变数据传输路径
不启用时，Nginx 必须用 read() + write() 完成文件发送，数据在磁盘、内核缓冲区、用户空间、Socket 缓冲区之间来回搬运：共 4 次拷贝 + 4 次上下文切换，CPU 大量消耗在搬数据上。
启用后，调用内核原生 sendfile() 系统调用，路径简化为：磁盘 → 内核缓冲区 → Socket 缓冲区 → 网卡。仅需 2 次拷贝 + 2 次上下文切换。Linux 2.4+ 还支持 SG-DMA，可跳过内核缓冲区到 Socket 的拷贝，实现更彻底的零拷贝。
哪些配置会让 sendfile 实际失效
即使写了 sendfile on;，以下情况也会强制退化回低效路径：
- 启用了 gzip on：运行时压缩必须进用户态，破坏零拷贝
- 使用了 etag 或 expires：需动态计算响应头，触发用户态介入
- 客户端发起 Range 请求（如视频拖拽）：Nginx 需切片处理，无法整块直传
- 静态文件存于 NFS/CIFS 等不支持 sendfile 的远程文件系统
- gzip_static on 但对应 .gz 文件缺失：fallback 到运行时压缩或原始读取
确保 sendfile 始终生效的关键协同配置
单开 sendfile on 不够，必须堵住退化漏洞：
- 用 gzip_static on 替代 gzip on：提前生成 .gz 文件（如 app.js.gz），Nginx 直接返回，仍走 sendfile 路径
- 显式关闭运行时压缩：gzip off，避免模块干扰
- 搭配 tcp_nopush on：等 sendfile 数据攒满 TCP 包再发，减少小包数量
- 启用 open_file_cache：缓存文件句柄和元数据，避免高并发下频繁 open/stat 触发用户态操作
验证 sendfile 是否真实工作
不能只看配置，要观察实际行为：
- 用 strace -p $(pgrep nginx) -e trace=sendfile 跟踪 worker 进程
- 持续看到 sendfile 系统调用被调用，说明路径畅通
- 若大量出现 read/write 调用，则已退化，需排查上述失效原因
