做一个文生图应用，前端界面好写，真正的问题在后端——用户上传的图存哪、怎么调模型、怎么把结果返回给用户。这篇按阿里云通义万相的技术方案，把 AI 图像生成应用的后端链路拆清楚。
一、整体请求链路
文生图应用的后端流程不复杂，但每个环节都有讲究：
用户输入 Prompt / 上传图片
│
▼
ECS 接收请求
│
├── 文生图：直接把 Prompt 发给万相 API
│
└── 图生图：用户图片先存 OSS，生成签名 URL 发给万相 API
│
▼
万相模型生成图像
│
▼
返回图像 URL
│
▼
存到 OSS，返回给前端
核心是三个组件：ECS 跑业务逻辑、OSS 存图片、万相 API 做实际生成。
二、为什么 ECS 不能少
有人会问：直接前端调万相 API 不就行了？为什么还要一台 ECS？
原因有三个：
1. API Key 不能暴露在前端。 大模型 API 都需要鉴权，Key 放在前端代码里等于公开了，任何人都能盗用你的额度。必须由 ECS 后端持有 Key，前端请求后端，后端再转发给模型。
2. 需要业务逻辑处理。 比如用户上传图片后，你要做格式校验、压缩、加水印、记录生成历史、统计调用次数。这些逻辑放在前端不靠谱，也没法在模型 API 里做。
3. 需要存中间状态。 用户发起生成 → 排队 → 生成中 → 完成，这个状态流转需要后端维护。大模型 API 是同步调用还是异步轮询，你得自己管理。
三、OSS 为什么必须有
文生图应用有两种输入：纯文字 Prompt，或者用户上传参考图（比如图生图、涂鸦转换、人像风格化）。
用户上传的图片不能直接传给模型 API。 万相这类模型服务要求图片通过 HTTP URL 访问，不能直接上传二进制文件。所以流程是：
- 用户在前端选图
- 前端把图传到你的 ECS
- ECS 把图存到 OSS
- 生成一个带签名的临时 URL（过期时间可控）
- 把这个 URL 连同 Prompt 一起发给万相 API
- 万相模型通过这个 URL 下载图片进行处理
OSS 的作用就是做"图片中转站"——用户上传的图、模型生成的结果图，都先存 OSS，再通过 URL 引用。
为什么要用签名 URL？ 因为 OSS 存储桶默认是私有的，不能公开访问。签名 URL 相当于一个有时效的临时通行证，模型服务能下载，但过了有效期就访问不了了，安全。
四、调万相 API 的关键细节
调用文生图 API 时，有几个参数直接影响生成效果：
| 参数 | 作用 | 调优建议 |
|---|---|---|
| prompt | 文本描述 | 越具体越好，加风格、构图、光影描述 |
| negative_prompt | 反向描述 | 排除不想要的元素，比如"模糊""低分辨率" |
| size | 输出尺寸 | 根据业务场景选，社交图用方形，海报用竖版 |
| n | 生成张数 | 一次生成多张方便用户选，但成本也翻倍 |
| style | 风格预设 | 写实、动漫、水彩等，根据产品定位选 |
图生图类的接口（人像风格化、涂鸦转换）还需要传参考图 URL 和风格强度参数。
五、异步处理是必须的
文生图不是秒回的——一张图生成通常要几秒到十几秒。如果同步等待，用户会以为卡死了。
正确做法是异步：
- 前端发请求，后端立即返回一个任务 ID
- 后端后台调万相 API，等模型返回结果
- 前端轮询任务状态（或者用 WebSocket 推送）
- 生成完成后返回图片 URL
这个状态管理逻辑放在 ECS 上，可以用数据库记录每个任务的状态：pending → processing → done / failed。
六、实际部署清单
从零搭一个文生图后端，需要准备：
- ECS 实例：跑 Node.js 或 Python Web 服务，配置不用太高，2核4G 够用
- OSS Bucket：存用户上传图和生成结果图，建议按日期分目录
- 百炼 API Key：在阿里云百炼平台申请，开通万相模型
- 域名和 HTTPS：如果是 Web 应用，需要 HTTPS（浏览器要求）
- 数据库：记录用户、生成历史、调用次数，轻量的 MySQL 就够
整个架构的成本主要是大模型 API 调用次数，基础设施（ECS+OSS）很便宜。
七、写在最后
AI 图像生成应用的后端架构不复杂——ECS 做业务中转、OSS 做图片存储、大模型 API 做实际生成。理解了这条链路，你就知道为什么不能直接前端调 API、为什么需要 OSS、为什么要异步处理。
完整的技术方案和产品组合可以看官方方案页——查看通义万相 AI 绘画创作技术方案。具体能力以页面实际展示为准。
你做过文生图应用吗？后端怎么搭的？评论区交流。
