ai绘画php接入实录：我给网站加自动出图只花了50行代码

上个月给我的内容站加了个自动出封面图的功能，动手前先搜了一圈ai绘画php的方案，结果十篇教程有九篇拐到Python去了。PHP就该不配出图吗？不服气，自己撸了一遍，最后核心逻辑落在50行代码上，站点到现在跑了一个多月。

这篇不讲大道理，就按我踩过的顺序把流程摊开。你看完能知道每个环节会卡在哪，值不值得给自己的站也接一个。

整个流程拆开就三步：请求、保存、落库

PHP出图的骨架是：cURL带提示词POST到文生图接口，拿到图片地址后下载转存到自己服务器，最后往队列表写一条状态记录。三步各自独立，出问题好定位。

第一步的请求最简单。curl_init设个JSON体，字段无非是提示词、尺寸、张数，跟调任何第三方接口没区别。唯一要留意的是接口返回结构千奇百怪，有的直接回图片二进制，有的回一个临时URL让你自己去拉，写代码前先拿Postman敲一遍看清楚返回长什么样，能省半小时。

第二步转存，我踩了个小坑：接口给的临时URL有效期只有一小时，当天偷懒没转存，第二天一看图全裂。所以转存这步别拖，拿到结果立刻file_put_contents落盘，顺手压成webp，一张原图能从2MB压到130KB左右。

第三步落库是我后来才补的。最开始图存完就完事，结果想查「昨天生成了哪些图、哪张失败了」完全没有凭据。加了一张 ai_images 表记录提示词、状态、耗时，排查问题的时候简直救命。

为什么必须异步排队，不能当场等结果

文生图接口一张图普遍要20到40秒，PHP-FPM的worker被你占住干等，五六个并发就能把整站拖成502。正确做法是先入队立即返回，后台进程慢慢消费。

这个坑我是真踩过的。第一版代码图省事，用户点按钮就同步等接口返回，本地测试一切美好。上线当天站点来了十几个人同时点，PHP进程池被占满，不画出图的页面也打不开了，后台报警短信响个不停。那晚我看着监控图上那排红色，脸跟出图失败占位符一个色。

重构后的方案很朴素：点按钮只往队列表插一条记录，页面立刻返回「生成中」；机器上跑一个常驻的worker脚本用 while 循环捞队列，或者偷懒用cron每分钟扫一次。我的站流量小，cron方案一分钟扫一次完全够用，从入队到出图平均等一分半，用户感知就是刷新一下图就出来了。

顺带一个细节：worker里记得设接口超时和重试上限。我的配置是接口超时60秒、失败重试最多3次，超过3次标记失败不再消耗额度。没这个上限的话，接口抽风一次能把你账户余额刷穿。

钱和坑：按张计费的时代要会过日子

自动出图的成本全在接口费上，测试期我花了三十来块钱出了100多张，能直接用的不到一半，失败重试和人工抽检都算进日常流程才稳。相同提示词做缓存，重复内容别重复花钱。

我算过一笔账：站点每天新文章十来篇，一张封面按几毛钱算，一个月下来几十块，比请人做图便宜太多。但有个前提——提示词写得稳定。有阵子我提示词随手写，出的图一半牛头不对马嘴，等于烧钱抽卡。后来把提示词模板化，标题关键词填进固定骨架，可用率从五成拉到八成往上。

另一个经验是抽检。自动生成的图偶尔会出些诡异玩意儿，我一般每周扫一次后台，把明显不能用替换掉。别迷信全自动，机器出图人把关，这个组合目前最省心。

功能上线一个多月，后台那条50行的核心逻辑没再动过，倒是队列表现攒了两千多条记录，翻起来还挺有成就感。回头看，ai绘画php接入这事最难的不是写代码，是愿意先把流程想清楚再动手——先入队还是先等待，转存拖不拖，重试封不封顶，这三个决定做对了，剩下的都是体力活。

常见问题

虚拟主机没有命令行，还能做吗？

能，但只能走同步方案，并且要把接口超时调短、限制单次一张。更好的出路是换成带SSH的轻量云服务器，一年一百多块的最低配就够跑cron队列了。

用户要等一分多钟才看到图，会不会流失？

把等待做出来就不流失：页面先展示一个占位骨架屏，出图后前端轮询替换。有进度预期的等待和无反应的白屏，用户体验完全是两回事。

接口生成的图用在商业站点有版权风险吗？

下单前把服务商的用户协议读一遍，重点看商用授权和免责条款那几节。我选的这家明确写了输出归付费用户使用，我才敢往站上放。协议没写的，默认当不能商用处理。

需要先学Python再接入吗？

不需要，这套流程从头到尾只有PHP加一条cron，用的都是curl、文件函数和PDO这些基础货色。教程爱用Python只是因为那边示例多，不代表PHP做不了。