【面试点拨】Swoole 为什么能让 PHP 焕发第二春？-Swoole-PHP中文网

swoole彻底重写了php运行范式，实现常驻内存、协程调度与异步i/o；其多进程/线程模型使$_session和global失效，需改用swoole\table或thread\map等共享机制。

【面试点拨】swoole 为什么能让 php 焕发第二春？

不是“PHP 又行了”，而是 Swoole 让 PHP 终于能干它原本干不了的事——常驻内存、协程调度、异步 I/O、原生 TCP/UDP/WebSocket 支持。它没改 PHP 语法，但彻底重写了 PHP 的运行范式。

为什么 `$_SESSION` 和 `global` 在 Swoole 里直接失效？

因为 Swoole 进程不销毁，而传统 PHP-FPM 每次请求都新建+销毁整个执行环境。$_SESSION 依赖 session 扩展的文件或 Redis 存储机制，但默认配置下不会自动开启；global 变量只在当前进程/线程作用域有效，多 worker 进程下互不可见，更别说 v6 的多线程模型——变量根本不同步。

要用共享数据，必须显式使用 Swoole\Table（v5 及以前）或 Swoole\Thread\Map（v6+ 线程安全）
$_SESSION 不是不能用，但得手动集成 session handler，比如用 RedisSessionHandler 并配置 session_set_save_handler()
别在 onRequest 回调里写 $counter++ 期望全局计数——它只会在这个 worker 进程里自增，其他进程完全无感

`Swoole\Http\Server` 刷新浏览器却收到两次请求？

这不是 bug，是浏览器行为：除主页面请求外，还会自动发一次 GET /favicon.ico。Swoole 原生 HTTP Server 不像 Nginx + PHP-FPM 那样默认忽略或 404 掉这个路径，它照单全收。

PHP 8.5.5

PHP 8.5.5 是 PHP 8.5 分支的维护更新版本。该版本延续了“小步快跑”的迭代逻辑，通过深度错误修复、底层性能微调以及安全加固，旨在为开发者提供一个更健壮、更高效的运行环境。该版本严格遵守语义化版本规范，不包含破坏性变更。

下载

最轻量解法：在 onRequest 中加判断 if ($request->server['request_uri'] === '/favicon.ico') { $response->status(404); $response->end(); return; }
更合理做法：用反向代理（如 Nginx）前置处理静态资源，让 Swoole 专注业务逻辑
注意：某些调试工具（如 Postman）不会发 favicon 请求，所以本地测试时可能“不复现”，上线后才暴露

v6 多线程模式下，`Swoole\Coroutine::create()` 还安全吗？

安全，但语义变了。v6 的协程仍是协作式调度，但底层运行在线程池中；而 Swoole\Thread 是抢占式系统线程，二者混用需格外小心。

Swoole\Coroutine::create() 仍推荐用于 I/O 密集型任务（如 Co\Http\Client、Co\MySQL），它不阻塞线程，且跨线程可挂起/恢复
不要在协程里直接操作 Swoole\Thread\Map 的写入——虽然线程安全，但协程切换时机不可控，容易引发逻辑竞态
若需同步控制，优先用 Swoole\Coroutine\Channel 或 Swoole\Coroutine\Lock，而非 Swoole\Thread\Mutex
v6 启动时默认启用 enable_coroutine => true，但若关闭它，所有 Co\* 类将不可用

为什么用 `swoole_table` 而不用 `apcu` 或 `redis` 做进程间缓存？

因为性能和场景错位：swoole_table 是纯内存、无序列化、零网络开销的共享表，适用于高频读写、结构固定、生命周期与 Server 一致的数据；apcu 不支持多进程共享（除非 ZTS + apcu-bc，且不稳定）；redis 是网络 IO，哪怕本地 loopback 也有微秒级延迟，在万级 QPS 下会成瓶颈。