PHP文生图卡顿的根本原因是同步阻塞在HTTP请求或模型推理上，必须改用Redis+Worker异步架构：前端提交即返回task_id，Worker后台拉取任务调用API生成图片并存结果，前端轮询获取URL；需设cURL超时参数、进程守护及磁盘存储+定时清理。
PHP 文生图（如用 Stable Diffusion API、ComfyUI 或本地模型）卡顿，不是 PHP 本身慢，而是同步阻塞在 HTTP 请求或模型推理上——必须把生成逻辑移出主请求流，改用后台任务。
为什么不能在 $_POST 处理里直接调用文生图 API
常见错误是：用户上传提示词后，PHP 脚本直接 curl_exec() 调用本地/远程文生图服务，等几秒到几十秒，期间 Nginx 超时、PHP-FPM 进程挂起、浏览器白屏。这不是“优化代码能解决”的问题，是架构级阻塞。
- HTTP 超时通常设为 30–60 秒，而 SDXL 生成一张图常需 8–25 秒（CPU/GPU 资源不足时更久）
- PHP-FPM 进程被占住，无法处理其他请求，
pm.max_children很快耗尽，触发 502 - 用户无法取消、无法查看进度、无法重试，体验断裂
用 Redis + Worker 实现真正异步文生图
核心是「提交即返回」+「轮询/通知查结果」。不依赖框架，纯 PHP 可落地：
- 前端提交后，PHP 写一条任务到
redis.lpush('queue:txt2img', json_encode($job))，立即返回{"task_id": "t_abc123"} - 独立运行的 Worker 脚本（如
php worker.php）持续redis.brpop('queue:txt2img', 0)拿任务，调用文生图 API，生成完存到redis.setex("result:t_abc123", 3600, json_encode([...])) - 前端用
fetch('/api/task?t=t_abc123')轮询（建议 2s 间隔），后端只查redis.get("result:t_abc123")，命中则返回图片 URL 或 base64 - Worker 必须加守护：用
supervisord或 systemd 管理，崩溃自动重启；加日志写入/var/log/txt2img-worker.log，别打屏
curl_setopt 调用文生图服务时必设的三个参数
即使进 Worker，没设对 cURL 参数，依然会卡死或超时失败：
立即学习“PHP免费学习笔记（深入）”；
-
curl_setopt($ch, CURLOPT_TIMEOUT, 120)：总超时至少 120 秒，SD 推理不可控，30 秒不够 -
curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, 10)：连接阶段超时设短，避免 DNS 卡住 -
curl_setopt($ch, CURLOPT_HTTPHEADER, ['Accept: image/png', 'Content-Type: application/json'])：明确告诉 API 你要什么格式，避免服务端协商耗时 - 禁用
CURLOPT_FOLLOWLOCATION：文生图 API 一般不跳转，开它反而增加不确定性
生成结果缓存与清理要主动，别靠过期
文生图结果（尤其是 PNG/WebP）体积大，Redis 存二进制易爆内存，正确做法是：
- Worker 生成图后，用
file_put_contents('/path/to/img/t_abc123.png', $png_data)写磁盘或上传到 OSS/CDN - Redis 中只存轻量元数据：
{"status":"done","url":"/img/t_abc123.png","created_at":1724789234} - 加定时清理：每天用
find /path/to/img -name 't_*' -mmin +1440 -delete清 24 小时前的图，别等磁盘满 - 用户删除任务时，PHP 主动调
redis.del("result:t_abc123")+unlink($local_path)，避免残留
文生图真正的瓶颈从来不在 PHP 解析速度，而在 I/O 阻塞和资源等待。后台任务不是“高级技巧”，是这类长耗时操作的唯一合理形态；漏掉进程守护、cURL 超时或结果清理中的任意一环，都会让系统在高并发下迅速雪崩。
