yii2搭上swoole常驻内存模式性能直接起飞，实测qps达5000+、响应时间5–20ms，核心在于一次加载框架与配置、复用db/redis连接池、协程非阻塞i/o；需重置请求级状态、清理静态缓存、检查连接健康，并禁用原生session、合理配置连接池。
Yii2搭上Swoole常驻内存模式，性能不是“略有提升”，而是直接起飞——实测QPS从几百飙到5000+，平均响应时间压到5–20ms。这不是理论值，而是真实压测结果：1万请求，Swoole耗时约11.6秒，PHP-FPM则要166秒，相差近15倍。
为什么能快这么多？
根本原因在于执行模型彻底改变：
- 不再重复加载：Yii2框架、配置、路由、组件全部一次加载、常驻内存，省掉每次请求的autoloader扫描、配置解析、类实例化开销
- 连接真正复用：MySQL/Redis连接池在Worker进程内长期存活，避免TCP三次握手、认证、权限校验等网络往返
- 协程非阻塞：I/O操作（如DB查询、HTTP调用）挂起当前协程，让出CPU给其他请求，单进程轻松支撑数千并发
关键适配点不能跳过
快的前提是稳。Yii2原生为短生命周期设计，直接扔进Swoole会出数据串号、内存泄漏、连接断开等问题。必须做三件事：
Swoole 6.1.1
下载
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
- 请求级状态重置：每次HTTP请求开始前，清空Yii::$app->user、Yii::$app->session、Yii::$app->cache等可变状态，避免A用户看到B的数据
- 静态缓存清理：重置AR模型schema缓存、ArrayHelper内部静态数组等，防止内存随请求累积暴涨
- 连接健康检查：在请求入口或数据库操作前，主动检测PDO连接是否活跃（如执行SELECT 1），失效则重建
主流方案怎么选？
不用从零造轮子，两个成熟方案可直接落地：
- tsingsun/yii2-swoole（推荐）：适配Swoole 4.2+，支持协程开关、session、连接池、热重启；启动脚本里一行define('COROUTINE_ENV', true)即可切换模式
- dacheng-php/yii2-swoole：基于Yii2组件体系封装，通过config/swoole.php配置，命令行php yii swoole/start一键启停，适合已有Yii2项目快速接入
上线前必须验证的细节
再快的引擎，跑错路也会翻车：
- 禁用PHP原生session：ini_set('session.auto_start', 0)，改用Swoole提供的session组件或自定义token机制
- DB连接池大小匹配负载：worker_num × max_coro_num 不宜远超MySQL max_connections，否则触发Too many connections
- OpCache保持启用但不依赖它救场：Swoole本身已规避文件重载，OpCache主要加速类反射和模板编译，仍建议开启
不复杂但容易忽略。只要把初始化逻辑和请求隔离做扎实，Yii2在Swoole上就能既快又稳。
