Swoole与ThinkPHP整合部署需要注意什么

说到Swoole和ThinkPHP的整合部署，本质上就是一次常驻内存模型跟传统请求生命周期的正面碰撞。如果不把这两者之间的根本冲突理顺，服务启动后很可能就会遭遇502、路由错乱、数据库连接泄漏乃至内存持续上涨等一系列问题。下面直接梳理几个必须卡死的节点。

确认Swoole协程能力已真正启用

光靠php -m | grep swoole只能说明扩展装上了，必须运行php --ri swoole并确认coroutine => enabled。如果显示的是disabled，意味着协程压根没打开，所有像Db::transaction()这样的事务操作、协程MySQL查询都会阻塞住worker进程，压测一到，活儿可能会直接卡死。

协程被禁用的话，得重新编译Swoole，并且编译时显式加上--enable-coroutine参数——光改php.ini是没用的。另外，PHP版本最好放在≥8.0；7.4虽然也能跑，但Swoole\Coroutine\MySQL这类API的行为不一致，容易闹出一些难以复现的随机异常，排查起来很痛苦。

强制使用think-swoole扩展，禁用手写HttpServer

正确做法是执行composer require topthink/think-swoole（注意包名是topthink/think-swoole，不是swoole/swoole，二者会冲突）。装完之后，去config/service.php里确认是否已注册think\swoole\Service::class——框架默认就有，一般不需要手动添加。如果项目启用了多应用模式，还要检查app/multi.php，确保没有禁用全局服务注册。

自己手写Swoole HTTP Server脚本是一条危险的路：漏掉$_SERVER模拟，路由解析就废了；漏掉协程Hook，内存泄漏是早晚的事；漏掉异常捕获，worker进程会在静默中崩溃。这些细节框架已经全都封装好了，自己实现的话，99%的概率上线即出故障，得不偿失。

启动服务必须走官方命令，配置项只写在swoole.php

第一步，启动命令必须是php think swoole:server，而不是自己弄一个php swoole.php或者其他自定义入口文件。第二步，所有配置——像worker_num、max_coroutine这些——必须乖乖写在config/swoole.php里，别硬编码进启动逻辑。

这里有几个关键数值需要记一下：worker_num一般设为CPU核数×2到4倍，超过32反而会加剧锁竞争；max_coroutine必须显式设置，比如设成3000，否则协程里的DB查询容易被阻塞。另外，swoole.php里不要写'daemonize' => true——ThinkPHP的日志flush和异常处理器在守护进程下会失效，到时错误日志丢了都找不到原因。

WebSocket场景必须手动补全事件回调

think-swoole默认只处理HTTP请求，如果涉及WebSocket，需要额外绑定事件。比如在app/command/SwooleChat.php里，$server->on('open', ...)和$server->on('message', ...)这些回调必须自己显式写好，框架不会代劳。

RPC场景则要在config/service.php中启用think\swoole\rpc\Service::class，并单独配好rpc键——光配HTTP是不够的。还有一个容易踩的坑：所有自定义的on*回调里，别直接调用echo或var_dump——在协程环境下，这会阻塞整个worker进程，导致所有挂在上面的连接都被卡住。

数据库连接必须按worker重置

Swoole是常驻进程，PDO实例不会自动释放。所以得在onWorkerStart回调里重新连数据库，或者用Swoole的协程MySQL连接池来管理。如果还在用传统的Db类，就得在onRequest中手动重置单例，不然上一个请求残留的事务状态、查询缓存都会污染下一个请求。

另外需要注意，中间件和路由链不会自动帮你触发App::run()——务必在onRequest里手动调用think\App::run()，而不是只echo $response->getContent()就完事。