在Swoole协程中直接使用PDO会导致协程卡死、事务错乱和数据丢失，因其同步阻塞模型与协程非阻塞机制天然冲突；ThinkPHP的Db::connect()单例模式加剧协程间状态污染；必须将数据库类型改为'mysql'、关闭读写分离、禁用预处理模拟，并避免环境变量获取凭据。
在Swoole协程环境下直接使用传统PDO会导致协程调度卡死、事务错乱、数据 silently 丢失，根本原因不是配置没调对，而是PDO底层同步阻塞模型与协程非阻塞调度机制天然冲突。
PDO在协程中会退化成同步阻塞行为
哪怕你把new PDO()包在go()里，PDO::__construct或PDO::query仍会发起同步TCP连接和读写操作，整个协程被挂起，其他协程无法调度——这不是性能差的问题，是并发能力直接归零。
PHP的PDO扩展本身是线程安全（ZTS）的，但它完全不感知协程切换：一次query内部可能经历多次send/recv系统调用，每次切换协程时PDO都不保存中间状态，导致fetch模式错乱、事务隔离失效、甚至查到其他协程刚写入的脏数据。
这一步操作起来很简单，但后果严重：只要有一个地方用了Db::connect()或new PDO()，整个请求链路就退出协程模型。
ThinkPHP中Db::connect()返回同一PDO实例
ThinkPHP默认将Db::connect()设计为单例+连接复用，每次调用都返回同一个PDO对象。
Swoole协程共享Worker进程内存，多个协程拿到的是同一份PDO连接状态。协程A执行了beginTransaction()，协程B紧接着调用query()，可能触发“Cannot execute queries while other unbuffered queries are active”错误；协程A设了setFetchMode(PDO::FETCH_ASSOC)，协程B查出来的结果却变成数字索引——【这种错乱不可预测，且难以复现】。
这不是Bug，是同步框架在协程环境下的必然表现。
强行用PDO模拟协程的三大陷阱
方法一：启用Swoole Runtime Hook（SWOOLE_HOOK_PDO）
只对新创建的PDO连接生效；若ThinkPHP在应用初始化阶段已提前硬建了PDO实例（如config/autoload.php中触发Db::connect()），Hook完全不起作用——【此时协程看似启用，实则全程同步阻塞】。
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
方法二：手动new PDO() + setAttribute(PDO::ATTR_PERSISTENT, true)
PDO持久连接在Swoole CLI场景下极易失效：子协程fork后文件描述符不共享，频繁触发“MySQL server has gone away”，连接池管理彻底失控。
方法三：封装PDO-like接口，底层用Swoole\Coroutine\MySQL代理
可行但成本高：需重写prepare/bind/execute全流程，且无法兼容原生PDOStatement对象的类型映射、游标定位等特性；更关键的是，任何跨协程传递PDOStatement实例的行为都会立即引发状态污染。
必须切断PDO路径的三项硬动作
第一步：修改config/database.php，将'type' => 'pdo'强制改为'type' => 'mysql'——这是启用Swoole原生协程MySQL客户端的开关，不改此项，后续所有配置无效。
第二步：设置'deploy' => 0，关闭读写分离——否则Connection类内部会绕过协程驱动，偷偷创建同步PDO连接，混入协程流程中。
第三步：禁用预处理模拟，'params' => [PDO::ATTR_EMULATE_PREPARES => false]——否则SQL由PHP同步拼接，失去协程化意义，且prepare语句无法复用，性能反降。
另外，'hostname'、'username'、'password'必须明文写死，不能依赖getenv()或$_ENV——协程上下文不保证环境变量始终可读，运行中可能出现credentials为空的静默失败。
