thinkphp文生图接口超时主因是连接池未启用或配置错误：必须用db::pool()显式调用、swoole常驻进程环境，fpm下无效；关键参数为max_active=12、wait_timeout=3000、idle_timeout=60，且需确认瓶颈确在db而非图像生成等下游依赖。
PHP文生图接口超时，不是数据库慢，而是连接池没配对、没启用，或根本不在常驻进程里跑。
ThinkPHP 6.1+ 的 Db::pool() 必须显式调用才生效
配置了 db_pool 但接口还是超时？大概率你还在用 Db::table() 或模型直接查 —— 这些走的全是传统短连接，和池子完全无关。
-
Db::table('image_tasks')->where('status', 'pending')->select()→ 每次新建 PDO，不复用，高并发下秒变PDOException: Too many connections -
Db::pool()->table('image_tasks')->where('status', 'pending')->select()→ 从当前 Worker 进程的池子里取空闲连接，复用成功 - 事务也得改：
Db::pool()->transaction(...)，否则Db::transaction()自动绕过池子 - 模型类（如
ImageTaskModel）默认不走池子，必须重写db()方法返回Db::pool()实例
max_active 和 wait_timeout 是文生图接口抗压的关键参数
文生图任务通常耗时长（生成、回调、状态轮询），连接占用时间远高于普通 API。若 max_active 设太小，请求排队；设太大，又可能打爆 MySQL 的 max_connections。
-
max_active => 12：适合单 Worker 并发 10–15 路文生图请求（每路平均占连 2–3 秒），超过的请求进入等待队列 -
wait_timeout => 3000：排队最长等 3 秒，超时抛PoolTimeoutException，比卡死强；设成 10000 就容易拖垮整个接口响应 -
idle_timeout => 60：空闲连接 60 秒后回收，防止长期闲置却占着名额 - 注意：
max_idle不是“保底连接数”，设为 0 不影响突发扩容，只控制回收节奏
FPM 下配 db_pool 完全无效，必须切 Swoole 环境
PHP-FPM 每个请求都是新进程，连接池无法跨请求存在。你看到的“连接复用”只是 PDO 持久连接（PDO::ATTR_PERSISTENT）的假象，实际仍受 MySQL wait_timeout 限制，且极易泄漏。
- 确认已装
swoole >= 4.8.0和topthink/think-swoole >= 3.1.0 - 配置只写在
config/swoole.php的db_pool项里，config/database.php中的 pool 配置会被忽略 - 启动命令必须是
php think swoole:start，不是php -S或 FPM - 每个 Swoole Worker 进程有独立池子，所以总连接数 =
worker_num × max_active，别忘了乘上
连接池不解决文生图本身的耗时，只解决 DB 连接瓶颈
如果超时来自图像生成（Stable Diffusion API 响应慢）、OSS 上传卡顿或第三方回调延迟，加连接池毫无意义。先用 microtime(true) 打点定位真瓶颈：
- DB 查询耗时
-
show processlist里大量Sleep连接未释放 → 检查是否漏调Db::pool()归还逻辑（一般不用手动归还，但自定义连接需注意） - 日志出现
PoolTimeoutException频繁 → 不是池子不够，是下游依赖（如绘图服务）拖慢了连接释放速度，导致池子被长期占满
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
