sendfile 是 Nginx 静态资源服务的性能基线，启用后数据在内核态直传（磁盘→内核缓冲区→网卡），仅需2次拷贝和2次上下文切换；若开启 gzip、etag、Range 请求、NFS 文件或 gzip_static 缺失，则退化为低效 read/write 模式。
sendfile 是 Nginx 静态资源服务的性能基线，不是可有可无的优化项，而是决定数据传输路径是否高效的核心开关。它启用后让文件从磁盘直通网卡，全程在内核态完成，绕过用户空间搬运，大幅降低 CPU 消耗和延迟。
为什么 sendfile 能显著提升性能
传统 read()+write() 方式需 4 次数据拷贝（磁盘→内核缓冲区→用户空间→socket 缓冲区→网卡）和 4 次上下文切换，CPU 大量耗费在内存搬运上。启用 sendfile 后，仅需 2 次拷贝（磁盘→内核缓冲区→网卡）和 2 次上下文切换。Linux 2.4+ 还支持 SG-DMA，可进一步跳过内核缓冲区到 socket 的拷贝，实现更接近“零拷贝”的效果。
哪些情况会让 sendfile 实际失效
即使配置了 sendfile on，以下场景仍会强制回退到低效的 read/write 模式：
- 开启 gzip on：运行时压缩必须进入用户态，破坏零拷贝路径
- 使用 etag 或 expires：需动态计算响应头，触发用户态介入
- 客户端发起 Range 请求（如视频拖拽）：Nginx 需切片处理，无法整文件直传
- 静态文件存于 NFS、CIFS 等不支持 sendfile 的远程文件系统
- gzip_static on 但对应 .gz 文件缺失：Nginx fallback 到原始文件读取或运行时压缩
如何确保 sendfile 始终生效
单开 sendfile 不够，必须协同配置堵住退化漏洞：
- 用 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 系统调用
- 若输出大量 sendfile(…) 成功返回，则路径畅通；若几乎无输出或频繁出现 read/write，则已退化
