swoole多进程模型中文件句柄不可跨worker复用，因各进程fd表隔离；正确做法是每个worker独立打开/关闭，或通过swoole\table存路径、redis/mysql协调、管道通信等方式间接共享数据。
在Swoole多进程模型中直接复用或跨Worker传递文件句柄（如fopen返回的resource、socket fd），会导致“句柄无效”“Bad file descriptor”错误，因为每个Worker进程拥有独立的文件描述符表，A进程打开的fd在B进程中根本不存在。
为什么不能跨进程使用文件句柄
PHP的文件句柄本质是操作系统分配给**当前进程**的整数索引（fd），Swoole Worker进程间内存与fd表完全隔离。即使你把$fd = fopen(...)的结果存进全局变量或Swoole\Table，其他Worker读到的也只是个无意义的数字——它在那个进程的fd表里没有对应项。
这和数据库连接、Redis客户端同理：协程内new没问题，但绝不能在Worker A里new一个fsockopen连接后，试图在Worker B里调用它的fwrite()。
正确方案一：每个Worker独立打开/关闭
在onReceive或onRequest回调入口处，根据当前请求上下文重新打开所需文件或网络连接。
例如处理上传临时文件：
```php
$tmpFile = tempnam(sys_get_temp_dir(), 'upload_');
$fp = fopen($tmpFile, 'w+'); // 每次请求都在本Worker内打开
fwrite($fp, $data);
fclose($fp); // 必须显式关闭，否则fd泄漏
```
这一步操作起来很简单，直接把文件拖进去就行。关键在于【必须在同一个Worker生命周期内完成打开→使用→关闭全流程】，不能依赖上一次请求留下的句柄。
正确方案二：用外部存储替代本地句柄共享
若需多个Worker协同处理同一份数据（如日志聚合、大文件分片上传合并），放弃“共享句柄”思路，改用进程无关的中间载体。
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
方法一：Swoole\Table + 文件路径字符串
在Table中只存文件绝对路径（如'/tmp/upload_abc123.bin'），各Worker按需fopen→操作→fclose。路径本身是字符串，可安全跨进程读取。
方法二：Redis或MySQL作为协调中心
用Redis的INCR、LPUSH或MySQL的INSERT ... ON DUPLICATE KEY UPDATE来同步状态；实际I/O操作仍由各自Worker独立发起。
方法三：Swoole\Process::signal配合管道通信
主进程创建命名管道（如/tmp/my_pipe），通过信号通知指定Worker去读写该管道——管道本身是内核对象，可在父子进程间继承，但依然【不能跨Worker进程直接传递fd值】，必须靠fork时继承或sendmsg传递fd（PHP不原生支持）。
绝对禁止的操作清单
第一步：检查代码中是否存在全局fopen赋值，如global $logHandle; $logHandle = fopen('/var/log/app.log', 'a');——立刻删除。
第二步：搜索所有static $conn或self::$fp类属性，若其值为文件句柄或socket资源，全部重构为每次请求new或从上下文获取。
第三步：禁用任何尝试用pcntl_fork()后在子进程中复用父进程fd的操作，Swoole Worker已由Manager管理，自行fork会破坏进程模型。
第四步：确认Swoole配置中'enable_coroutine' => true已开启，并在协程入口调用Swoole\Runtime::enableCoroutine(SWOOLE_HOOK_FILE)，确保fopen/fwrite等函数被协程化钩子接管——否则仍可能阻塞整个Worker。
