PHP文生图超时本质是同步阻塞与AI生成不可控耗时的冲突，需分层应对：可控后端设CURLOPT_TIMEOUT_MS+反代超时；半可控云服务启用异步+Redis轮询；不可控第三方用ignore_user_abort+fastcgi_finish_request提前返回，并配状态机与兜底图。
PHP调用文生图接口超时，不是加个set_time_limit就能解决的——核心矛盾在于同步阻塞与AI生成不可控耗时的天然冲突。
为什么PHP脚本容易卡死在文生图请求上
绝大多数PHP文生图封装（比如调用Stable Diffusion WebUI、Fal.ai或混元API）默认走cURL同步请求，而AI图像生成实际耗时从3秒到90秒不等。PHP默认max_execution_time=30，一旦后端响应慢于这个值，脚本直接被FPM或CLI中断，返回空白或500，且无法回收连接资源。
更隐蔽的问题是：有些服务（如本地WebUI）在生成中会保持HTTP连接长挂起，但PHP cURL若未显式设置CURLOPT_TIMEOUT和CURLOPT_CONNECTTIMEOUT，可能陷入无限等待；而设得太短又导致频繁失败。
- Stable Diffusion WebUI的
/sdapi/v1/txt2img默认不支持异步轮询，必须等完才返回 - Fal.ai虽提供
sync=false选项，但PHP客户端若没处理202 Accepted+Location重定向头，就会当成错误 - 腾讯混元API对
Image字段Base64过大（>8MB）时，会在解析阶段超时，而非生成阶段
三类降级策略对应不同部署场景
不能只靠“加大超时时间”，得按服务可控性分层应对：
立即学习“PHP免费学习笔记（深入）”；
-
可控后端（如自建SD WebUI）：启用
--api-worker-processes 2并配置Nginx反向代理超时，PHP侧改用curl_setopt($ch, CURLOPT_TIMEOUT_MS, 15000)，失败后立即退到预设兜底图URL -
半可控云服务（如Fal.ai）：强制开启异步模式，PHP收到
202后存request_id到Redis，由独立worker轮询/v1/tasks/{id}，主流程不阻塞 -
不可控第三方（如混元控制台Demo）：前端加loading倒计时，PHP后端用
ignore_user_abort(true)+fastcgi_finish_request()提前返回“已提交”，再后台静默重试三次
PHP代码里最容易漏掉的两个timeout参数
只设set_time_limit(120)没用，它管不了cURL底层连接和读取阶段。必须同时控制三层：
- 连接建立：用
curl_setopt($ch, CURLOPT_CONNECTTIMEOUT_MS, 5000)（单位毫秒，避免DNS卡住） - 数据传输：用
curl_setopt($ch, CURLOPT_TIMEOUT_MS, 45000)（建议≤后端SLA承诺的P95延迟） - PHP自身：配合
ini_set('max_execution_time', 0)仅在CLI环境生效，Web环境依赖FPMrequest_terminate_timeout
示例关键片段：
curl_setopt($ch, CURLOPT_CONNECTTIMEOUT_MS, 5000); curl_setopt($ch, CURLOPT_TIMEOUT_MS, 45000); curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); curl_setopt($ch, CURLOPT_HEADER, false);漏掉
CURLOPT_HEADER会导致响应头混入body，JSON解析失败。
超时后怎么避免用户看到“生成失败”页面
真正影响体验的不是超时本身，而是没有平滑回退。别让PHP直接echo错误，而是：
- 返回标准JSON：
{"status":"pending","task_id":"fal_abc123","fallback_image":"/images/placeholder.png"} - 前端用
setTimeout在8秒后自动展示fallback_image，同时继续轮询 - 记录日志时带上
curl_getinfo($ch, CURLINFO_HTTP_CODE)和CURLINFO_TOTAL_TIME，区分是网络超时还是服务端超时
注意：所有降级路径（包括兜底图）必须经过CDN缓存，否则高并发下PHP又会因读取本地文件阻塞。
超时不是性能问题，是架构契约问题——你得明确告诉PHP：“这张图我不等了，但我知道它迟早会来”。真正的难点不在写set_time_limit，而在设计那个“不等却可靠”的状态机。
