fopen+fread+fwrite复制大文件慢因php用户态缓冲导致高频系统调用和内存拷贝；应优先用copy()走内核零拷贝，或用stream_copy_to_stream并显式设缓冲区。
为什么 fopen + fread + fwrite 复制大文件特别慢
因为默认用 PHP 用户态缓冲逐块读写，每读 8KB 就调一次系统调用，中间还夹着 PHP 的内存拷贝和编码检测。对 100MB 文件，可能触发上万次 read() 和 write() 系统调用，CPU 花在上下文切换上比实际搬运数据还多。
- 别用
fopen/fread循环手动复制 —— 即使把$chunk_size调到 1MB，也绕不开 PHP 层的额外开销 - 优先走内核级零拷贝路径：
copy()函数底层直接调sendfile(2)（Linux）或CopyFile()（Windows），不经过 PHP 内存 - 注意
copy()不支持跨文件系统硬链接或特殊挂载点（如某些 NFS 或 overlayfs），失败时会静默回退到用户态复制，但不会报错 - 如果目标路径是远程 URL（如
ftp://），copy()依然慢，此时必须换curl或流封装器优化
stream_copy_to_stream 比 copy() 快还是慢
取决于流类型。对本地文件句柄，它和 copy() 底层调用几乎一样；但对 HTTP、FTP、压缩流等，它更可控，能避免临时文件和重复解码。
- 用前确保两个流都已打开且可读写：
$src = fopen('large.zip', 'rb');，$dst = fopen('out.zip', 'wb'); - 显式设置缓冲区大小比依赖默认值更稳：
stream_copy_to_stream($src, $dst, -1, 2 * 1024 * 1024)（最后参数是最大字节数，设为-1表示不限，但建议指定，防内存溢出） - 若源流是
php://input或加密流（如crypt://），stream_copy_to_stream可能因不支持 seek 而提前终止，需配合stream_get_contents()分段处理 - PHP 8.1+ 对
stream_copy_to_stream做了 memcpy 优化，老版本（
调整 output_buffering 对文件复制完全没用
这个配置只影响 echo、print 等输出到 Web 客户端的内容，和 fwrite() 写文件、copy() 拷贝磁盘文件完全无关。改它既不提速也不减内存占用。
- 别在
php.ini里折腾output_buffering = 4096来“优化复制”——这是常见误解 - 真正影响文件 I/O 性能的是系统级参数：
/proc/sys/vm/dirty_ratio（Linux）、磁盘 I/O 调度器（如deadlinevsmq-deadline），但这些不属于 PHP 配置范畴 - 如果复制卡在
fclose()，可能是文件系统 sync 延迟，加fflush($fp); fsync($fp);强制刷盘，但会拖慢整体速度，仅在数据一致性要求极高时用
小文件批量复制反而更容易出问题
单个 copy() 很快，但循环 1000 次调用，PHP 解析函数名、检查权限、打开/关闭文件描述符的开销会累积成瓶颈，尤其在 ext4 + xattr 或 SELinux 环境下。
立即学习“PHP免费学习笔记（深入）”；
- 合并操作：用
tar命令打包再解包（exec('tar -cf - files/ | tar -xf - -C /dest')），绕过 PHP 文件系统抽象层 - 禁用 stat 检查：确保
opcache.enable_file_override=1且脚本没被频繁重载，否则每次copy()都会重新 stat 源文件 - 注意 umask 和 ACL 继承：
copy()不保留源文件的扩展属性（xattr）、SELinux 上下文、ACL 权限，批量时容易漏掉权限修复步骤
复制不是拼 PHP 函数调用次数，而是看数据有没有真正走最短路径进磁盘。很多人卡在“以为调得够深就快”，其实关键在选对系统原语，再小心绕开那些看不见的元数据陷阱。
