Swoole与ThinkPHP整合部署需要注意哪些问题

Swoole与ThinkPHP整合需解决常驻内存与请求生命周期冲突，必须启用协程、使用think-swoole扩展、通过php think swoole:server启动、配置swoole.php、重置数据库连接并手动触发App::run。

将Swoole与ThinkPHP整合部署时，必须直面常驻内存模型与传统请求生命周期的根本冲突，否则服务启动后立即出现502、路由错乱、数据库连接泄漏或内存持续飙升等问题。

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

php -m | grep swoole只能说明扩展加载成功，【必须运行php --ri swoole并确认coroutine => enabled】。若显示disabled，代表协程未开启，所有Db::transaction()、协程MySQL查询都会阻塞worker进程，压测时瞬间卡死。

若为disabled，需重新编译Swoole并显式添加--enable-coroutine参数，仅修改php.ini无效。

PHP版本建议≥8.0；7.4虽可运行，但SwooleCoroutineMySQL等API行为不一致，极易引发不可复现的随机异常。

立即学习“PHP免费学习笔记（深入）”；

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

方法一：执行composer require topthink/think-swoole（注意不是swoole/swoole，二者冲突）。

方法二：验证config/service.php中已注册thinkswooleService::class——默认已存在，无需手动添加；若项目启用了多应用模式，需检查app/multi.php未禁用全局服务注册。

手写SwooleHttpServer脚本是高危操作：【漏掉$_SERVER模拟会导致ThinkPHP路由解析失败，漏掉协程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中启用thinkswoolerpcService::class，并单独配置rpc键；仅靠HTTP配置无效。

【所有自定义on*回调里禁止直接调用echo或var_dump】——协程环境下会阻塞整个worker进程，导致所有连接挂起。

数据库连接必须按worker重置

Swoole进程常驻，PDO实例不会自动释放。必须在onWorkerStart回调中重连数据库，或使用SwooleCoroutineMySQL连接池。

若沿用传统Db类，需在onRequest中手动reset单例，否则上一个请求残留的事务状态、查询缓存会污染下一个请求。

中间件和路由链不会自动触发——务必在onRequest中手动调用thinkApp::run()，而非仅echo $response->getContent()。