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虽可运行，但Swoole\Coroutine\MySQL等API行为不一致，极易引发不可复现的随机异常。
强制使用think-swoole扩展，禁用手写HttpServer
方法一：执行composer require topthink/think-swoole（注意不是swoole/swoole，二者冲突）。
方法二：验证config/service.php中已注册think\swoole\Service::class——默认已存在，无需手动添加；若项目启用了多应用模式，需检查app/multi.php未禁用全局服务注册。
手写Swoole\Http\Server脚本是高危操作：【漏掉$_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中启用think\swoole\rpc\Service::class，并单独配置rpc键；仅靠HTTP配置无效。
【所有自定义on*回调里禁止直接调用echo或var_dump】——协程环境下会阻塞整个worker进程，导致所有连接挂起。
数据库连接必须按worker重置
Swoole进程常驻，PDO实例不会自动释放。必须在onWorkerStart回调中重连数据库，或使用Swoole\Coroutine\MySQL连接池。
若沿用传统Db类，需在onRequest中手动reset单例，否则上一个请求残留的事务状态、查询缓存会污染下一个请求。
中间件和路由链不会自动触发——务必在onRequest中手动调用think\App::run()，而非仅echo $response->getContent()。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
