【面试加分】Swoole 在物联网（IoT）领域的面试题-Swoole-PHP中文网

swoole server不能直接用swoole_process模式跑mqtt设备接入，因为各worker进程内存隔离，无法共享client_id、订阅关系等会话状态，导致重复连接无法踢旧连接；必须改用swoole_base模式配合swoole_table存储元数据，并用swoole_timer_tick实现应用层心跳检测。

【面试加分】swoole 在物联网（iot）领域的面试题

Swoole 在 IoT 场景中不是“能用”，而是“必须用对”——否则高并发连接、低延迟响应、设备心跳保活这些基本需求都会出问题。

为什么 `swoole_server` 不能直接用 `SWOOLE_PROCESS` 模式跑 MQTT 设备接入？

因为 SWOOLE_PROCESS 模式下，每个 worker 进程是独立内存空间，无法共享连接状态和设备会话（如 client ID、will message、订阅关系）。MQTT 协议要求同一 client ID 的重复连接必须踢掉旧连接，而跨进程无法感知。

正确做法：用 SWOOLE_BASE 模式 + swoole_table 存储设备元数据（client_id → fd + last_active_time）
必须配合 swoole_timer_tick 做心跳检测，不能依赖 TCP keepalive（IoT 网络不稳定，需应用层可控超时）
注意 swoole_table 的 key 长度限制（默认 64 字节），client_id 超长需哈希截断或改用 redis 作外置会话存储

`swoole_http_server` 处理设备固件升级时，大文件上传失败的常见原因

不是带宽或超时设置的问题，而是 HTTP 协议层与 Swoole 内存模型不匹配导致的 —— 默认 upload_tmp_dir 是 PHP-FPM 时代的路径，Swoole 不走该流程；且 post_max_size 等 ini 设置对 swoole_http_server 完全无效。

Swoole 6.1.1

Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。

下载

必须手动解析 multipart/form-data：监听 onRequest，用 swoole_http_request->rawContent() 拿原始 body，再用 curl_init() 或 fopen('php://input', 'r') 流式读取（避免内存爆满）
设备端上传固件建议改用分块上传（chunked upload），服务端用 swoole_atomic 计数器校验完整性
禁用 http_compression，压缩会破坏二进制固件的 CRC 校验值

设备频繁断线重连时，`swoole_client` 的复用陷阱

很多面试者写 new swoole_client(SWOOLE_SOCK_TCP) 放在循环里，每次重连都 new 一个新对象 —— 这会导致 fd 泄漏、TIME_WAIT 爆满、最终 Too many open files 错误。

正确方式：复用 swoole_client 实例，调用 $client->close() 后立即 $client->connect()，不要 new 新对象
务必监听 onClose 和 onError，并在回调里触发重连逻辑（避免在 onConnect 里直接 connect 形成死循环）
注意 swoole_client 的 timeout 参数单位是秒（非毫秒），IoT 设备弱网下建议设为 5~10 秒，太短会误判断线