sendfile 的核心价值是零拷贝减负，通过内核直接搬运数据省去用户空间中转，降低 CPU 占用 15%–30%、减少系统调用与内存拷贝；必须配合 tcp_nopush on 才能合并 TCP 包，且需设置 sendfile_max_chunk 512k～1m 防大文件阻塞 worker。
sendfile 不是“提升并发数”的直接手段，而是通过减少单次静态文件响应的系统开销，间接释放资源、支撑更高并发。它真正起作用的地方，是在高流量下降低 CPU 占用、减少上下文切换和内存拷贝，让每个 worker 进程能更稳定地维持大量连接。
sendfile 的核心价值：零拷贝减负
传统文件传输需经历两次数据拷贝（磁盘→用户空间→内核网络缓冲区），而 sendfile 让内核直接在文件系统缓存和 socket 缓冲区之间搬运数据，省去用户空间中转。这对图片、JS、CSS 等静态资源尤其明显：
- CPU 使用率下降 15%–30%，尤其在大文件或高频小文件请求场景
- 内存带宽压力减小，避免因频繁拷贝引发的内存瓶颈
- 系统调用次数减少，单个请求处理延迟更平稳
必须配合的 TCP 优化项
sendfile 单独开启效果有限，需与 tcp_nopush 协同才能发挥最大效能：
- tcp_nopush on：让 Nginx 在启用 sendfile 后，等 TCP 包填满 MSS 再发送，减少小包数量和网络往返
- 避免同时开启 tcp_nodelay on（除非业务强依赖实时性）：它会禁用 Nagle 算法，与 tcp_nopush 目标冲突
- 二者组合后，典型静态资源响应的 TCP 报文数可减少 40% 以上
合理设置 sendfile_max_chunk 防阻塞
对超大文件（如视频、安装包），不加限制的 sendfile 可能长期占用 worker 进程，影响其他请求调度：
- 建议设置 sendfile_max_chunk 512k 或 1m，分块传输而非一次性加载
- 该值不宜过大（如设为 100m），否则单个大文件可能阻塞整个 worker 连接队列
- 搭配 client_body_timeout 和 send_timeout 使用，防止慢速客户端拖垮连接
验证是否生效的简单方法
无需复杂工具，靠日志和基础指标就能初步判断：
- 检查 nginx -t 配置语法后 reload，再执行 ss -s | grep "inuse"，对比开启前后 established 连接下 CPU 负载变化
- 访问一个静态文件（如 /logo.png），用 curl -I 查看响应头，确认无 Transfer-Encoding: chunked（sendfile 启用时通常为 Content-Length + 直接传输）
- 在高并发压测中观察 nginx stub_status 的 Active connections 和 Reading/Writing 数值波动是否更平滑
