Swoole HTTP Server中$_FILES为空，因绕过PHP SAPI层，需手动解析multipart数据；文件数据存于内存字节流，生命周期与请求一致；推荐流式解析+协程写入处理大文件。
Swoole HTTP 服务器（Swoole\Http\Server）本身不走 PHP 原生的 $_FILES 和临时文件机制，因此没有传统 PHP-FPM 下那种由 SAPI 解析 multipart/form-data、自动写入 upload_tmp_dir、再填充 $_FILES 的流程。换句话说：在纯 Swoole HTTP Server 中，$_FILES 始终为空，move_uploaded_file() 无法直接使用。
为什么 Swoole 不用 $_FILES？
因为 Swoole 是常驻内存的异步服务器，它绕过了 PHP 的 CGI/FPM SAPI 层，不触发 PHP 内置的文件上传解析逻辑。HTTP 请求体作为原始字节流交给 onRequest 回调，需开发者自行解析 multipart 数据 —— 这意味着：
- 没有自动创建临时文件
- 没有
upload_max_filesize、post_max_size等 ini 配置生效 - 没有
$_FILES数组，也没有move_uploaded_file()可依赖的上下文
那文件数据存在哪？生命周期怎么算？
在 onRequest 回调中接收到的请求体（$request->rawContent() 或通过 multipart 解析器逐块读取），其内容始终是内存中的字节流，生命周期与该次请求完全一致：
- 请求开始 → 数据逐步接收并暂存在 Worker 进程内存缓冲区
- 请求处理中 → 可用协程文件 I/O（如
Swoole\Coroutine\FileSystem::writeFile）边收边存，或全量加载后解析 - 请求结束 → 所有局部变量、临时解析对象、未显式保存的原始数据自动销毁
⚠️ 注意：若在解析过程中将文件内容写入磁盘（例如用 file_put_contents 或协程写入），那个磁盘文件的生命周期就由你控制；但 Swoole 本身不生成、不管理任何“临时文件”。
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
如何安全高效地处理大文件上传？
推荐采用流式解析 + 协程写入，避免内存爆炸：
- 使用
multipart-parser类库（如swoole/multipart-parser）分块提取文件字段 - 对每个
file字段，用Swoole\Coroutine\FileSystem::open创建句柄，配合write持续追加 - 设置合理的
package_max_length（默认 2MB）防止单包过大 - 在
onRequest中校验文件大小、类型、扩展名，拒绝非法上传
示例关键逻辑：
if ($request->server['request_method'] === 'POST' && $request->header['content-type'] ?? '' =~ '/multipart\/form-data/') {$parser = new MultipartParser($request->header['content-type']);
$parser->onFile = function ($fileInfo) {
$fp = \Swoole\Coroutine\FileSystem::open('uploads/' . uniqid(), 'wb');
// 分块写入 $fileInfo['stream']
};
$parser->parse($request->rawContent());
}
如果非要兼容 $_FILES 怎么办？
可通过中间层模拟，例如：
- 使用
hyperf/http-message或psr7-swoole将 Swoole Request 转为 PSR-7 对象 - 再借助
nyholm/psr7-server等工具解析 multipart 并构建UploadedFile实例 - 此时“临时文件”是你手动
fopen(..., 'temp')或tmpfile()创建的，生命周期由你显式fclose或脚本结束时释放
但这类模拟会带来额外开销和内存占用，高并发下不推荐作为主力方案。
