sendfile 通过内核零拷贝避免用户态内存分配，保护 request 内存池稳定性；需配合 tcp_nopush、open_file_cache 等配置防退化，否则 Range 请求等场景将触发池外 malloc 导致内存失控。
sendfile 配置本身不直接操作 Nginx 内存池，但它通过绕过用户态内存分配路径，间接保护了 request 级内存池的稳定性与效率。
避免 request 池被大文件读取污染
当 sendfile 关闭时，Nginx 必须用 read() 把文件内容逐块读入用户空间 buffer（如 r->buffer），这些 buffer 通常从 request pool 分配。一个 10MB 的静态文件可能触发上百次小块分配，迅速耗尽池空间、触发扩容甚至 fallback 到 malloc —— 这不仅增加延迟，还让原本 O(1) 销毁的池失去确定性。
启用 sendfile 后，整个文件传输在内核完成，完全不申请 r->pool 内存。request pool 只用于解析请求头、处理变量等轻量任务（≤4KB），保持 bump-pointer 分配的纳秒级响应。
减少异步回调对池生命周期的干扰
sendfile 是纯内核路径，不涉及用户态回调（如 filter 模块、body 处理钩子）。而一旦退化为 read/write 模式，Nginx 就需注册读事件、拼接 chain、调用 output filter —— 这些过程常隐式依赖 r->pool 或误复用它，容易引发子请求访问已重置内存、定时器回调引用失效 buffer 等问题。
保持 sendfile 在线，等于压缩了用户态介入深度，让 request 生命周期更干净：解析完 header → 调用 sendfile → 请求结束 → 整池重置，逻辑闭环、无残留。
协同 tcp_nopush + open_file_cache，降低池外开销
sendfile 单独开启不够，还需配套配置来堵住“间接触发 malloc”的漏洞：
- tcp_nopush on：避免每 sendfile 一次就发一个小 TCP 包，减少 socket write 调用频次，也就减少了底层 buffer chain 的临时分配需求
- open_file_cache max=10000 inactive=60s：缓存 fd 和 stat 结果，防止高并发下反复 open() 触发系统调用和临时字符串分配（这些也走 r->pool）
- gzip_static on; gzip off：用预压缩文件替代运行时压缩，避免 deflate filter 在 r->pool 中分配压缩上下文和输出 buffer
注意退化场景对池机制的破坏
以下情况会让 sendfile 失效，Nginx 回退到 read/write 模式，进而激活大量非池内存操作：
- 客户端发起 Range 请求（如视频拖拽），需切片读取 → 触发用户态 buffer 分配
- 启用了 etag、expires 或其他需动态计算响应头的指令 → 强制进入 filter 链，分配 header buffer
- 静态文件放在 NFS/CIFS 上 → sendfile 不支持，自动 fallback 到 read
- gzip_static 找不到 .gz 文件，且 gzip on 开启 → 运行时压缩全程占用 r->pool
这些退化不是简单变慢，而是让原本受控的内存行为失控：chain 分配、临时字符串、filter 上下文全部跳出 bump-pointer 路径，引入锁、碎片和不可预测延迟。
