应在大文件 location 块中配置 sendfile_max_chunk，需与 sendfile on、tcp_nopush on、gzip off 同时启用；典型值为 512k 至 1m，兼顾响应性与吞吐，避免设为 0 或过高导致 worker 阻塞。
直接在需要处理大文件的 location 块中设置，必须搭配 sendfile on 才生效，不能写在 http 或 server 全局块里起作用。
只在真正用到的地方启用
避免全局配置，精准控制大文件路径，比如下载、视频、镜像等目录：
-
location ^~ /download/ { ... }——^~确保前缀匹配优先，不被正则覆盖 -
location ~* \.(mp4|avi|iso|pkg)$ { ... }—— 按后缀匹配动态资源 - 不要在
/api/或/static/js/这类小文件路径下配，反而增加开销
典型值参考与取舍逻辑
数值不是越大越好，核心目标是让 worker 每次传输后能及时响应其他事件：
- 512k（524288）：高并发 + 小请求混合场景（如网页带下载按钮），响应更灵敏
- 1m（1048576）：通用推荐值，吞吐与调度平衡，适合多数 CDN 边缘或下载站
- 256k（262144）：对延迟极其敏感，或存在大量并发大文件请求时可尝试
- 避免低于 64k（系统调用太频繁，抵消零拷贝优势）
- 避免高于 4m（单次仍可能阻塞几十毫秒，失去“分段让渡”意义）
必须同步配置的关键项
单独设 sendfile_max_chunk 几乎无效，以下三项需同时存在：
-
sendfile on;—— 基础前提，缺一则参数不触发 -
gzip off;—— 压缩必须在用户态做，和 sendfile 内核零拷贝互斥；开启 gzip 会自动禁用 sendfile -
tcp_nopush on;—— 配合 sendfile 把数据攒满 TCP 包再发，提升网络效率，不冲突反而增强分块效果
可选但强烈建议的增强配置
针对超大文件（>1GB）或机械盘环境，进一步卸载 I/O 压力：
-
aio threads;—— 启用线程池异步读取，避免同步 read() 阻塞 worker -
directio 4m;—— 文件大于 4MB 时绕过页缓存，减少内存拷贝，尤其适合大文件直传 -
limit_rate 2m;—— 应用层限速，防止单连接吃光带宽，和 sendfile_max_chunk 目标不同（后者管调度，前者管速率）
