sendfile 不是“开启就加速”的开关，而是需与tcp_nopush on、tcp_nodelay off成对启用，并避开gzip、代理、动态头、非本地文件等退化条件，才能实现内核零拷贝；单独配置无效，且仅对真实静态文件生效。
sendfile 不是“开启就加速”的开关，而是让 Nginx 绕过用户态、由内核直接把磁盘文件推送到网络连接的机制。它真正起效的前提是一整套协同配置和运行环境约束，缺一不可。
核心配置必须成对启用
单独打开 sendfile on 没有意义，必须与 tcp_nopush on 配合，并确保 tcp_nodelay 处于 off 状态：
- sendfile on;：激活内核级文件直送能力，跳过用户空间缓冲
- tcp_nopush on;：依赖 sendfile 路径，将响应头与文件数据合并进尽可能少的 TCP 报文段，减少小包
- tcp_nodelay off;：避免禁用 Nagle 算法，否则会破坏 tcp_nopush 的攒包逻辑
哪些情况会让零拷贝自动失效
即使配置全对，只要出现以下任一情形，Nginx 就会悄悄退回到 read()+write() 模式，失去零拷贝优势：
- 启用了 gzip on、gunzip on 或 gzip_static on（但 .gz 文件缺失时也会 fallback）
- 使用了 proxy_pass、fastcgi_pass、scgi_pass 等代理指令
- 配置了 sub_filter、add_before_body、etag、expires 等需动态处理响应头或内容的功能
- 文件位于 NFSv3、CIFS、FUSE 或某些容器存储驱动挂载点（不支持 sendfile() 系统调用）
- 响应未带 Content-Length（如 chunked 编码或动态生成内容）
按资源类型做 location 级精准控制
不建议在全局 http 块盲目开启所有功能，应针对不同静态资源特性分别配置：
- 图片类：location ~* \.(jpg|jpeg|png|webp|gif|avif|svg)$ 中启用 sendfile + tcp_nopush，同时关闭 gzip
- 大文件类：location ~ \.(mp4|zip|iso|tar\.gz|dmg)$ 可加 sendfile_max_chunk 512k，防止单次传输阻塞事件循环
- 已压缩资源：用 gzip_static on 替代 gzip on，配合预生成的 .gz 文件，仍可走 sendfile 路径
验证是否真实生效
不能只看配置是否加载成功，要确认运行时行为：
- 用 strace -p $(pgrep nginx) -e trace=sendfile64 观察 worker 进程是否持续调用 sendfile64 系统调用
- 对比开启前后高并发请求下的 CPU 使用率（尤其是 sy 系统态占比）和 QPS 变化
- 检查错误日志中是否有 sendfile() failed 类报错，提示文件系统或权限问题
