Windows 下 sendfile 是伪开关，不触发零拷贝，完全退化为 read()+write() 模式；因系统无等效内核接口且 Nginx 未集成 TransmitFile，所有静态文件仍经历 4 次拷贝与上下文切换。
Windows 下的 Nginx sendfile 实际上是**不可用的伪开关**，它不会触发真正的零拷贝路径，也不会带来任何性能提升。
Windows 不支持 sendfile 系统调用
Linux 的 sendfile() 是内核原生系统调用，依赖 page cache + DMA 直传机制；而 Windows 内核没有等效的、被 Nginx 官方适配的零拷贝接口。Nginx for Windows 在编译时已禁用该能力，即使你写 sendfile on;，运行时也完全忽略——它既不报错，也不生效，只是安静地退回到传统 read() + write() 模式。
这意味着：
- 所有静态文件传输仍需经过用户态缓冲区，发生完整 4 次内存拷贝和 4 次上下文切换
-
tcp_nopush在 Windows 下失去协同意义，因无 sendfile 数据可“攒包” -
sendfile_max_chunk配置无效，不会被读取或应用
为什么 Windows 无法实现零拷贝
根本原因在于操作系统设计差异：
- Windows 的文件 I/O 和网络栈分离较深，缺乏类似 Linux
sendfile()或splice()的跨子系统内核直通机制 - 虽有
TransmitFile()API（支持文件句柄到 socket 的高效发送），但 Nginx 官方从未在 Windows 版本中集成对其的调用逻辑 - NTFS 缓存行为、I/O 完成端口（IOCP）调度模型与 page cache 零拷贝路径不兼容
Windows 下替代优化方向
既然 sendfile 形同虚设，应转向 Windows 友好的实际优化点：
-
启用
tcp_nodelay on;：避免 Nagle 算法延迟小包发送，对 API 和首屏资源更友好 -
调大
worker_connections：Windows 使用 IOCP 模型，高并发下比 epoll 更稳定，可设为 8192 或更高 -
用
open_file_cache缓存句柄：减少频繁CreateFile开销，尤其适合大量小文件场景 -
静态压缩走
gzip_static on;：预生成.gz文件后，Nginx 仍可直接read()返回，避免运行时压缩开销
如何确认 sendfile 在 Windows 下未工作
无需复杂追踪——只需检查两点：
- 用
nginx -t或查看 error.log，不会出现 sendfile 相关警告，但也不会记录启用成功 - 用 Process Monitor（Sysinternals 工具）监控 nginx worker 进程，会持续看到
ReadFile+WSASend调用，却**绝不会出现TransmitFile或任何零拷贝语义调用**
换句话说：Windows 下的 sendfile on; 就像一个贴了标签的空盒子——配置写了，但里面什么也没有。
