必须用Swoole\Coroutine\MySQL/Redis，因原生PDO/mysqli底层为阻塞I/O，协程调度器无法接管；即使启用Runtime::enableCoroutine(SWOOLE_HOOK_ALL)，仍需用Channel手写连接池并确保异常归还、心跳检测与合理容量控制。
不能直接用 PDO 或 mysqli，必须用 Swoole\Coroutine\MySQL 或 Swoole\Coroutine\Redis，否则协程一跑就退化成同步阻塞模型。
为什么原生 PDO / mysqli 在协程里会失效
因为它们底层调用的是系统级阻塞 socket I/O，Swoole 协程调度器完全无法接管。哪怕开了 Swoole\Runtime::enableCoroutine(true)，只要走 PDO::query() 或 mysqli_query()，整个协程就会卡住，等同于没开协程。
- 确认 PHP 使用的是
mysqlnd驱动（运行php -i | grep mysqlnd，有输出才有效） - 必须启用全量 Hook：
Swoole\Runtime::enableCoroutine(SWOOLE_HOOK_ALL)，只传true不够，SWOOLE_HOOK_ALL才能拦截 DNS、文件、socket 等所有系统调用 - 即使用了支持 hook 的 PDO 封装（如 Hyperf），
PDO::exec()仍可能漏掉，优先用query()和prepare()->execute()
手写连接池：用 Swoole\Coroutine\Channel 管理 MySQL 连接
这是最轻量、可控性最强的方式，不依赖框架封装，适合想看清原理或做定制化控制的场景。
- 池子本质是一个协程安全的队列：
$pool = new Swoole\Coroutine\Channel($maxSize)，容量即最大连接数 - 预热阶段要显式
connect()，传完整配置数组，不能靠构造函数自动连：['host' => '127.0.0.1', 'port' => 3306, 'user' => 'root', 'password' => '', 'database' => 'test'] - 获取连接后，务必在
finally块中归还，防止异常导致连接泄露：$pool->push($mysql) - 不要复用同一个
$mysql实例跨多个协程——它不是线程安全的，更不是协程间共享资源
示例关键片段：
立即学习“PHP免费学习笔记（深入）”；
go(function () use ($pool) {
$mysql = $pool->pop(); // 阻塞等待空闲连接
try {
$result = $mysql->query('SELECT id FROM user LIMIT 1');
var_dump($result);
} finally {
$pool->push($mysql); // 必须放回，哪怕 query 报错
}
});
Redis 连接池与 MySQL 的关键差异
Swoole\Coroutine\Redis 的行为比 MySQL 更“友好”，但仍有几个硬约束容易踩坑。
- 它不支持 pipeline 模式下的原子性归还——如果中途断开，整条 pipeline 的连接状态可能混乱，建议单次只发一个命令或自己封装重试逻辑
- 连接对象本身不带自动重连机制，
connect()失败需手动处理，不能假设pop()出来的一定可用 - Redis 密码必须放在
auth字段里，不是 DSN 参数：['host' => '127.0.0.1', 'port' => 6379, 'auth' => 'mypass'] - 若 Redis 启用了
timeout配置（如timeout 300），连接池里空闲连接可能被服务端主动断开，需配合心跳检测或设置ping预检
池大小和超时参数怎么设才不翻车
没有万能公式，但有三条铁律：池大小 ≤ 数据库 max_connections × 0.7，max_wait_time 必须小于接口整体超时，空闲连接存活时间必须短于 MySQL 的 wait_timeout。
- MySQL 默认
wait_timeout = 28800（8 小时），但线上常调低到 300～600 秒；你的连接池里连接空闲超过这个值，下次query()就报MySQL server has gone away - Redis 的
timeout默认是 0（永不过期），但内核 TCP keepalive 可能断连，建议池内连接每 60 秒ping一次 - 并发压测时观察
Threads_connected和SHOW PROCESSLIST，如果大量连接处于Sleep状态且不释放，说明归还逻辑漏了或者没进finally - 别迷信“越大越好”——池子过大反而加剧锁竞争，
Channel的pop/push是串行操作，50 以上容量对性能提升极小，还占内存
真正难的从来不是写几行 pop 和 push，而是确保每次异常路径都归还、每次空闲连接都心跳、每次连接创建都带完整上下文——这些细节一旦松动，连接池就变成连接泄漏加速器。
