sendfile 是 nginx 提升静态资源传输性能的关键机制，需同时启用 sendfile on;、tcp_nopush on; 且 tcp_nodelay off;，并避开 gzip、代理、不支持的文件系统等退化场景，配合 gzip_static 和 open_file_cache 等调优才能充分发挥零拷贝效能。
sendfile 是 Nginx 提升静态资源传输性能的关键机制，它通过内核态零拷贝大幅降低 CPU 和内存开销，但真正起效依赖于完整配置与规避退化条件。
确保 sendfile 路径畅通
仅写 sendfile on; 不足以触发优化。必须同时满足三项基础配置：
- 启用 sendfile on;（默认已开启，但仍需显式确认）
- 搭配 tcp_nopush on;，让响应头与文件数据合并发送，减少小包数量
- 保持 tcp_nodelay off;（即不启用），避免破坏 tcp_nopush 的攒包逻辑
避开常见失效场景
即使配置正确，以下情况会让 Nginx 自动回退到传统 read/write 模式，彻底绕过 sendfile：
- 启用了 gzip on; —— 运行时压缩必须进入用户态，直接中断零拷贝路径
- 使用了代理指令（如 proxy_pass、fastcgi_pass）或内容改写（如 sub_filter）
- 静态文件位于 NFSv3、CIFS 或某些容器卷挂载点等不支持 sendfile 的文件系统上
- 请求带 Range 头（如视频拖拽），或启用 gzip_static 但对应 .gz 文件缺失
用 gzip_static 替代运行时压缩
想兼顾压缩收益又不牺牲 sendfile，应将压缩前置到构建阶段：
- 启用 gzip_static on;，Nginx 会自动查找并返回同名 .gz 文件
- 明确设置 gzip off;，彻底禁用运行时压缩模块
- 确认 Nginx 编译时包含 ngx_http_gzip_static_module，否则配置报错
- 确保 mime.types 中已声明对应类型（如 application/javascript），否则 .gz 不被识别
配套调优增强整体效率
sendfile 是性能基线，还需收敛其他干扰因素才能释放全部潜力：
- 在静态 location 中关闭日志：access_log off;，避免高并发 I/O 成瓶颈
- 启用文件句柄缓存：open_file_cache max=10000 inactive=60s;，减少重复 open/stat
- 对大文件（如 mp4、zip）可加 sendfile_max_chunk 512k;，防止单次传输阻塞事件循环
- 用前缀匹配替代正则 location（如 location /img/ 而非 location ~* \.png$），降低 PCRE 开销
