Spring Boot + Vue.js 构建 GPT AI 聊天应用：架构设计、核心实现与部署实践

<p>在 AI 应用快速普及的背景下，很多开发者都希望搭建一个属于自己的 GPT 聊天系统：既能接入多家大模型平台，又能提供稳定的 Web 交互体验，还要具备用户体系、会话记录、后台管理和生产环境部署能力。</p>
<p>本文将围绕一个基于 <strong>Spring Boot + Vue.js</strong> 的 GPT AI 聊天应用，系统梳理从技术选型、项目架构、核心功能到线上部署的完整实现思路。它不是一个简单的接口调用 Demo，而是一个具备完整业务闭环的前后端分离 AI 应用实践。</p>
<h2>一、项目定位与技术选型</h2>
<p>这个项目的目标是实现一个可在线访问的 AI 聊天平台，支持文本对话、图像生成、用户登录、会话管理、使用统计以及管理员后台等功能。</p>
<p>整体采用典型的前后端分离架构：后端负责 API 服务、模型适配、数据持久化与权限控制；前端负责聊天交互、状态管理、页面渲染和用户体验。</p>
<h3>1. 后端技术栈</h3>
<p>后端主要使用：</p>
<ul><li><strong>Spring Boot 3.x</strong>：提供 Web 服务和业务接口</li><li><strong>Java 17</strong>：作为主要开发语言</li><li><strong>JPA / Hibernate</strong>：负责 ORM 映射与数据访问</li><li><strong>SQLite</strong>：用于轻量级数据持久化</li><li><strong>SSE（Server-Sent Events）</strong>：实现 AI 回复的流式输出</li></ul>
<p>SQLite 对于课程项目、个人项目或中小规模演示系统非常友好，部署简单，不需要额外维护数据库服务。如果后续用户量上升，也可以平滑迁移到 MySQL、PostgreSQL 等数据库。</p>
<h3>2. 前端技术栈</h3>
<p>前端主要使用：</p>
<ul><li><strong>Vue.js 3</strong>：构建单页应用</li><li><strong>Vite</strong>：提升开发和构建效率</li><li><strong>Pinia</strong>：管理用户信息、模型配置和会话状态</li><li><strong>JavaScript ES6+</strong>：完成 API 封装和交互逻辑</li></ul>
<p>相比传统 Vuex，Pinia 的写法更加简洁，组合式开发体验也更好，适合用于现代 Vue 3 项目。</p>
<h3>3. AI 平台接入</h3>
<p>项目支持多个主流 AI 平台，包括：</p>
<ul><li>OpenAI GPT 系列模型</li><li>阿里云通义千问、通义万相</li><li>DeepSeek</li><li>豆包</li><li>Kimi</li></ul>
<p>在设计上，项目没有把某一个模型供应商写死，而是通过统一接口和适配器机制完成平台切换。这一点对于 AI 应用非常关键，因为大模型生态变化很快，保持可扩展性比单次接入更重要。</p>
<h2>二、整体项目架构</h2>
<p>项目可以拆分为两个主要模块：</p>
<pre><code class="language-text">GPT-AI-Project/
├── backend/              # Spring Boot 后端服务
│   ├── controller/       # REST API 控制器
│   ├── service/          # 业务逻辑层
│   ├── entity/           # 数据实体
│   ├── config/           # 配置类
│   └── adapter/          # AI 平台适配器
└── frontend/             # Vue.js 前端应用
    ├── components/       # 通用组件
    ├── views/            # 页面视图
    ├── api/              # API 请求封装
    └── store/            # Pinia 状态管理</code></pre>
<p>这种分层结构的好处是职责清晰：</p>
<ul><li><strong>Controller 层</strong>负责接收前端请求</li><li><strong>Service 层</strong>负责业务编排</li><li><strong>Adapter 层</strong>负责对接不同 AI 平台</li><li><strong>Entity 层</strong>负责数据模型定义</li><li><strong>前端 API 层</strong>统一管理请求逻辑</li><li><strong>Store 层</strong>维护全局状态</li></ul>
<p>对于后期维护来说，这种架构比把所有逻辑写在控制器或页面组件中更可靠。</p>
<h2>三、后端核心设计</h2>
<h2>1. 多 AI 平台的统一入口</h2>
<p>AI 聊天应用最容易踩的坑之一，是在业务代码里直接写某个厂商的接口调用逻辑。这样前期看似简单，但一旦需要增加新平台，就会导致代码分支越来越混乱。</p>
<p>更合理的方式是采用类似适配器模式的设计：前端只需要传入 <code>platform</code> 和 <code>model</code>，后端根据平台类型选择对应的服务实现。</p>
<p>示例思路如下：</p>
<pre><code class="language-java">@RestController
@RequestMapping("/api/ai")
public class AiController {

@GetMapping("/chat/text/stream")
    public SseEmitter streamChat(String platform, String model, String message) {
        return aiServiceFactory.getService(platform)
                .streamChat(model, message);
    }
}</code></pre>
<p>这里的重点不是代码本身，而是设计思路：</p>
<ul><li>前端不关心具体 AI 厂商的 API 差异</li><li>后端通过工厂或策略模式选择服务</li><li>新增平台时，只需要增加新的适配器实现</li><li>统一返回格式，降低前端适配成本</li></ul>
<p>这类设计能够显著提升系统的可维护性。</p>
<h2>2. 使用 SSE 实现流式回复</h2>
<p>AI 聊天产品的体验很大程度取决于响应方式。如果用户必须等待完整答案生成后才能看到内容，交互会显得迟钝。更好的方式是使用流式输出，让回复像真实聊天一样逐步展示。</p>
<p>项目中使用 <strong>Server-Sent Events（SSE）</strong> 实现服务端向浏览器持续推送数据。</p>
<p>简化后的后端实现如下：</p>
<pre><code class="language-java">@PostMapping("/chat/text/stream")
public SseEmitter sendTextStream(String model, String message) {
    SseEmitter emitter = new SseEmitter(0L);

CompletableFuture.runAsync(() -> {
        try {
            aiService.sendText(model, message, true, delta -> {
                emitter.send(SseEmitter.event()
                        .name("delta")
                        .data(delta));
            });

emitter.send(SseEmitter.event()
                    .name("done")
                    .data("[DONE]"));
            emitter.complete();
        } catch (Exception e) {
            emitter.completeWithError(e);
        }
    });

return emitter;
}</code></pre>
<p>SSE 相比 WebSocket 更轻量，尤其适合 AI 文本生成这种单向流式推送场景。只要业务不是强双向实时通信，SSE 的实现成本和部署复杂度都更低。</p>
<h2>3. 会话历史与数据持久化</h2>
<p>一个完整的 GPT AI 聊天应用不能只完成“问一句、答一句”。用户通常需要查看历史对话、切换不同会话，甚至基于上下文继续提问。</p>
<p>因此，后端需要保存对话历史。核心字段通常包括：</p>
<ul><li>用户 ID</li><li>会话 ID</li><li>用户提问内容</li><li>AI 回复内容</li><li>创建时间</li><li>模型平台与模型名称</li></ul>
<p>示例实体可以抽象为：</p>
<pre><code class="language-java">@Entity
public class ConversationHistory {

@Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

private String userId;
    private String sessionId;

@Column(length = 5000)
    private String userMessage;

@Column(length = 10000)
    private String assistantReply;

private String platform;
    private String model;
    private LocalDateTime createdAt;
}</code></pre>
<p>需要注意的是，AI 回复内容可能较长，数据库字段长度要预留足够空间。若后期支持长文档分析或多轮上下文，建议进一步优化存储结构。</p>
<h2>4. 跨域配置与前后端分离支持</h2>
<p>前端和后端分离部署时，跨域问题几乎一定会遇到。开发环境通常是 <code>localhost:5173</code> 调用 <code>localhost:8083</code>，生产环境则是域名通过 Nginx 代理到后端服务。</p>
<p>后端需要配置 CORS，允许指定来源访问接口：</p>
<pre><code class="language-java">@Configuration
public class CorsConfig implements WebMvcConfigurer {

@Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/**")
                .allowedOriginPatterns("http://localhost:*", "https://your-domain.com")
                .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS")
                .allowCredentials(true);
    }
}</code></pre>
<p>生产环境中不建议直接使用全量通配符放开所有来源。更稳妥的做法是明确配置允许访问的前端域名。</p>
<h2>四、前端核心实现</h2>
<h2>1. API 请求统一封装</h2>
<p>前端不应在每个组件中重复编写请求逻辑。更好的方式是将 API 调用集中放在 <code>api</code> 目录中，页面组件只负责调用封装后的方法。</p>
<p>以流式聊天为例，前端可以使用 <code>EventSource</code> 接收 SSE 数据：</p>
<pre><code class="language-javascript">export function streamChat({ platform, model, message, onDelta, onDone, onError }) {
  const query = new URLSearchParams({ platform, model, message })
  const eventSource = new EventSource(`/api/ai/chat/text/stream?${query}`)

eventSource.addEventListener('delta', event => {
    onDelta?.(event.data)
  })

eventSource.addEventListener('done', () => {
    onDone?.()
    eventSource.close()
  })

eventSource.onerror = error => {
    onError?.(error)
    eventSource.close()
  }
}</code></pre>
<p>这样做有几个优势：</p>
<ul><li>页面组件代码更干净</li><li>方便统一处理异常</li><li>后端接口变化时只需要修改 API 层</li><li>有利于后续接入鉴权 Token、请求拦截等功能</li></ul>
<h2>2. 流式聊天界面设计</h2>
<p>聊天界面的关键在于实时更新。用户发送消息后，前端需要立即显示用户消息，同时创建一个正在生成中的 AI 消息，并随着 SSE 数据不断追加内容。</p>
<p>实现逻辑可以概括为：</p>
<ul><li>用户输入问题并点击发送</li><li>前端将用户消息加入消息列表</li><li>创建一个空的 AI 回复消息</li><li>接收后端流式片段并追加到当前消息</li><li>接收到完成事件后结束加载状态</li><li>将完整对话保存到历史记录</li></ul>
<p>在用户体验上，还应补充以下细节：</p>
<ul><li>回复生成中显示状态提示</li><li>防止重复点击发送</li><li>支持停止生成或重新生成</li><li>长内容自动滚动到底部</li><li>Markdown 内容渲染与代码高亮</li></ul>
<p>这些细节往往决定一个 AI 聊天应用是否“可用”。</p>
<h2>3. 使用 Pinia 管理全局状态</h2>
<p>项目中可以将用户信息、当前会话、模型配置、系统设置等内容放入 Pinia。</p>
<p>示例结构如下：</p>
<pre><code class="language-javascript">import { defineStore } from 'pinia'

export const useMainStore = defineStore('main', {
  state: () => ({
    user: null,
    currentSession: null,
    settings: {
      platform: 'openai',
      textModel: 'gpt-4o-mini',
      imageModel: 'dall-e-3'
    }
  }),
  actions: {
    setUser(user) {
      this.user = user
    },
    updateSettings(settings) {
      this.settings = { ...this.settings, ...settings }
    }
  }
})</code></pre>
<p>对于 AI 应用来说，模型配置通常会被多个页面共享，例如聊天页、图像生成页、用户设置页。因此，将其放入全局状态更合适。</p>
<h2>五、主要功能模块梳理</h2>
<h2>1. 多平台 AI 对话</h2>
<p>项目通过统一参数切换不同平台和模型。例如用户可以选择 OpenAI、通义千问、DeepSeek、Kimi 等模型进行对话。</p>
<p>关键设计点包括：</p>
<ul><li>统一请求入口</li><li>统一响应格式</li><li>不同平台单独适配</li><li>前端模型列表可配置</li><li>异常信息标准化返回</li></ul>
<p>这样可以避免每接入一个模型就重写一套前端逻辑。</p>
<h2>2. 图像生成能力</h2>
<p>除了文本对话，项目还支持图像生成。可接入的能力包括 OpenAI DALL-E、阿里云通义万相等。</p>
<p>常见参数包括：</p>
<ul><li>提示词</li><li>图片尺寸</li><li>生成数量</li><li>风格配置</li><li>平台与模型选择</li></ul>
<p>图像生成接口通常不是流式返回，而是任务式或同步返回。因此前端需要根据不同平台的响应特点设计加载状态和结果展示方式。</p>
<h2>3. 用户认证与权限控制</h2>
<p>用户系统是应用从 Demo 走向产品化的重要一步。基本功能包括：</p>
<ul><li>用户注册</li><li>用户登录</li><li>登录状态保持</li><li>用户数据隔离</li><li>个人设置保存</li></ul>
<p>如果系统后续开放给更多用户使用，还需要继续补充密码加密、Token 鉴权、接口限流和敏感操作校验。</p>
<h2>4. 会话管理</h2>
<p>会话管理让用户可以保留不同主题的聊天上下文，例如“代码问题”“论文润色”“产品方案”等。</p>
<p>建议的会话能力包括：</p>
<ul><li>新建会话</li><li>删除会话</li><li>重命名会话</li><li>查看历史消息</li><li>按时间排序</li><li>支持多会话切换</li></ul>
<p>对 AI 聊天应用而言，会话管理不是附加功能，而是基础体验的一部分。</p>
<h2>5. 管理员面板与统计分析</h2>
<p>管理员后台主要用于观察系统使用情况和管理用户数据。可以包含：</p>
<ul><li>注册用户列表</li><li>用户使用次数</li><li>模型调用统计</li><li>Token 使用量统计</li><li>每日请求趋势</li><li>异常请求记录</li></ul>
<p>对于个人项目来说，这些功能能够帮助开发者判断系统是否稳定，也能为后续优化模型成本提供依据。</p>
<h2>六、本地开发环境搭建</h2>
<h2>1. 后端启动流程</h2>
<p>后端启动流程相对直接：</p>
<pre><code class="language-bash">git clone <repository-url>
cd backend
mvn spring-boot:run</code></pre>
<p>核心配置通常放在 <code>application.yaml</code> 中：</p>
<pre><code class="language-yaml">server:
  port: 8083

spring:
  application:
    name: gpt-ai
  datasource:
    url: jdbc:sqlite:identifier.sqlite
    driver-class-name: org.sqlite.JDBC</code></pre>
<p>如果接入第三方 AI 平台，还需要配置对应的 API Key。建议不要将密钥硬编码在代码仓库中，可以使用环境变量或独立配置文件管理。</p>
<h2>2. 前端启动流程</h2>
<p>前端安装依赖并启动开发服务器：</p>
<pre><code class="language-bash">cd frontend
npm install
npm run dev</code></pre>
<p>开发阶段通常通过 Vite 配置代理，避免浏览器跨域限制：</p>
<pre><code class="language-javascript">export default defineConfig({
  server: {
    proxy: {
      '/api': {
        target: 'http://localhost:8083',
        changeOrigin: true
      }
    }
  }
})</code></pre>
<p>这样前端请求 <code>/api</code> 时，会自动转发到本地后端服务。</p>
<h2>七、生产环境部署方案</h2>
<p>生产部署可以采用 Nginx + Spring Boot Jar 包的方式。前端构建为静态文件，由 Nginx 提供访问；后端以 Java 服务运行，Nginx 将 <code>/api</code> 请求代理到后端端口。</p>
<h2>1. 后端打包与运行</h2>
<pre><code class="language-bash">mvn clean package -DskipTests
java -jar target/gpt-ai.jar</code></pre>
<p>实际生产环境建议使用 <code>systemd</code>、Supervisor 或容器方式托管后端进程，避免服务异常退出后无人感知。</p>
<h2>2. 前端构建与上传</h2>
<pre><code class="language-bash">npm run build</code></pre>
<p>构建完成后，将 <code>dist</code> 目录部署到服务器站点目录，例如：</p>
<pre><code class="language-text">/www/wwwroot/your-domain.com/dist</code></pre>
<h2>3. Nginx 反向代理配置</h2>
<p>Nginx 配置需要同时处理三件事：</p>
<ul><li>访问前端静态资源</li><li>将 API 请求代理到 Spring Boot</li><li>支持 Vue Router 的 History 模式</li><li>保持 SSE 长连接稳定</li></ul>
<p>示例配置如下：</p>
<pre><code class="language-nginx">server {
    listen 80;
    listen 443 ssl http2;
    server_name your-domain.com;

root /www/wwwroot/your-domain.com/dist;
    index index.html;

location /api/ {
        proxy_pass http://127.0.0.1:8083;
        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;

proxy_http_version 1.1;
        proxy_buffering off;
        proxy_cache off;
        proxy_read_timeout 3600s;
        proxy_send_timeout 3600s;
    }

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

location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg)$ {
        expires 1y;
        add_header Cache-Control "public, immutable";
    }
}</code></pre>
<p>其中 <code>proxy_buffering off</code> 和较长的 <code>proxy_read_timeout</code> 对 SSE 非常重要，否则流式对话可能会出现中断或延迟输出的问题。</p>
<h2>八、常见问题与处理建议</h2>
<h2>1. 前端请求 API 返回 404</h2>
<p>通常是 Nginx 代理规则没有命中，或前端请求路径与后端接口路径不一致。</p>
<p>建议检查：</p>
<ul><li>前端请求是否以 <code>/api</code> 开头</li><li>Nginx 是否配置了 <code>location /api/</code></li><li>后端服务端口是否正确</li><li>Spring Boot 接口路径是否匹配</li></ul>
<h2>2. SSE 回复中途断开</h2>
<p>流式输出中断多半与代理层配置有关。</p>
<p>建议检查：</p>
<ul><li><code>proxy_read_timeout</code> 是否过短</li><li>是否关闭了代理缓冲</li><li>后端是否抛出异常</li><li>浏览器网络连接是否稳定</li></ul>
<h2>3. 浏览器出现 CORS 错误</h2>
<p>跨域问题可能来自后端配置，也可能来自 Nginx 代理头设置。</p>
<p>建议检查：</p>
<ul><li>后端 CORS 是否允许当前前端域名</li><li>是否允许携带 Cookie 或认证信息</li><li>OPTIONS 预检请求是否正常响应</li><li>生产环境是否通过同域代理访问 API</li></ul>
<h2>4. Vue 页面刷新后 404</h2>
<p>如果使用 Vue Router 的 History 模式，刷新页面时 Nginx 会尝试查找真实路径，导致 404。</p>
<p>解决方式是在 Nginx 中加入：</p>
<pre><code class="language-nginx">try_files $uri $uri/ /index.html;</code></pre>
<p>这样所有前端路由都会回退到入口文件，由 Vue 接管路由解析。</p>
<h2>九、可以继续优化的方向</h2>
<p>当前项目已经覆盖了一个 GPT AI 聊天应用的主要能力，但如果要进一步产品化，还可以从以下方向扩展。</p>
<h3>1. 功能层面</h3>
<ul><li>增加语音识别和语音合成，实现语音对话</li><li>支持文件上传，用于文档问答与内容分析</li><li>增加提示词模板，提高用户使用效率</li><li>支持分享会话或导出聊天记录</li><li>增加插件机制，扩展搜索、翻译、代码解释等能力</li></ul>
<h3>2. 架构层面</h3>
<ul><li>引入 Redis 缓存用户配置和热点数据</li><li>使用消息队列处理耗时任务</li><li>增加接口限流，防止滥用</li><li>将模型调用、用户系统、统计系统拆分为独立服务</li><li>对高频接口增加监控和告警</li></ul>
<h3>3. 运维层面</h3>
<ul><li>接入日志分析系统</li><li>配置自动化部署流程</li><li>增加异常告警通知</li><li>统计模型调用成本</li><li>定期备份数据库</li></ul>
<p>对于 AI 应用来说，成本控制和稳定性同样重要。尤其是接入多个商业模型后，用量统计、权限控制和限流策略都应尽早规划。</p>
<h2>十、总结</h2>
<p>这个基于 <strong>Spring Boot + Vue.js</strong> 的 GPT AI 聊天应用，完整覆盖了现代 Web AI 产品的核心开发链路：后端接口设计、前端交互实现、多模型平台适配、会话持久化、用户体系、管理员后台以及 Nginx 生产部署。</p>
<p>我认为，这类项目最有价值的地方不只是“能调用 AI 接口”，而是把一个 AI 能力包装成了可使用、可维护、可扩展的应用系统。</p>
<p>如果你也计划开发类似的 GPT AI 聊天应用，建议重点关注三件事：</p>
<ul><li><strong>架构上要预留多模型扩展能力</strong>，不要与某个供应商深度耦合；</li><li><strong>体验上要优先做好流式输出和会话管理</strong>，这是聊天产品的基本盘；</li><li><strong>部署上要正确处理 Nginx 代理、SSE 长连接和前端路由回退</strong>，否则本地可用不代表线上稳定。</li></ul>
<p>通过 Spring Boot 的稳健后端能力与 Vue.js 的灵活前端体验，个人开发者也可以较快搭建出一个完整的 AI 聊天平台，并在此基础上继续扩展为更成熟的智能应用。</p>

在 AI 应用快速普及的背景下，很多开发者都希望搭建一个属于自己的 GPT 聊天系统：既能接入多家大模型平台，又能提供稳定的 Web 交互体验，还要具备用户体系、会话记录、后台管理和生产环境部署能力。

本文将围绕一个基于 Spring Boot + Vue.js 的 GPT AI 聊天应用，系统梳理从技术选型、项目架构、核心功能到线上部署的完整实现思路。它不是一个简单的接口调用 Demo，而是一个具备完整业务闭环的前后端分离 AI 应用实践。

一、项目定位与技术选型

这个项目的目标是实现一个可在线访问的 AI 聊天平台，支持文本对话、图像生成、用户登录、会话管理、使用统计以及管理员后台等功能。

整体采用典型的前后端分离架构：后端负责 API 服务、模型适配、数据持久化与权限控制；前端负责聊天交互、状态管理、页面渲染和用户体验。

1. 后端技术栈

后端主要使用：

Spring Boot 3.x：提供 Web 服务和业务接口
Java 17：作为主要开发语言
JPA / Hibernate：负责 ORM 映射与数据访问
SQLite：用于轻量级数据持久化
SSE（Server-Sent Events）：实现 AI 回复的流式输出

SQLite 对于课程项目、个人项目或中小规模演示系统非常友好，部署简单，不需要额外维护数据库服务。如果后续用户量上升，也可以平滑迁移到 MySQL、PostgreSQL 等数据库。

2. 前端技术栈

前端主要使用：

Vue.js 3：构建单页应用
Vite：提升开发和构建效率
Pinia：管理用户信息、模型配置和会话状态
JavaScript ES6+：完成 API 封装和交互逻辑

相比传统 Vuex，Pinia 的写法更加简洁，组合式开发体验也更好，适合用于现代 Vue 3 项目。

3. AI 平台接入

项目支持多个主流 AI 平台，包括：

OpenAI GPT 系列模型
阿里云通义千问、通义万相
DeepSeek
豆包
Kimi

在设计上，项目没有把某一个模型供应商写死，而是通过统一接口和适配器机制完成平台切换。这一点对于 AI 应用非常关键，因为大模型生态变化很快，保持可扩展性比单次接入更重要。

二、整体项目架构

项目可以拆分为两个主要模块：

GPT-AI-Project/
├── backend/              # Spring Boot 后端服务
│   ├── controller/       # REST API 控制器
│   ├── service/          # 业务逻辑层
│   ├── entity/           # 数据实体
│   ├── config/           # 配置类
│   └── adapter/          # AI 平台适配器
└── frontend/             # Vue.js 前端应用
    ├── components/       # 通用组件
    ├── views/            # 页面视图
    ├── api/              # API 请求封装
    └── store/            # Pinia 状态管理

这种分层结构的好处是职责清晰：

Controller 层负责接收前端请求
Service 层负责业务编排
Adapter 层负责对接不同 AI 平台
Entity 层负责数据模型定义
前端 API 层统一管理请求逻辑
Store 层维护全局状态

对于后期维护来说，这种架构比把所有逻辑写在控制器或页面组件中更可靠。

三、后端核心设计

1. 多 AI 平台的统一入口

AI 聊天应用最容易踩的坑之一，是在业务代码里直接写某个厂商的接口调用逻辑。这样前期看似简单，但一旦需要增加新平台，就会导致代码分支越来越混乱。

更合理的方式是采用类似适配器模式的设计：前端只需要传入 platform 和 model，后端根据平台类型选择对应的服务实现。

示例思路如下：

@RestController
@RequestMapping("/api/ai")
public class AiController {

    @GetMapping("/chat/text/stream")
    public SseEmitter streamChat(String platform, String model, String message) {
        return aiServiceFactory.getService(platform)
                .streamChat(model, message);
    }
}

这里的重点不是代码本身，而是设计思路：

前端不关心具体 AI 厂商的 API 差异
后端通过工厂或策略模式选择服务
新增平台时，只需要增加新的适配器实现
统一返回格式，降低前端适配成本

这类设计能够显著提升系统的可维护性。

2. 使用 SSE 实现流式回复

AI 聊天产品的体验很大程度取决于响应方式。如果用户必须等待完整答案生成后才能看到内容，交互会显得迟钝。更好的方式是使用流式输出，让回复像真实聊天一样逐步展示。

项目中使用 Server-Sent Events（SSE） 实现服务端向浏览器持续推送数据。

简化后的后端实现如下：

@PostMapping("/chat/text/stream")
public SseEmitter sendTextStream(String model, String message) {
    SseEmitter emitter = new SseEmitter(0L);

    CompletableFuture.runAsync(() -> {
        try {
            aiService.sendText(model, message, true, delta -> {
                emitter.send(SseEmitter.event()
                        .name("delta")
                        .data(delta));
            });

            emitter.send(SseEmitter.event()
                    .name("done")
                    .data("[DONE]"));
            emitter.complete();
        } catch (Exception e) {
            emitter.completeWithError(e);
        }
    });

    return emitter;
}

SSE 相比 WebSocket 更轻量，尤其适合 AI 文本生成这种单向流式推送场景。只要业务不是强双向实时通信，SSE 的实现成本和部署复杂度都更低。

3. 会话历史与数据持久化

一个完整的 GPT AI 聊天应用不能只完成“问一句、答一句”。用户通常需要查看历史对话、切换不同会话，甚至基于上下文继续提问。

因此，后端需要保存对话历史。核心字段通常包括：

用户 ID
会话 ID
用户提问内容
AI 回复内容
创建时间
模型平台与模型名称

示例实体可以抽象为：

@Entity
public class ConversationHistory {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String userId;
    private String sessionId;

    @Column(length = 5000)
    private String userMessage;

    @Column(length = 10000)
    private String assistantReply;

    private String platform;
    private String model;
    private LocalDateTime createdAt;
}

需要注意的是，AI 回复内容可能较长，数据库字段长度要预留足够空间。若后期支持长文档分析或多轮上下文，建议进一步优化存储结构。

4. 跨域配置与前后端分离支持

前端和后端分离部署时，跨域问题几乎一定会遇到。开发环境通常是 localhost:5173 调用 localhost:8083，生产环境则是域名通过 Nginx 代理到后端服务。

后端需要配置 CORS，允许指定来源访问接口：

@Configuration
public class CorsConfig implements WebMvcConfigurer {

    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/**")
                .allowedOriginPatterns("http://localhost:*", "https://your-domain.com")
                .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS")
                .allowCredentials(true);
    }
}

生产环境中不建议直接使用全量通配符放开所有来源。更稳妥的做法是明确配置允许访问的前端域名。

四、前端核心实现

1. API 请求统一封装

前端不应在每个组件中重复编写请求逻辑。更好的方式是将 API 调用集中放在 api 目录中，页面组件只负责调用封装后的方法。

以流式聊天为例，前端可以使用 EventSource 接收 SSE 数据：

export function streamChat({ platform, model, message, onDelta, onDone, onError }) {
  const query = new URLSearchParams({ platform, model, message })
  const eventSource = new EventSource(`/api/ai/chat/text/stream?${query}`)

  eventSource.addEventListener('delta', event => {
    onDelta?.(event.data)
  })

  eventSource.addEventListener('done', () => {
    onDone?.()
    eventSource.close()
  })

  eventSource.onerror = error => {
    onError?.(error)
    eventSource.close()
  }
}

这样做有几个优势：

页面组件代码更干净
方便统一处理异常
后端接口变化时只需要修改 API 层
有利于后续接入鉴权 Token、请求拦截等功能

2. 流式聊天界面设计

聊天界面的关键在于实时更新。用户发送消息后，前端需要立即显示用户消息，同时创建一个正在生成中的 AI 消息，并随着 SSE 数据不断追加内容。

实现逻辑可以概括为：

用户输入问题并点击发送
前端将用户消息加入消息列表
创建一个空的 AI 回复消息
接收后端流式片段并追加到当前消息
接收到完成事件后结束加载状态
将完整对话保存到历史记录

在用户体验上，还应补充以下细节：

回复生成中显示状态提示
防止重复点击发送
支持停止生成或重新生成
长内容自动滚动到底部
Markdown 内容渲染与代码高亮

这些细节往往决定一个 AI 聊天应用是否“可用”。

3. 使用 Pinia 管理全局状态

项目中可以将用户信息、当前会话、模型配置、系统设置等内容放入 Pinia。

示例结构如下：

import { defineStore } from 'pinia'

export const useMainStore = defineStore('main', {
  state: () => ({
    user: null,
    currentSession: null,
    settings: {
      platform: 'openai',
      textModel: 'gpt-4o-mini',
      imageModel: 'dall-e-3'
    }
  }),
  actions: {
    setUser(user) {
      this.user = user
    },
    updateSettings(settings) {
      this.settings = { ...this.settings, ...settings }
    }
  }
})

对于 AI 应用来说，模型配置通常会被多个页面共享，例如聊天页、图像生成页、用户设置页。因此，将其放入全局状态更合适。

五、主要功能模块梳理

1. 多平台 AI 对话

项目通过统一参数切换不同平台和模型。例如用户可以选择 OpenAI、通义千问、DeepSeek、Kimi 等模型进行对话。

关键设计点包括：

统一请求入口
统一响应格式
不同平台单独适配
前端模型列表可配置
异常信息标准化返回

这样可以避免每接入一个模型就重写一套前端逻辑。

2. 图像生成能力

除了文本对话，项目还支持图像生成。可接入的能力包括 OpenAI DALL-E、阿里云通义万相等。

常见参数包括：

提示词
图片尺寸
生成数量
风格配置
平台与模型选择

图像生成接口通常不是流式返回，而是任务式或同步返回。因此前端需要根据不同平台的响应特点设计加载状态和结果展示方式。

3. 用户认证与权限控制

用户系统是应用从 Demo 走向产品化的重要一步。基本功能包括：

用户注册
用户登录
登录状态保持
用户数据隔离
个人设置保存

如果系统后续开放给更多用户使用，还需要继续补充密码加密、Token 鉴权、接口限流和敏感操作校验。

4. 会话管理

会话管理让用户可以保留不同主题的聊天上下文，例如“代码问题”“论文润色”“产品方案”等。

建议的会话能力包括：

新建会话
删除会话
重命名会话
查看历史消息
按时间排序
支持多会话切换

对 AI 聊天应用而言，会话管理不是附加功能，而是基础体验的一部分。

5. 管理员面板与统计分析

管理员后台主要用于观察系统使用情况和管理用户数据。可以包含：

注册用户列表
用户使用次数
模型调用统计
Token 使用量统计
每日请求趋势
异常请求记录

对于个人项目来说，这些功能能够帮助开发者判断系统是否稳定，也能为后续优化模型成本提供依据。

六、本地开发环境搭建

1. 后端启动流程

后端启动流程相对直接：

git clone <repository-url>
cd backend
mvn spring-boot:run

核心配置通常放在 application.yaml 中：

server:
  port: 8083

spring:
  application:
    name: gpt-ai
  datasource:
    url: jdbc:sqlite:identifier.sqlite
    driver-class-name: org.sqlite.JDBC

如果接入第三方 AI 平台，还需要配置对应的 API Key。建议不要将密钥硬编码在代码仓库中，可以使用环境变量或独立配置文件管理。

2. 前端启动流程

前端安装依赖并启动开发服务器：

cd frontend
npm install
npm run dev

开发阶段通常通过 Vite 配置代理，避免浏览器跨域限制：

export default defineConfig({
  server: {
    proxy: {
      '/api': {
        target: 'http://localhost:8083',
        changeOrigin: true
      }
    }
  }
})

这样前端请求 /api 时，会自动转发到本地后端服务。

七、生产环境部署方案

生产部署可以采用 Nginx + Spring Boot Jar 包的方式。前端构建为静态文件，由 Nginx 提供访问；后端以 Java 服务运行，Nginx 将 /api 请求代理到后端端口。

1. 后端打包与运行

mvn clean package -DskipTests
java -jar target/gpt-ai.jar

实际生产环境建议使用 systemd、Supervisor 或容器方式托管后端进程，避免服务异常退出后无人感知。

2. 前端构建与上传

npm run build

构建完成后，将 dist 目录部署到服务器站点目录，例如：

/www/wwwroot/your-domain.com/dist

3. Nginx 反向代理配置

Nginx 配置需要同时处理三件事：

访问前端静态资源
将 API 请求代理到 Spring Boot
支持 Vue Router 的 History 模式
保持 SSE 长连接稳定

示例配置如下：

server {
    listen 80;
    listen 443 ssl http2;
    server_name your-domain.com;

    root /www/wwwroot/your-domain.com/dist;
    index index.html;

    location /api/ {
        proxy_pass http://127.0.0.1:8083;
        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;

        proxy_http_version 1.1;
        proxy_buffering off;
        proxy_cache off;
        proxy_read_timeout 3600s;
        proxy_send_timeout 3600s;
    }

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

    location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg)$ {
        expires 1y;
        add_header Cache-Control "public, immutable";
    }
}

其中 proxy_buffering off 和较长的 proxy_read_timeout 对 SSE 非常重要，否则流式对话可能会出现中断或延迟输出的问题。

八、常见问题与处理建议

1. 前端请求 API 返回 404

通常是 Nginx 代理规则没有命中，或前端请求路径与后端接口路径不一致。

建议检查：

前端请求是否以 /api 开头
Nginx 是否配置了 location /api/
后端服务端口是否正确
Spring Boot 接口路径是否匹配

2. SSE 回复中途断开

流式输出中断多半与代理层配置有关。

建议检查：

proxy_read_timeout 是否过短
是否关闭了代理缓冲
后端是否抛出异常
浏览器网络连接是否稳定

3. 浏览器出现 CORS 错误

跨域问题可能来自后端配置，也可能来自 Nginx 代理头设置。

建议检查：

后端 CORS 是否允许当前前端域名
是否允许携带 Cookie 或认证信息
OPTIONS 预检请求是否正常响应
生产环境是否通过同域代理访问 API

4. Vue 页面刷新后 404

如果使用 Vue Router 的 History 模式，刷新页面时 Nginx 会尝试查找真实路径，导致 404。

解决方式是在 Nginx 中加入：

try_files $uri $uri/ /index.html;

这样所有前端路由都会回退到入口文件，由 Vue 接管路由解析。

九、可以继续优化的方向

当前项目已经覆盖了一个 GPT AI 聊天应用的主要能力，但如果要进一步产品化，还可以从以下方向扩展。

1. 功能层面

增加语音识别和语音合成，实现语音对话
支持文件上传，用于文档问答与内容分析
增加提示词模板，提高用户使用效率
支持分享会话或导出聊天记录
增加插件机制，扩展搜索、翻译、代码解释等能力

2. 架构层面

引入 Redis 缓存用户配置和热点数据
使用消息队列处理耗时任务
增加接口限流，防止滥用
将模型调用、用户系统、统计系统拆分为独立服务
对高频接口增加监控和告警

3. 运维层面

接入日志分析系统
配置自动化部署流程
增加异常告警通知
统计模型调用成本
定期备份数据库

对于 AI 应用来说，成本控制和稳定性同样重要。尤其是接入多个商业模型后，用量统计、权限控制和限流策略都应尽早规划。

十、总结

这个基于 Spring Boot + Vue.js 的 GPT AI 聊天应用，完整覆盖了现代 Web AI 产品的核心开发链路：后端接口设计、前端交互实现、多模型平台适配、会话持久化、用户体系、管理员后台以及 Nginx 生产部署。

我认为，这类项目最有价值的地方不只是“能调用 AI 接口”，而是把一个 AI 能力包装成了可使用、可维护、可扩展的应用系统。

如果你也计划开发类似的 GPT AI 聊天应用，建议重点关注三件事：

架构上要预留多模型扩展能力，不要与某个供应商深度耦合；
体验上要优先做好流式输出和会话管理，这是聊天产品的基本盘；
部署上要正确处理 Nginx 代理、SSE 长连接和前端路由回退，否则本地可用不代表线上稳定。

通过 Spring Boot 的稳健后端能力与 Vue.js 的灵活前端体验，个人开发者也可以较快搭建出一个完整的 AI 聊天平台，并在此基础上继续扩展为更成熟的智能应用。

最后修改：2026 年 06 月 08 日

如果觉得我的文章对你有用，请随意赞赏

一、项目定位与技术选型

1. 后端技术栈

2. 前端技术栈

3. AI 平台接入

二、整体项目架构

三、后端核心设计

1. 多 AI 平台的统一入口

2. 使用 SSE 实现流式回复

3. 会话历史与数据持久化

4. 跨域配置与前后端分离支持

四、前端核心实现

1. API 请求统一封装

2. 流式聊天界面设计

3. 使用 Pinia 管理全局状态

五、主要功能模块梳理

1. 多平台 AI 对话

2. 图像生成能力

3. 用户认证与权限控制

4. 会话管理

5. 管理员面板与统计分析

六、本地开发环境搭建

1. 后端启动流程

2. 前端启动流程

七、生产环境部署方案

1. 后端打包与运行

2. 前端构建与上传

3. Nginx 反向代理配置

八、常见问题与处理建议

1. 前端请求 API 返回 404

2. SSE 回复中途断开

3. 浏览器出现 CORS 错误

4. Vue 页面刷新后 404

九、可以继续优化的方向

1. 功能层面

2. 架构层面

3. 运维层面

十、总结

发表评论 取消回复 使用cookie技术保留您的个人信息以便您下次快速评论，继续评论表示您已同意该条款

Spring Boot + Vue.js 构建 GPT AI 聊天应用：架构设计、核心实现与部署实践

发表评论取消回复
使用cookie技术保留您的个人信息以便您下次快速评论，继续评论表示您已同意该条款