sendfile比readfile快的根本原因是绕过PHP用户态缓冲和多次内存拷贝，直接内核零拷贝推送至TCP发送缓冲区，降低CPU占用40%+、减轻内存带宽压力、提升延迟稳定性。
sendfile为什么比readfile快？
根本原因是绕过了 PHP 用户态缓冲和多次内存拷贝。readfile() 或 fread() 循环必须把文件内容从内核页缓存读到 PHP 的用户内存，再经 Swoole 缓冲区写入 socket；而 sendfile() 直接让内核把文件页缓存“零拷贝”推送到 TCP 发送缓冲区，不经过用户空间。
这带来三个实际好处：
- CPU 占用下降 40%+（尤其在 10MB+ 文件、100+ 并发时）
- 内存带宽压力显著降低，避免大文件下载触发 GC 频繁或 OOM
- 延迟更稳定，不受 PHP 内存分配碎片影响
sendfile配置项哪些真正起作用？
buffer_output_size 对 sendfile() 完全无效 —— 这是关键盲点。只要调用了 $response->sendfile($path)，整个流程就跳过 Swoole 的用户态响应缓冲，直接走内核 sendfile(2) 系统调用。
真正需要关注的只有：
-
open_tcp_nodelay => true：禁用 Nagle 算法，避免小包合并导致首字节延迟（对断点续传尤其重要） -
tcp_keepalive => true：防止长连接空闲超时断开，影响大文件分段传输 - 文件系统挂载选项：
noatime（避免每次访问更新 atime，减少磁盘 IO）
sendfile失败的常见原因和排查路径
失败时不报错，只静默返回 404 或空响应，容易误判为路由问题。
Swoole 6.1.1
下载
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
典型失败场景：
- 文件权限不足：Swoole worker 进程用户（如
www-data）无法open()目标文件（注意 SELinux 上下文，ls -Z $path可查） - 路径含符号链接但未启用
enable_static_handler的 symlink 支持（sendfile()不自动解析软链） - 文件被其他进程独占打开（如 Windows 下某编辑器锁定，或 Linux 下
flock()持有写锁） - 文件大小超过
fs.file-max或进程级ulimit -n，导致无法创建新 fd（sendfile内部需 open 文件）
验证是否真走 sendfile：用 strace -p $(pgrep -f 'server.php') -e trace=sendfile64 抓系统调用，看到非 0 返回即成功。
断点续传依赖 sendfile 的哪些行为？
$response->sendfile($path, $offset, $length) 是唯一可靠支持断点续传的方式，底层自动处理：
- 解析
Range请求头（无需手动$_SERVER['HTTP_RANGE']） - 设置
206 Partial Content状态码 - 生成正确的
Content-Range和Accept-Ranges: bytes头
但要注意两个硬限制：
-
$offset必须对齐文件系统块大小（通常 4KB），否则可能触发 EINVAL 错误 - 不能和
$response->write()混用：调用sendfile()前不能已写入任何响应体，否则会报 “cannot sendfile after write”
真正容易被忽略的是：断点续传响应体长度必须严格等于 $length，哪怕文件末尾不足，也要用 truncate() 或临时截取，否则浏览器会校验失败并重试。
