Vite Proxy 只存在于开发环境，正式上线后谁来转发 /api？

开发环境不等于正式环境

正式环境通常不会运行 npm run dev。

开发环境的运行方式 ≠ 正式环境的部署方式

项目组织

代码放在同一个目录，不代表上线时是一个应用。

前后端是否放在同一个仓库，要看团队规模和工程管理方式。关键不在“目录是否分开”，而在它们应该被视为两个独立构建、独立运行、独立发布的应用。

构建产物

前端产物和后端产物不是一类东西。

正式环境请求链路

Nginx 提供前端文件，也转发后端 API。

server {
    listen 80;
    server_name album.example.com;

    root /usr/share/nginx/html;
    index index.html;

    location /api/ {
        proxy_pass http://album-api:8080;
    }

    location / {
        try_files $uri $uri/ /index.html;
    }
}

Nginx 不是用来替代 Go 后端，而是作为静态资源服务器和统一请求入口。浏览器看到同一个域名，内部请求由 Nginx 分发。

先把 Nginx 跑起来

用 Docker 一条命令启动一个 Nginx。

先不急着写 Dockerfile。先用现成的 Nginx 镜像，把“静态文件目录”和“Nginx 配置”挂进去，让浏览器能访问到前端构建产物。

docker run -d \
  --name album-nginx \
  -p 8081:80 \
  -v ./frontend/dist:/usr/share/nginx/html:ro \
  -v ./nginx.conf:/etc/nginx/conf.d/default.conf:ro \
  nginx:1.27-alpine

这个命令适合理解 Nginx 的运行方式，但它不是最终交付形态。正式发布时，更常见的做法是把构建产物和配置打进镜像，形成可版本化、可发布、可回滚的前端镜像。

Docker 镜像

为什么还需要 Dockerfile？

它回答的不是“这段代码怎么写”，而是：这个应用最终应该以什么环境、什么文件、什么命令运行。AI 可以生成 Dockerfile，但你必须能看懂它把哪些东西带进了最终镜像。

审查 Dockerfile

AI 可以生成配置，但你要知道最终镜像里有什么。

配置与镜像分离

同一个镜像，使用不同环境配置。

测试环境和生产环境数据库地址不同，不应该分别构建两个后端镜像。镜像负责“应用是什么”，运行时配置负责“应用连接哪里”。

React 的 VITE_ 环境变量通常会在构建时写入前端产物，因此不能包含秘密。

独立发布

前后端分离的关键，是可以独立构建、发布和回滚。

更安全的方式是新增字段而不是立即删除旧字段，新旧版本短期兼容，接口变更经过评审，并明确发布顺序。

CI/CD

发布不是执行几条命令，而是一条可重复的链路。

数据库变更边界

CI/CD 不能在服务启动时执行 GORM AutoMigrate。

Docker 镜像成功构建，不代表已经可以上线。上线还要考虑镜像版本、环境配置、数据库变更、健康检查、日志、回滚、密钥注入和前后端兼容。

给 AI 的工程约束

不要只说“生成一个 Dockerfile”。

请为当前项目生成正式环境构建方案。

项目情况：
- 前端使用 React、TypeScript 和 Vite
- 后端使用 Go 和 Gin
- 前端和后端分别构建 Docker 镜像
- 前端由 Nginx 提供静态资源
- Nginx 将 /api 转发到后端服务
- 浏览器不能直接访问后端内部端口

工程要求：
1. 前后端都使用多阶段 Docker 构建。
2. 尽量利用 Docker 构建缓存。
3. 最终镜像中不保留源码和编译工具。
4. 不把 .env、密码或 AccessKey 打入镜像。
5. 前端不能运行 Vite 开发服务器。
6. Nginx 需要处理 React 路由刷新。
7. Go 后端不使用 AutoMigrate。
8. 输出 Dockerfile、.dockerignore 和 Nginx 配置。
9. 解释每个关键工程决策。