把 GPT-Image-2 从“单次出图工具”，升级成“可复用、可管理、可部署”的完整图像工作台。
如果你经常遇到这些问题：
- Prompt 写过一次，下次又得重写
- 团队里每个人的出图风格都不统一
- 想基于截图、海报、UI 稿继续改图，但流程很散
- 想把模板沉淀下来，却没有一个真正能管理的后台
那这个项目就是为这种场景准备的。
Awesome GPT-Image-2 Workbench 不只是一个“输入一句话生成图片”的页面，它更像一个面向创作者、设计师、产品经理、运营团队的 AI 出图工作台：
- 模板化 Prompt：把高频提示词沉淀成模板，减少重复劳动
- 变量化输入：同一个模板可快速适配不同产品、主题和风格
- 参考图编辑：支持基于本地截图、照片、设计稿继续生成
- 结果可回看：最近生成记录保存在本地，方便继续迭代
- 后台可管理：通过隐藏后台
/rhz统一维护模板内容 - 上游 API 可控：后台统一配置上游 API 名称、接口地址和平台 Token，前台不暴露真实上游地址
- 个人 Token 可选：普通用户可在前台设置中填写自己的 Token，不填则使用后台配置的平台 Token
- 可自部署：支持本地、Docker、PM2、Node 服务等部署方式
- 可持久化：模板库默认走 SQLite，不再是一次性临时数据
一句话概括：
这不是“AI 画图演示页”，而是一套能真正用于日常生产的 GPT-Image-2 工作流界面。
如果你只是想马上跑起来，不想先看完整文档，可以直接选一条：
| 你的目标 | 你该怎么做 |
|---|---|
| 本地体验 | npm install → npm run dev |
| 正式部署且后台可在线保存模板 | 用 Docker |
| 没有 Docker，但有 Node 服务器 | 用 PM2 / npm start |
| 只有静态托管 | 只能发布 构建时模板快照，不能在线写后台 |
- 工作台 + 模板库 + 后台管理一体化：不再在多个零散页面之间切换
- 更适合长期创作：模板可沉淀、变量可复用、结果可回看
- 对个人和团队都友好：既能自己本地使用，也能部署给团队共用
- 兼顾创意与工程化：既支持自由 Prompt，也支持结构化模板和后台管理
| 对比项 | 普通 AI 出图页 | Awesome GPT-Image-2 Workbench |
|---|---|---|
| Prompt 使用方式 | 一次性输入，重复率高 | 模板化 + 变量化，适合长期复用 |
| 参考图流程 | 通常比较零散 | 直接集成到工作台里 |
| 结果回看 | 常常没有历史 | 保留最近生成记录 |
| 模板沉淀 | 基本靠手工复制粘贴 | 有后台统一管理 |
| 上游接口 | 常常写死在前台或需要用户自己填 URL | 后台统一配置，前台只显示服务名称 |
| Token 使用 | 常常只有全站统一 Key | 支持后台平台 Token，也支持用户个人 Token |
| 上线方式 | 多数只是演示页 | 可本地用，也可 Docker / PM2 / Node 部署 |
| 持久化 | 往往没有 | 默认 SQLite 持久化 |
相比普通的图像生成页面，这个项目更适合长期使用，因为它解决的是 “持续创作与团队复用”，而不只是一次性的试验。
你可以把它理解成：
- 给个人创作者准备的 AI 图像工作台
- 给设计 / 运营团队准备的模板化出图工具
- 给需要私有部署的用户准备的可控型图像前端
它的核心优势不是“功能多”，而是 把常见出图动作串成了一条顺手的工作流：
- 先选模板或直接写 Prompt
- 需要时上传本地截图作为参考图
- 调整参数并生成
- 回看结果、继续修改
- 把高质量玩法沉淀进后台模板库
这个项目尤其适合下面这些人：
- 内容创作者：需要稳定产出海报、封面、社媒配图
- 设计师：想快速验证视觉方向，或基于参考图继续迭代
- 产品经理：想快速生成 UI 概念图、产品展示图、活动视觉草案
- 运营团队：想把常用 AI 出图玩法模板化、流程化
- 开发者 / 独立站长：想把 GPT-Image-2 能力部署成自己的工作台
以下预览图均为 PC 桌面端宽屏截图。
| 工作台首页 | 模板库 |
|
 |
| 后台登录页 | 后台管理页 |
 |
 |
如果你还在想“这个项目具体适合拿来干嘛”，下面这些就是非常典型的落地方式：
适合：
- 小红书封面
- 公众号配图
- 活动海报
- 宣传长图
- 短视频封面
优势在于：
- 可把高频玩法沉淀成模板
- 运营同学可以直接复用
- 不需要每次重新从零写 Prompt
适合：
- SaaS 控制台概念图
- App 页面草图
- 活动页视觉方向图
- 产品首页展示图
优势在于：
- 可以先用模板快速起稿
- 也可以上传现有截图继续改
- 更适合“先出方向，再逐步细化”的工作方式
适合：
- 已有海报二次改版
- 基于截图做视觉升级
- 商品图换风格
- 保留主体不变，仅调整背景、灯光或材质
这类需求如果只靠纯文生图，往往不稳定；而参考图模式会更接近真实工作流。
适合：
- 把高质量 Prompt 统一沉淀
- 让团队成员共享模板
- 统一输出风格和结构
- 避免“只有某一个人会写 Prompt”的情况
这也是这个项目和普通 AI 出图页最大的差别之一。
当前项目已经具备：
- 工作台
- 模板库
- 本地截图 / 参考图编辑
- 后台模板 CRUD
- SQLite 持久化
- Docker / PM2 / Node 部署
后续可以继续增强的方向包括：
- 模板导入 / 导出 / 备份
- 后台模板分页、排序、筛选
- 模板草稿 / 发布状态
- 更完整的后台管理页截图与帮助文档
- 更细的权限控制
- 更丰富的模板分类与推荐逻辑
如果你准备把它长期作为团队工具使用，这些方向都值得继续迭代。
不是。
如果你只是本地 npm run dev，看起来像前端项目；
但如果你要：
- 使用后台
/rhz - 在线保存模板
- 使用 SQLite 持久化
那它本质上就是一个 前端 + Node 服务 + 本地数据库 的可部署应用。
适合一部分场景，但不适合全部场景。
如果你只是：
- 展示页面
- 使用构建时模板快照
那纯静态部署可以。
但如果你要：
- 在线进入后台新增模板
- 让模板真正持久化保存
那就必须使用：
- Docker
- PM2
- Node 服务
因为它强调的是：
- 模板复用
- 工作流连续性
- 结果回看
- 后台管理
- 可部署与可持久化
也就是说，它解决的是“日常持续生产”，而不是“一次性试玩”。
这份文档按 “小白也能照着做” 的目标来写。
如果你只关心怎么部署，请直接看：
如果你准备开始部署，这 4 条是最关键的：
- 本地试用最简单：执行
npm install和npm run dev即可打开工作台 - 后台
/rhz不是纯静态能力：如果你想上线后还能在线新增、编辑、删除模板，就必须运行 Node 服务 - 推荐部署方式是 Docker：对小白最省心，且 SQLite 数据最容易持久化保留
- 纯静态部署只能用构建时快照：适合展示，不适合把后台当在线 CMS 使用
如果你还没看前面的项目介绍，建议先快速浏览这些部分：
默认情况下，这个项目会用到两个常见端口：
- 5175：本地开发时的 Vite 端口
- 3000：生产服务 / Docker / PM2 默认端口
如果这两个端口被占用，或者你想统一改成自己的端口，可以按下面方法修改。
本地开发端口写在：
vite.config.js
当前默认配置是：
server: {
port: 5175,
strictPort: true
}如果你想改成 5180，就改成：
server: {
port: 5180,
strictPort: true
}然后重新执行：
npm run dev新的访问地址就会变成：
- 工作台：
http://localhost:5180/ - 后台：
http://localhost:5180/rhz
strictPort: true的意思是：如果端口被占用，Vite 不会自动跳到别的端口，而是直接报错。这样更适合固定文档地址和本地联调。
生产服务端口来自环境变量：
PORT
服务入口里实际读取的是：
server.mjs
const port = Number(process.env.PORT || 3000);也就是说，不设置时默认就是 3000。
Windows PowerShell：
$env:PORT="3100"
npm startLinux / macOS：
export PORT="3100"
npm start启动后访问：
http://localhost:3100/http://localhost:3100/rhz
修改：
ecosystem.config.cjs
把：
PORT: 3000,改成：
PORT: 3100,然后重启：
pm2 restart awesome-gpt-image-2Docker 需要同时注意两层端口：
- 容器内部端口
- 宿主机映射端口
当前 docker-compose.yml 默认是：
ports:
- "127.0.0.1:3000:3000"
environment:
PORT: 3000这表示：
- 宿主机
127.0.0.1:3000 - 映射到容器内
3000 - 应用本身也监听
3000
例如你想让宿主机访问地址变成 3100，而容器内部仍然保持 3000，改成：
ports:
- "127.0.0.1:3100:3000"
environment:
PORT: 3000这样改动最小，通常也最推荐。
启动后访问：
http://127.0.0.1:3100/
例如改成全部使用 3100：
ports:
- "127.0.0.1:3100:3100"
environment:
PORT: 3100这样容器内外都改成 3100。
修改后重新启动：
docker compose up -d --build假设你把 Docker 改成：
ports:
- "3100:3000"那外部访问地址通常就是：
http://你的服务器IP:3100/
如果你再配了 Nginx / Caddy 反向代理，也可以把用户访问入口继续统一到 80 / 443，而应用本身保持在 3000 或 3100。
改完端口后，建议顺手检查这些地方：
- README 里的访问地址是否需要同步
- Docker 映射端口是否和你的防火墙规则一致
- Nginx / Caddy 反向代理目标端口是否同步修改
- 宝塔 / 面板 / 云服务器安全组是否开放了新端口
- 如果你收藏了后台地址，记得同步更新
/rhz
如果你只是端口冲突，推荐这样处理：
- 本地开发：改
vite.config.js里的5175 - Docker 部署：优先只改宿主机映射端口，例如
3100:3000 - PM2 / Node 部署：改
PORT
这样改动最少，也最不容易把配置弄乱。
先别急着部署，先判断你属于哪一种情况：
用这个：
npm install
npm run dev适合：
- 本地开发
- 本机测试
- 临时使用
访问地址：
- 工作台：
http://localhost:5175/ - 模板后台：
http://localhost:5175/rhz
推荐用 Docker。
这是最省心、最适合小白的方案，因为：
- 不容易受本机 Node 环境影响
.env会自动注入容器- SQLite 数据库可直接挂载到宿主机目录持久化
- 重启容器后模板不会丢
看这里：
推荐用 PM2，比直接 npm start 稳定，适合长期运行。
看这里：
例如：
- 只会上传
dist - 没有 Node 服务进程
- 没有 Docker
- 没有数据库运行环境
这种情况下只能走 纯静态部署。
它的特点是：
- 页面能打开
- 模板能显示
- 但
/rhz后台不能在线写入数据库
看这里：
如果你是第一次部署这个项目，优先选 Docker。
至少准备以下 4 样东西：
- 一台电脑或服务器
- 已安装 Docker 和 Docker Compose
- 平台默认 Token（可先用
OPENAI_API_KEY配置） - 一个你自己设置的后台密码
进入项目根目录，应该能看到这些文件：
package.jsonDockerfiledocker-compose.yml.env.example
把 .env.example 复制成 .env。
Windows PowerShell：
Copy-Item ".env.example" ".env"Linux / macOS：
cp .env.example .env然后编辑 .env，至少保证下面这些值正确：
OPENAI_API_KEY=你的平台默认Token
TEMPLATE_ADMIN_PASSWORD=你自己设置的后台密码
OPENAI_IMAGE_REQUEST_TIMEOUT_MS=180000
TEMPLATE_STORE_DRIVER=sqlite
TEMPLATE_DATABASE_PATH=runtime-data/templates.sqlite这几个变量的含义：
OPENAI_API_KEY：平台默认 Token；普通用户没有填写个人 Token 时会使用它TEMPLATE_ADMIN_PASSWORD：访问/rhz后台时输入的密码OPENAI_IMAGE_REQUEST_TIMEOUT_MS：图片生成请求超时时间，默认180000毫秒（3 分钟）TEMPLATE_STORE_DRIVER=sqlite：模板库存储驱动，推荐保持 sqliteTEMPLATE_DATABASE_PATH：SQLite 数据库文件位置
如果你不想改环境变量，也可以进入后台 /rhz，在 接口设置 里维护：
- 上游 API 名称，例如
R-API - 上游生图接口地址
- 上游编辑接口地址
- 平台默认 Token
- 请求超时时间和队列并发数
后台保存的接口设置会优先于环境变量生效；普通前台用户只能使用后台设置好的上游 API，前台只展示上游 API 名称，不展示真实接口地址。
在项目根目录执行：
docker compose up -d --build第一次启动会做这些事：
- 构建前端
- 构建镜像
- 启动 Node 服务
- 创建并使用 SQLite 数据库
- 把运行时数据放到
runtime-data/
当前 docker-compose.yml 默认是：
ports:
- "127.0.0.1:3000:3000"这表示：
- 只能本机访问
- 宿主机外部网络默认访问不到
打开：
- 工作台：
http://127.0.0.1:3000/ - 后台：
http://127.0.0.1:3000/rhz
把 docker-compose.yml 里的这行：
- "127.0.0.1:3000:3000"改成：
- "3000:3000"然后重启：
docker compose up -d --build这时可通过：
http://你的服务器IP:3000/
访问。
更推荐的做法：仍然保持只监听本机，然后用 Nginx/Caddy 反向代理到
127.0.0.1:3000。这样更安全。
Docker 方案里，数据会保存在宿主机目录：
runtime-data/templates.sqlite：模板数据库runtime-data/images/uploads/：上传的模板封面或相关文件
只要你不要删除 runtime-data/，模板就不会因为容器重启而消失。
查看容器状态：
docker compose ps查看日志：
docker compose logs -f重启：
docker compose restart停止：
docker compose down再次启动：
docker compose up -d更新代码后重新构建：
docker compose up -d --build优先选 Docker，如果你符合以下任意一条：
- 不熟悉 Node 环境
- 想少踩环境坑
- 想稳定上线
- 想要模板后台在线可写
- 想保留 SQLite 数据库
如果你没有 Docker，也可以部署。
但请注意：对小白来说，这条路比 Docker 更容易踩坑。
当前项目生产启动命令是：
npm start它实际执行的是：
node server.mjs这意味着：
- 生产环境下不是 Vite dev server
- 必须先执行
npm run build - 需要你自己保证环境变量已经存在
尤其要注意：裸 npm start 不会像 Docker 那样自动帮你处理整套部署环境。
所以如果你是小白，仍然建议优先回到 Docker 方案。
先检查版本：
node -v要求：
- Node.js
>= 22
如果版本低于 22，请先升级，否则 SQLite 相关能力可能不可用。
npm install
npm run build至少需要这些变量：
OPENAI_API_KEY（平台默认 Token，可后续在后台接口设置里覆盖）TEMPLATE_ADMIN_PASSWORDHOSTPORTWORKBENCH_DATA_DIRTEMPLATE_STORE_DRIVERTEMPLATE_DATABASE_PATH
$env:OPENAI_API_KEY="你的平台默认Token"
$env:TEMPLATE_ADMIN_PASSWORD="你自己设置的后台密码"
$env:HOST="0.0.0.0"
$env:PORT="3000"
$env:WORKBENCH_DATA_DIR="runtime-data"
$env:TEMPLATE_STORE_DRIVER="sqlite"
$env:TEMPLATE_DATABASE_PATH="runtime-data/templates.sqlite"
npm startexport OPENAI_API_KEY="你的平台默认Token"
export TEMPLATE_ADMIN_PASSWORD="你自己设置的后台密码"
export HOST="0.0.0.0"
export PORT="3000"
export WORKBENCH_DATA_DIR="runtime-data"
export TEMPLATE_STORE_DRIVER="sqlite"
export TEMPLATE_DATABASE_PATH="runtime-data/templates.sqlite"
npm start启动后访问：
http://你的服务器IP:3000/http://你的服务器IP:3000/rhz
PM2 适合：
- 想让服务常驻运行
- 想断线后自动拉起
- 想开机自动启动
- 想方便查看日志
npm install -g pm2npm install
npm run build当前项目自带：
ecosystem.config.cjs
它已经内置了这些默认值：
HOST=0.0.0.0PORT=3000WORKBENCH_DATA_DIR=runtime-dataTEMPLATE_STORE_DRIVER=sqliteTEMPLATE_DATABASE_PATH=runtime-data/templates.sqlite
但你仍然需要自己提供：
OPENAI_API_KEY（平台默认 Token，可后续在后台接口设置里覆盖）TEMPLATE_ADMIN_PASSWORD
最简单的做法是先在当前终端设置，再启动 PM2。
$env:OPENAI_API_KEY="你的平台默认Token"
$env:TEMPLATE_ADMIN_PASSWORD="你自己设置的后台密码"
pm2 start ecosystem.config.cjsexport OPENAI_API_KEY="你的平台默认Token"
export TEMPLATE_ADMIN_PASSWORD="你自己设置的后台密码"
pm2 start ecosystem.config.cjs常用命令：
查看状态：
pm2 status查看日志：
pm2 logs awesome-gpt-image-2重启：
pm2 restart awesome-gpt-image-2停止：
pm2 stop awesome-gpt-image-2删除进程：
pm2 delete awesome-gpt-image-2默认在：
runtime-data/templates.sqlite
如果你没设置 WORKBENCH_DATA_DIR，也可能落到：
data/templates.sqlite
建议生产环境统一用：
runtime-data/templates.sqlite
这样更清晰，也更方便做备份。
这是最容易误解的地方，请认真看。
指的是你只上传：
dist/
到静态托管平台，例如某些：
- 静态网站托管
- OSS 静态站点
- 只托管前端文件的平台
这种方式没有长期运行的 Node 服务，也就没有在线 SQLite 写入能力。
可以：
- 正常打开页面
- 使用工作台前端
- 读取 build 时带进去的模板快照
不能：
- 在线通过
/rhz把模板真正写进 SQLite - 在线新增模板后立刻永久保存到服务器数据库
因为纯静态部署只能发布构建时快照。
正确流程是：
- 在本地或有后端能力的环境里打开
/rhz - 保存模板
- 执行
npm run build - 把新的
dist/上传上线
这样模板会作为构建快照一起发布。
如果你跳过了“本地保存 + 重新 build”这一步，线上就不会有新模板。
适合：
- 模板很少改
- 只想展示成品
- 不需要在线后台运营
不适合：
- 需要运营人员在线管理模板
- 需要上线后直接在后台新增/编辑模板
- 需要数据库级持久化
后台地址固定为：
/rhz
例如：
- 本地开发：
http://localhost:5175/rhz - Docker/生产：
http://你的域名或IP:3000/rhz
后台默认不会显示在导航里，这是故意设计的。
后台密码由服务端环境变量控制：
TEMPLATE_ADMIN_PASSWORD=你自己设置的后台密码如果这个值没设置，或者你启动服务时没有把它注入进去，就会出现：
- 无法登录后台
- 登录状态异常
进入后台 /rhz 后，可以在 接口设置 区域统一维护图片生成服务。
建议按下面方式配置：
上游 API 名称：前台展示给用户看的名称，例如R-API上游生图接口地址：兼容 OpenAI Images generations 的接口地址上游编辑接口地址：兼容 OpenAI Images edits 的接口地址API Token：平台默认 Token，普通用户不填个人 Token 时使用请求超时时间：上游响应较慢时可适当调大队列并发数：控制同时处理多少个用户任务单任务分图并发数：控制一次生成多张图时单个任务内部的并发请求数
保存后，新提交的生图任务会使用最新接口设置。前台不会让普通用户修改上游地址，只会显示这里配置的上游 API 名称。
如果你希望上游固定为 R-API，可以这样填：
上游 API 名称：R-API
上游生图接口地址：https://new.rhzhz.cn/v1/images/generations
上游编辑接口地址：https://new.rhzhz.cn/v1/images/edits
如果你的上游服务给出的路径不是上面这种格式，以服务商实际文档为准。这里的关键原则是：地址只在后台配置，前台不开放给普通用户改。
普通用户在前台点击 设置，可以看到：
- 当前图片服务：只读显示后台配置的上游 API 名称
- 个人 Token（可选）：用户自己的 Token
使用规则：
- 用户填写个人 Token：本次和后续生图会优先使用该用户自己的 Token
- 用户不填写个人 Token：使用后台接口设置里的平台默认 Token
- 用户清空个人 Token：恢复使用平台默认 Token
个人 Token 只保存在当前用户浏览器本地，不会写入模板库，也不会出现在生成历史或公开模板快照里。
默认保存到 SQLite：
- 本地默认：
data/templates.sqlite - 生产推荐：
runtime-data/templates.sqlite
如果项目里存在旧文件：
data/custom-templates.json
或：
${WORKBENCH_DATA_DIR}/custom-templates.json
服务第一次访问模板接口时会自动尝试迁移到 SQLite。
后台支持从提示词自动提取模板变量，当前可识别的形式包括：
{{产品名}}[背景风格]{argument name="口号" default="限时优惠"}
如果你在后台编辑模板时没有手动配置变量，可以使用：
- 从提示词映射变量
按钮快速生成。
/
/rhz
/images/uploads/...
最关键的是备份：
runtime-data/templates.sqlite
如果你上传过模板封面，也建议一并备份：
runtime-data/images/uploads/
备份数据库：
Copy-Item "runtime-data/templates.sqlite" "runtime-data/templates.sqlite.bak"备份整个运行目录：
Copy-Item "runtime-data" "runtime-data-backup" -Recurse备份数据库：
cp runtime-data/templates.sqlite runtime-data/templates.sqlite.bak备份整个运行目录：
cp -r runtime-data runtime-data-backup- 用你自己的方式替换为最新代码
- 确认
runtime-data/还在 - 重新执行：
docker compose up -d --build- 用你自己的方式替换为最新代码
- 保留
runtime-data/ - 重新安装依赖并构建：
npm install
npm run build- 重启服务：
pm2 restart awesome-gpt-image-2如果你不是 PM2，而是手工跑的 npm start，那就停止旧进程后重新启动。
如果你有自己的域名，推荐让 Nginx 代理到：
127.0.0.1:3000
这样可以：
- 不把 3000 端口直接暴露给公网
- 更容易接 HTTPS
- 更安全
示例 Nginx 配置：
server {
listen 80;
server_name your-domain.com;
location / {
proxy_pass http://127.0.0.1:3000;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}如果你还没接触过 Nginx，可以先忽略这一节，先把 Docker 方案跑通。
这一节是写给真正准备上线的人看的。
如果你只是本地测试，可以先跳过。
最推荐的结构是：
- 项目服务跑在本机端口，例如：
127.0.0.1:3000- 或
127.0.0.1:3100
- 再用 Nginx / Caddy / 面板反向代理到你的域名
- 最后给域名开 HTTPS
也就是说，用户访问的是：
https://你的域名/
而不是直接访问：
http://你的服务器IP:3000/
这样做的好处：
- 更安全
- 更适合正式对外使用
- 更容易配置 HTTPS
- 不需要把应用端口直接暴露到公网
对小白来说，建议按这个顺序走：
- 先在本机确认项目能跑起来
- 再确认 Docker / PM2 服务能稳定启动
- 再确认数据库文件会正常保存
- 最后再接域名和 HTTPS
不要一上来就先折腾域名，否则问题会很难定位。
如果你用的是 宝塔面板，最常见的做法有两种：
如果你的宝塔环境已经安装了 Docker / Docker Compose，这个方案最省心。
基本流程：
- 把项目代码上传到服务器
- 在项目目录准备好
.env - 执行：
docker compose up -d --build- 确认项目已经跑在：
127.0.0.1:3000
或你自定义的端口上
- 在宝塔网站里添加一个站点
- 给这个站点配置反向代理，目标指向：
http://127.0.0.1:3000
- 再申请 SSL 证书
这样用户就可以通过域名访问，而不是直接访问端口。
如果你不用 Docker，也可以：
- 在服务器安装 Node 22+
- 上传项目代码
- 执行：
npm install
npm run build- 用 PM2 启动：
pm2 start ecosystem.config.cjs- 确认服务监听在：
127.0.0.1:3000- 或你设置的
PORT
- 在宝塔站点里做反向代理
- 配置 SSL
如果你是第一次上线，仍然更推荐 方案 A：宝塔 + Docker。
不管你用的是：
- 1Panel
- aaPanel
- 宝塔
- 其他面板
整体思路其实都一样：
- 让项目先跑在一个本地端口
- 用面板创建站点或反向代理
- 域名指向服务器 IP
- 给域名加 HTTPS
你真正需要关心的只有两件事：
- 项目实际跑在哪个端口
- 面板反向代理有没有正确指向这个端口
如果你已经买了域名，通常要做的是：
- 到域名服务商后台
- 添加一条
A记录 - 让域名指向你的服务器公网 IP
例如：
- 主机记录：
@ - 记录类型：
A - 记录值：
你的服务器公网IP
如果你想让 www 也能访问，再加一条：
- 主机记录：
www - 记录类型：
A - 记录值：
你的服务器公网IP
然后等待解析生效。
如果你用：
- 宝塔
- 1Panel
- Caddy
- Nginx + Let's Encrypt
一般都可以直接申请免费证书。
上线建议：
- 后台和前台都统一走 HTTPS
- 不要让用户长期使用
http://IP:端口
这样更专业，也更安全。
通常是：
- 应用根本没启动
- 反向代理指错端口
- Docker 容器没起来
通常是：
- 你部署成了纯静态站点
- 没有真正运行 Node 服务
- 数据目录没有持久化
通常是：
- 面板反向代理还是旧端口
- 防火墙没开放新端口
- 你改的是宿主机端口，但代理还是指向旧值
通常是：
- 没挂载
runtime-data - 数据库文件没放在持久目录
- 容器重建后用了新空目录
如果你希望：
- 最少踩坑
- 后台可在线保存模板
- 后续方便迁移和备份
我推荐你优先用：
Docker + runtime-data 持久化 + 域名反向代理 + HTTPS
这是当前项目最稳定、最适合长期使用的上线方式。
现象：
- 启动失败
- build 失败
- SQLite 相关能力异常
处理：
- 升级 Node 到 22 或更高版本
原因通常是：
HOST没设成0.0.0.0- 服务只监听了
127.0.0.1
处理：
- 设置
HOST=0.0.0.0 - 或直接用 Docker / PM2
先检查 docker-compose.yml 的端口映射是不是：
- "127.0.0.1:3000:3000"如果是，这代表只允许本机访问。
如果你想让别人访问，改成：
- "3000:3000"然后重新：
docker compose up -d --build先检查：
TEMPLATE_ADMIN_PASSWORD是否设置了- 服务重启后是否读取到了新值
Docker 方式改完 .env 后，记得重新启动容器：
docker compose up -d --buildPM2 方式改完环境变量后，记得重启：
pm2 restart awesome-gpt-image-2这几乎总是因为你部署的是纯静态站点。
记住：
- 在线可写后台 需要 Node/Docker/PM2
- 纯静态部署 只能读取构建时模板快照
如果你用的是纯静态部署，请按这个流程：
- 本地后台保存模板
npm run build- 上传新的
dist/
说明你直接启动了生产服务，但还没构建。
先执行：
npm run build再启动：
npm start这是 Node 运行时对 node:sqlite 的提示，不是报错。
只要程序正常启动、模板正常保存，就可以忽略。
这是当前设计要求：
- 后台不显示在导航
- 需要手动访问
/rhz
这是图片同步的正常中间状态。
后端任务完成只代表上游已经返回结果；前端还需要把图片读取出来并写入本地图片走廊。这个阶段前台会短暂显示“图片同步中...”，图片读到后会自动进入结果区和图片走廊。
如果长时间没有出现，可以优先检查：
- 上游接口是否真的返回了图片数据，而不是网页或错误 JSON
- 后台接口设置里的生图地址和编辑地址是否填对
- 当前 Token 是否仍有额度或权限
- 浏览器本地存储空间是否已满
server.mjs
scripts/workbench-api.mjs
scripts/template-store-backend.mjs
scripts/generate-custom-template-store.mjssrc/data/custom-template-store.generated.js
runtime-data/
data/templates.sqlite
即使这是你自己用的项目，也建议至少做到这几点：
- 把
TEMPLATE_ADMIN_PASSWORD设置成强密码 - 不要把平台默认 Token 写进前端代码，只放在服务端环境变量或后台接口设置里
- 前台只展示上游 API 名称，不要向普通用户暴露真实上游地址
- 如果公网部署，优先使用反向代理 + HTTPS
- 定期备份
runtime-data/templates.sqlite - 如果不是必须，不要直接把 3000 端口裸露到公网
如果你只想用最少步骤跑起来，直接照着做：
npm install
npm run dev打开：
http://localhost:5175/http://localhost:5175/rhz
- 安装 Docker
- 复制
.env.example为.env - 填好
OPENAI_API_KEY和TEMPLATE_ADMIN_PASSWORD - 执行：
docker compose up -d --build- 打开：
http://127.0.0.1:3000/http://127.0.0.1:3000/rhz
进入 /rhz 后，可以在 接口设置 里继续把上游 API 名称改成 R-API，并填写实际的上游接口地址和平台默认 Token。普通用户前台只能看到服务名称，也可以在前台设置里填写自己的个人 Token。
如果要外网访问，再把 docker-compose.yml 的端口映射改成：
- "3000:3000"然后重新执行：
docker compose up -d --build本项目的 UI 表达、模板库展示思路与部分信息组织方式，参考了：
在此基础上，当前项目继续往“可部署、可管理、可长期使用”的方向做了增强，包括：
- 独立的图片工作台
- 本地截图 / 参考图编辑入口
- 隐藏后台
/rhz - SQLite 模板持久化
- 模板 CRUD 与变量自动映射
- Docker / PM2 / Node 服务部署支持
图片生成任务通常比普通接口慢，建议通过后台 /rhz 的 接口设置 来调整超时时间和并发数。
请求超时时间：控制单次请求最多等待多久，默认 180 秒队列并发数：控制同时处理多少个用户任务，允许 1 到 4单任务分图并发数：控制一次生成多张图时单个任务内部同时请求多少张，允许 1 到 4
如果是 4 核 4G 左右的轻量服务器，建议先使用：
队列并发数：2
单任务分图并发数：2
请求超时时间：60 到 180 秒
如果上游接口响应稳定、服务器资源充足，再逐步调高并发数。不要一开始就把两个并发值都拉满，避免上游限流或服务器内存压力过大。