sendfile 是 Nginx 静态内容性能核心，需同时启用 sendfile on; 和 tcp_nopush on;，禁用 tcp_nodelay、gzip 及内容改写指令，并配合文件系统、缓存、CPU 绑定等优化确保零拷贝生效。
sendfile 是 Nginx 服务静态内容最核心的性能支点，它不是简单“打开一个开关”，而是触发 Linux 内核零拷贝路径的关键入口——数据从页缓存直接送入 socket 缓冲区，跳过用户态内存拷贝，大幅降低 CPU 和上下文切换开销。
确保 sendfile 路径畅通无阻
配置生效的前提是避免所有导致其退化的操作：
- 必须同时启用 sendfile on; 和 tcp_nopush on;，二者缺一不可
- 显式关闭 tcp_nodelay off;（注意：不是 on），否则会破坏 tcp_nopush 的攒包逻辑
- 彻底禁用运行时压缩：gzip off;，否则 Nginx 必须读取、压缩、再写入，强制回退到 read()+write() 模式
- 移除 location 中的 proxy_pass、sub_filter、add_before_body 等内容改写指令
- 静态文件需位于本地 ext4/XFS 文件系统，避开 NFSv3、FUSE 或容器挂载等不支持 sendfile 的存储后端
按资源类型精细化配置 location
全局开启不如按需启用，既保障性能又避免误伤：
- 小文件（CSS/JS/图标）：location ~* \.(css|js|png|jpg|webp|svg)$ { sendfile on; tcp_nopush on; tcp_nodelay off; gzip off; access_log off; }
- 大文件（视频/安装包）：location ~ \.(mp4|zip|iso|tar\.gz) { sendfile on; tcp_nopush on; tcp_nodelay off; sendfile_max_chunk 512k; expires 7d; }，其中 sendfile_max_chunk 防止单次传输阻塞事件循环
- 避免正则匹配 favicon.ico 或 robots.txt 等高频小资源，改用前缀匹配如 location = /favicon.ico { ... }，减少 PCRE 计算开销
配套缓存与系统协同提升稳定性
sendfile 依赖内核页缓存，而页缓存质量受元数据访问频率影响：
- 启用 open_file_cache max=10000 inactive=60s; 缓存文件句柄和 stat 结果，配合 open_file_cache_min_uses 2; 防止缓存污染
- 挂载静态文件分区时添加 noatime 选项，避免每次读取都触发磁盘写入
- worker 进程绑定物理 CPU 核心：worker_cpu_affinity 0001 0010 0100 1000;，提升 L1/L2 缓存命中率，稳定页缓存访问路径
- 对已压缩资源（如 JS/CSS），改用 gzip_static on; + gzip off;，让 Nginx 直接返回预生成的 .gz 文件，仍走 sendfile 路径
验证是否真实生效
不能只看配置是否存在，要观察实际行为：
- 用 strace -p $(pgrep nginx | head -1) -e trace=sendfile64，确认 worker 进程是否调用 sendfile64 系统调用
- 对比开启前后 pidstat -u 1 中 Nginx worker 的 CPU 使用率，大文件并发场景下应明显下降
- curl -I 请求一个静态资源，响应头中不应出现 Vary: Accept-Encoding 或 Content-Encoding: gzip（除非用了 gzip_static）
