基于Vue 3与Node.js的ChatGPT私有化Web应用部署与定制指南

在现代Web开发中，前后端分离架构已成为构建复杂应用的主流范式。其核心原理在于将用户界面与业务逻辑解耦，前端负责交互与展示，后端则专注于数据处理与API服务。这种架构的技术价值在于提升了开发效率、便于团队协作，并能实现更好的可扩展性与维护性。在人工智能应用领域，尤其是大模型集成场景，该架构能有效管理API密钥安全、处理流式响应与维护对话上下文。本文聚焦于一个具体的工程实践：如何利用Vue 3、Ty

李昦

336人浏览 · 2026-05-01 11:31:46

李昦 · 2026-05-01 11:31:46 发布

1. 项目概述：一个开箱即用的ChatGPT Web应用

最近在GitHub上看到一个挺有意思的项目，叫 rhua-ai/rhua-chatgpt-web 。简单来说，这就是一个让你能快速搭建起自己专属ChatGPT网页版聊天界面的开源工具。如果你厌倦了官方网页版偶尔的访问限制，或者想把它集成到自己的内网环境、做个二次开发，甚至只是想有个更清爽、更可控的聊天环境，那这个项目就特别适合你。

它本质上是一个前后端分离的Web应用。前端负责呈现我们熟悉的聊天界面——对话框、历史记录、模型切换那些；后端则扮演一个“智能中转站”的角色，负责处理你的请求，并安全、稳定地调用OpenAI官方的API（或者兼容API的其他大模型服务）。这样一来，你就不用每次都去打开OpenAI的官网，而是有一个随时可以访问的私有化入口。

这个项目解决的核心痛点，其实就是“便捷部署”和“自主可控”。对于开发者而言，它提供了一个清晰的、可修改的代码范例，你能看到前后端如何交互、API密钥如何管理、对话上下文如何维护。对于普通用户或小团队，它又像一个“一键安装包”，通过简单的配置就能获得一个功能完整的AI助手前端，省去了从零开发的巨大成本。无论是想学习大模型应用开发，还是单纯想拥有一个更稳定的聊天工具， rhua-chatgpt-web 都是一个不错的起点。

2. 核心架构与技术栈拆解

要理解这个项目，我们得先把它拆开看看里面用了哪些“零件”，以及这些零件是怎么组装在一起工作的。这就像看一辆车的构造图，明白了发动机、变速箱、底盘各自的作用，你才知道它为什么能跑，以及哪里可以自己动手改装。

2.1 前端技术选型：Vue 3 + TypeScript的现代组合

项目的前端部分采用了 Vue 3 和 TypeScript 这套当前非常主流且高效的技术组合。

选择Vue 3而不是React或其他框架，我认为有几个很实际的考虑。首先，Vue的学习曲线相对平缓，对于想要快速上手或参与贡献的开发者更友好。其次，Vue 3的 Composition API 在组织复杂组件的逻辑时非常清晰，尤其是对于聊天应用这种有大量状态（如对话列表、当前输入、模型参数）需要管理的场景。你可以把发送消息、处理响应、管理历史记录这些逻辑分别写成一个个可复用的函数（composable），代码的维护性会好很多。

而 TypeScript 的加入，则是为项目的稳健性加了一道保险。在调用后端API、定义消息数据结构（比如一条消息包含角色、内容、时间戳等字段）时，TypeScript的强类型检查能在编码阶段就发现很多潜在的错误，避免把 string 类型的数据当成 array 来处理这类低级问题。这对于一个开源项目来说尤为重要，能减少贡献者因类型不匹配导致的Bug。

前端的UI框架通常基于 Element Plus 或 Ant Design Vue 这类成熟的组件库。它们提供了现成的按钮、输入框、布局组件，让开发者能快速搭建出美观且交互一致的界面，而不用花大量时间去调整CSS细节。聊天界面核心的“消息列表”组件，往往会利用这些UI库的列表或卡片组件进行定制，实现消息的气泡样式、流式响应（一个字一个字地显示）效果。

2.2 后端服务核心：Node.js与API密钥安全中转

后端是项目的“大脑”和“守门人”。 rhua-chatgpt-web 的后端通常基于 Node.js 环境，使用 Express 或 Koa 这类轻量级Web框架来构建。

它的核心职责非常明确：

接收请求 ：接收从前端发来的用户消息和相关配置（如选择的模型、温度参数）。
安全转发 ：将请求重新封装，并附上你的OpenAI API密钥，发送给OpenAI的官方接口。
处理响应 ：接收OpenAI返回的流式或非流式数据，进行必要的处理（如错误处理、格式整理）后，再返回给前端。

这里最关键的一环是 API密钥的安全管理 。绝对不能在浏览器端（前端代码里）暴露你的API密钥，那相当于把银行卡密码贴在橱窗上。正确的做法是，将API密钥保存在后端的环境变量（如 .env 文件）或安全的配置中心。后端服务在转发请求时，从这些安全的位置读取密钥，并将其添加到请求的 Authorization 头部。这样，密钥永远不会离开你的服务器，大大降低了泄露风险。

后端还需要实现一个重要的功能： 上下文管理 。为了让ChatGPT能记住之前的对话，你需要把历史消息也一并发送。后端需要维护一个会话（session）或根据前端传来的对话ID，从数据库（如Redis用于缓存，或MySQL/PostgreSQL用于持久化）中取出历史记录，将它们组织成OpenAI API要求的消息数组格式（通常是一系列 {role: “user”/“assistant”, content: “…”} 对象）。这个逻辑的好坏，直接影响到对话的连贯性和智能感。

2.3 数据流与通信机制

整个应用的数据流动是一个清晰的闭环：

用户在浏览器中输入问题，点击发送。
前端（Vue应用）通过 HTTP请求 或 WebSocket 将消息和配置发送到后端服务器。
后端服务器验证请求，从安全存储中读取API密钥，并准备好包含历史上下文的请求体。
后端使用 axios 或 node-fetch 库，将请求发送至 https://api.openai.com/v1/chat/completions 。
后端接收到OpenAI的响应（通常是流式数据流），开始边接收边转发（streaming）给前端，或者等全部接收完再一次性返回。
前端根据返回的数据，以打字机效果渲染出AI的回复，并更新本地对话历史。

流式响应（Streaming） 是提升用户体验的关键。如果等AI生成完所有文字再一次性显示，用户面对一个空白的界面等待，体验会很差。通过Server-Sent Events (SSE) 或 WebSocket 实现流式传输，后端每从OpenAI收到一个数据块（chunk）就立刻推给前端，前端就能实时地、逐字地显示回答，感觉更自然、响应更快。 rhua-chatgpt-web 这类项目通常会实现这个特性。

注意：在部署时，你需要关注后端服务器的网络环境。由于需要直接访问 api.openai.com ，服务器必须具备稳定访问国际互联网的能力。同时，合理设置请求超时和重试机制，以应对可能出现的网络波动或API限流。

3. 从零开始的部署与配置实战

看懂了架构，我们动手把它跑起来。这里我以最常见的部署方式——使用Docker——为例，带你走一遍全流程。这种方式能最大程度避免环境依赖问题，真正做到开箱即用。

3.1 环境准备与项目获取

首先，你需要在你的服务器或本地开发机上准备好基础环境：

Docker与Docker Compose ：这是容器化部署的基石。确保已安装最新稳定版。
```
# 检查Docker和Docker Compose版本
docker --version
docker-compose --version
```
Git ：用于拉取项目代码。
一个有效的OpenAI API密钥 ：前往OpenAI平台注册并获取。这是项目能工作的“燃料”。

接下来，获取项目代码：

# 克隆项目仓库到本地
git clone https://github.com/rhua-ai/rhua-chatgpt-web.git
cd rhua-chatgpt-web

进入项目目录后，你会看到典型的项目结构： frontend/ （前端代码）、 backend/ （后端代码）、 docker-compose.yml （部署编排文件）、 README.md （说明文档）以及一些配置文件。

3.2 关键配置详解：.env文件与docker-compose.yml

配置是部署的灵魂，主要涉及两个文件。

首先是 .env 文件 。项目根目录下通常会提供一个 .env.example 或类似的环境变量示例文件。你需要复制一份并重命名为 .env ，然后编辑它：

cp .env.example .env
# 然后使用文本编辑器（如vim, nano, VS Code）打开 .env 文件

这个文件里最关键的配置项包括：

OPENAI_API_KEY=sk-your-actual-api-key-here ：替换 your-actual-api-key-here 为你的真实API密钥。这是必填项。
OPENAI_API_BASE_URL=https://api.openai.com/v1 ：默认指向官方API。如果你使用Azure OpenAI或第三方兼容API（如某些国内中转服务），需要修改此地址。
API_PORT=3002 ：后端服务监听的端口号，可按需修改。
HTTP_PROXY= 或 ALL_PROXY= ：如果你的服务器需要通过代理访问外网，可以在这里配置HTTP或SOCKS5代理地址。 这是解决服务器网络访问问题的关键一步 。
可能还有数据库连接字符串（如 DATABASE_URL ）、会话密钥（ SESSION_SECRET ）等。

其次是 docker-compose.yml 文件 。这个文件定义了如何启动前端、后端以及可能需要的数据库（如Redis）服务。你需要检查并确认以下几点：

服务定义 ：确保 backend （后端）和 frontend （前端）服务都已正确定义，并且 backend 服务依赖 .env 文件。
端口映射 ：检查端口映射是否合理。例如，前端可能映射主机的 3000 端口到容器的 80 端口，后端映射主机的 3002 端口到容器的 3002 端口。确保这些端口在你的服务器上没有冲突。
卷挂载 ：有时为了持久化数据（如聊天记录、配置文件），会将主机目录挂载到容器内。确认挂载路径是否存在或是否需要创建。
网络：确保所有服务在同一个自定义Docker网络下，以便它们能通过服务名互相访问（例如，前端可以通过 http://backend:3002 访问后端API）。

3.3 一键启动与验证

配置妥当后，启动服务就非常简单了：

# 在项目根目录下执行
docker-compose up -d

-d 参数表示在后台运行。Docker会依次拉取镜像（如果本地没有）、构建容器并启动。

启动后，通过以下命令检查服务状态：

docker-compose ps

你应该看到 frontend 和 backend 两个服务的状态都是 Up 。

接下来进行验证：

访问前端 ：打开浏览器，输入 http://你的服务器IP:3000 （端口号以你实际的映射为准）。你应该能看到ChatGPT的聊天界面。
测试聊天 ：在输入框中发送一条消息，如“你好”。如果一切正常，你应该能收到AI的回复。
检查后端日志 ：如果聊天失败，查看后端日志是首要的排查手段：
```
docker-compose logs backend
```
重点关注是否有连接OpenAI API失败的错误（如网络超时、认证失败）。

实操心得 ：第一次部署时，最容易出问题的地方就是网络。如果后端日志显示连接 api.openai.com 超时，基本可以确定是服务器网络问题。这时你有几个选择：一是如前所述在 .env 中配置代理；二是将后端服务部署在能顺畅访问OpenAI的网络环境中；三是考虑使用支持国内访问的API中转服务（需相应修改 OPENAI_API_BASE_URL ）。另外，务必确认你的OpenAI API密钥余额充足且未过期。

4. 深度定制与功能扩展指南

基础部署只是第一步。 rhua-chatgpt-web 作为一个开源项目，其更大的价值在于你可以根据需求对它进行“改造”。下面我们聊聊几个常见的定制方向。

4.1 界面与交互个性化

前端代码都在 frontend/ 目录下，使用Vue开发。如果你想修改界面，比如换个主题颜色、调整布局、增加一个功能按钮，可以遵循以下步骤：

本地开发环境搭建 ：进入 frontend 目录，运行 npm install 安装依赖，然后使用 npm run dev 启动本地开发服务器。这样你就能在修改代码后实时看到效果。
修改主题 ：如果项目使用了UI组件库，通常可以通过覆盖CSS变量或使用其主题定制工具来修改主题色。例如，在Element Plus中，你可以在 main.ts 或一个全局样式文件中定义新的主题色变量。
添加功能组件 ：假设你想在侧边栏增加一个“一键清空对话”的按钮。
- 首先，在对应的Vue组件文件（如 Sidebar.vue ）中找到模板部分，添加一个按钮元素。
- 然后，在组件的 <script setup> 部分，编写一个处理函数（如 handleClearChat ），这个函数会调用Vuex/Pinia存储（状态管理库）的action或直接调用后端API来清空当前对话。
- 最后，将按钮的点击事件绑定到这个处理函数上。
修改流式渲染效果 ：如果你觉得打字机效果的速度或样式不满意，可以找到负责渲染消息流的组件（可能叫 MessageItem.vue 或 ChatWindow.vue ）。流式渲染的核心逻辑通常是一个函数，它逐个将响应字符串推入显示内容中。你可以调整其中的延迟时间或添加自定义的CSS动画。

4.2 集成其他大模型与第三方API

项目默认对接OpenAI，但架构设计上通常预留了扩展性。后端处理AI请求的部分，往往抽象成了一个“模型提供商”（Model Provider）层。要接入新的模型，比如国内的智谱AI、月之暗面（Kimi），或者开源的Ollama本地模型，你需要：

理解请求适配器 ：在后端代码中，找到负责向OpenAI发送请求的模块（可能是一个独立的类或函数，例如 openaiAdapter.js ）。它的输入是标准化的消息和配置，输出是处理后的响应。
创建新的适配器 ：为新的模型服务创建一个新的适配器文件（如 zhipuAdapter.js ）。你需要研究目标模型的API文档，了解其请求格式、认证方式（API Key通常放在请求头或参数中）、以及响应格式。
实现标准化转换 ：在新适配器内部，将项目内部的标准消息格式，转换成目标API要求的格式。同时，将目标API返回的响应，转换回项目内部的标准格式。关键是要处理好 流式响应 的兼容性，不同API返回的流式数据块格式可能不同。
修改路由或配置 ：在后端的主路由文件或配置中心，添加一个开关或条件判断，使得当用户选择不同模型时，能路由到对应的适配器进行处理。一种常见的做法是在请求体中携带一个 model 或 provider 字段，后端根据这个字段来实例化不同的适配器。

例如，一个非常简化的适配器选择逻辑可能长这样：

// 伪代码示例
async function handleChatRequest(req, res) {
  const { messages, model } = req.body;
  let adapter;

  if (model.startsWith('gpt-')) {
    adapter = new OpenAIAdapter();
  } else if (model.startsWith('glm-')) {
    adapter = new ZhipuAIAdapter();
  } else if (model.startsWith('llama')) {
    adapter = new OllamaAdapter(); // 假设对接本地Ollama
  } else {
    throw new Error('Unsupported model');
  }

  const stream = await adapter.createChatCompletionStream(messages, model);
  // ... 将stream管道式地返回给前端
}

4.3 实现对话持久化与用户系统

默认情况下，对话历史可能只保存在前端的内存或浏览器的LocalStorage中，刷新页面就没了。对于想长期保存记录或支持多用户的应用，需要引入数据库和后端用户认证。

选择数据库 ：对于聊天记录， Redis 作为缓存非常合适，能快速存储和读取活跃的会话。对于需要永久保存的记录和用户信息，则需要 PostgreSQL 或 MySQL 这类关系型数据库。项目可能已经使用了Prisma、TypeORM或Sequelize这样的ORM工具来简化数据库操作。
设计数据表 ：至少需要 users （用户）表和 conversations （对话）表。 conversations 表可以关联 user_id ，每条记录存储一次对话的标题、创建时间等元数据。而具体的消息内容，可以存储在 messages 表中，每条消息关联一个 conversation_id 。
修改后端API ：
- 用户注册/登录 ：添加对应的路由，使用 bcrypt 哈希密码，使用 jsonwebtoken (JWT) 签发令牌。
- 对话保存 ：在每次创建新对话或收到AI回复后，将消息记录插入数据库。注意，为了性能，可以在流式响应完全结束后再异步执行保存操作。
- 历史记录获取 ：添加API端点，根据用户ID和对话ID，从数据库中查询对应的消息记录并返回给前端。
前端适配 ：前端需要增加登录/注册页面，并在所有需要认证的API请求头中携带JWT令牌。同时，需要改造聊天界面，增加“保存对话”、“加载历史对话列表”等功能。

注意事项 ：引入用户系统后，安全性变得至关重要。务必做好以下几点：1) 密码加盐哈希存储；2) API接口实施权限校验（确保用户只能访问自己的对话）；3) 对用户输入进行适当的清理和过滤，防止XSS攻击；4) 使用HTTPS加密传输。

5. 生产环境部署优化与安全加固

将项目部署到公网供团队或更多人使用时，就不能再用开发模式了。我们需要从性能、稳定性和安全方面进行加固。

5.1 性能优化策略

启用压缩 ：在后端服务器（如Nginx）或Node.js应用层（使用 compression 中间件）启用Gzip或Brotli压缩，可以有效减少网络传输的数据量，加快页面和API响应速度。
静态资源优化 ：对前端构建产物（JavaScript, CSS, 图片）进行压缩、代码分割（Code Splitting）和长期缓存。在Dockerfile的构建阶段，使用多阶段构建，并确保最终镜像中只包含运行所需的文件。
数据库与缓存优化 ：
- 为频繁查询的字段（如 conversations 表的 user_id 和 created_at ）建立索引。
- 对热点数据（如用户最近10条对话）使用Redis进行缓存，减少数据库直接查询。
API限流与防滥用 ：使用 express-rate-limit 等中间件，对API接口进行限流。例如，限制每个IP地址每分钟最多发送60次聊天请求，防止恶意爬虫或误操作耗尽你的API额度。

5.2 安全配置清单

安全无小事，特别是涉及API密钥和用户数据时。

环境变量管理 ：绝不在代码中硬编码密钥。所有敏感信息（API Key、数据库密码、JWT密钥）必须通过 .env 文件或更专业的密钥管理服务（如HashiCorp Vault、AWS Secrets Manager）注入。确保 .env 文件被添加到 .gitignore 中，避免意外提交。
HTTPS强制 ：使用Nginx或Caddy作为反向代理，配置SSL证书（可以从Let‘s Encrypt免费获取），强制所有HTTP请求跳转到HTTPS。这能防止中间人攻击，保护数据传输安全。
CORS策略收紧 ：在后端配置CORS（跨源资源共享）时，不要使用通配符 * 。明确指定允许访问的前端域名（ Access-Control-Allow-Origin: https://your-frontend-domain.com ）。
输入验证与清理 ：对所有用户输入（包括聊天内容）进行严格的验证和清理，防止SQL注入和XSS攻击。可以使用 validator 或 joi 库进行验证。
依赖项安全扫描 ：定期使用 npm audit 或 yarn audit 检查项目依赖包是否存在已知安全漏洞，并及时更新到安全版本。可以在CI/CD流水线中集成此步骤。

5.3 使用Nginx进行反向代理与负载均衡

直接暴露Node.js服务到公网不是最佳实践。使用Nginx作为反向代理有以下好处：

静态文件服务 ：Nginx可以高效地直接提供前端构建出的静态文件（HTML, JS, CSS），减轻Node.js服务的负担。
负载均衡 ：如果流量较大，可以在Nginx后面部署多个Node.js后端实例，由Nginx将请求分发到不同的实例上。
SSL终结 ：在Nginx层面处理SSL加解密，让后端应用专注于业务逻辑。
缓冲与超时控制 ：可以配置客户端请求的缓冲和超时时间，保护后端服务。

一个简化的Nginx配置示例可能如下：

server {
    listen 443 ssl http2;
    server_name chat.yourdomain.com;

    ssl_certificate /path/to/your/cert.pem;
    ssl_certificate_key /path/to/your/key.pem;

    # 静态前端文件
    location / {
        root /var/www/rhua-chatgpt-web-frontend;
        try_files $uri $uri/ /index.html;
    }

    # 反向代理到后端API
    location /api/ {
        proxy_pass http://localhost:3002; # 假设后端运行在3002端口
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        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_cache_bypass $http_upgrade;
        # 重要：设置较长的超时时间以支持流式响应
        proxy_read_timeout 300s;
        proxy_send_timeout 300s;
    }
}

6. 常见问题排查与调试技巧实录

在实际部署和运行过程中，你肯定会遇到各种各样的问题。下面我整理了一些最常见的问题和我的排查思路，希望能帮你快速定位。

6.1 部署启动类问题

问题1：执行 docker-compose up -d 后，服务启动失败，状态为 Exit 1 或 Restarting 。

排查步骤 ：
1. 查看日志 ：第一时间运行 docker-compose logs [service-name] ，比如 docker-compose logs backend 。错误信息几乎都会在这里显示。
2. 常见原因 ：
  - 端口冲突 ：日志中可能出现 Address already in use 。用 netstat -tulpn | grep :端口号 检查该端口是否被其他程序占用，修改 docker-compose.yml 中的端口映射。
  - 环境变量缺失或错误 ：检查 .env 文件是否已创建，且其中的 OPENAI_API_KEY 等关键变量是否已正确填写。有时变量名拼写错误也会导致读取失败。
  - 依赖安装失败 ：对于需要构建（ build ）的镜像，可能因为网络问题导致 npm install 失败。可以尝试先进入容器手动安装： docker-compose run --rm backend sh ，然后在容器内执行安装命令，观察报错。
  - 文件权限问题 ：如果挂载了本地目录到容器，可能容器内用户没有写入权限。检查主机目录的权限。

问题2：前端页面能打开，但发送消息后一直显示“正在思考…”或直接报错。

排查步骤 ：
1. 打开浏览器开发者工具 ：按F12，切换到“网络”(Network)标签页，重新发送一条消息。观察调用哪个API接口失败了。
2. 分析请求与响应 ：
  - 状态码5xx （如502， 504）：通常是后端服务挂了或网络超时。去查看后端容器日志。
  - 状态码4xx （如401， 403）：通常是认证或权限问题。检查API密钥是否正确、是否过期、是否有额度。检查后端CORS配置是否正确，是否允许了前端的源。
3. 后端日志定位 ：结合浏览器中看到的失败API请求，去后端日志里搜索对应的请求ID或时间点，看后端处理时具体报什么错。
4. 常见原因 ：
  - API密钥无效 ：后端日志会明确提示 Incorrect API key provided 。请仔细核对密钥，并确保在OpenAI平台该密钥有调用ChatGPT API的权限。
  - 网络连接问题 ：后端日志显示连接 api.openai.com 超时或失败。这是部署中最常见的问题。确认服务器网络，并按前文所述配置代理或更换部署环境。
  - 请求格式错误 ：可能是后端在构造发送给OpenAI的请求体时出错。检查后端代码中关于消息数组格式、模型名称等是否符合API文档要求。

6.2 运行与使用类问题

问题3：对话没有上下文，AI好像失忆了，每次回答都只基于当前问题。

原因与解决 ：这通常是上下文管理逻辑没有正常工作。
1. 检查前端 ：确认前端在发送请求时，是否将之前的历史消息（包括用户和AI的对话）都放入了请求体的 messages 数组中。可以通过浏览器开发者工具的“网络”标签查看发送出去的请求内容。
2. 检查后端 ：后端是否正确地接收并传递了这个 messages 数组。有些实现可能会将会话ID（sessionId）发给后端，由后端从数据库或缓存中取出历史记录。检查这个逻辑是否正常。
3. 注意Token限制 ：即使上下文传递正确，如果对话历史太长，超过了模型的最大上下文长度（如gpt-3.5-turbo的16K），后端需要实现一个“剪裁”策略，只保留最近的一部分对话，否则API会报错。

问题4：响应速度很慢，或者流式响应时断时续。

优化方向 ：
1. 网络延迟 ：这是主要因素。你的服务器到OpenAI API服务器的网络质量直接影响速度。可以考虑使用网络优化服务或将服务部署在离OpenAI数据中心较近的区域。
2. 模型选择 ： gpt-3.5-turbo 比 gpt-4 系列快得多。如果对智能程度要求不高，可以选用更快的模型。
3. 流式响应优化 ：确保后端在接收到OpenAI的流式数据后，是实时地、分块（chunk）地转发给前端的，而不是等全部接收完再一次性返回。检查后端代码中关于流式传输的实现。
4. 前端渲染优化 ：如果前端在渲染大量历史消息时卡顿，可以考虑使用虚拟滚动（virtual scroll）技术，只渲染可视区域内的消息。

6.3 高级调试技巧

在容器内执行命令 ：当需要检查容器内部状态时，使用 docker-compose exec backend sh （或 bash ）进入后端容器，可以查看文件、运行命令、甚至手动调用一段测试代码来验证API连接。

使用 curl 模拟请求 ：在后端服务器上，直接用 curl 命令模拟前端发送请求，可以快速隔离前端问题。

curl -X POST http://localhost:3002/api/chat \
  -H "Content-Type: application/json" \
  -d '{"messages":[{"role":"user","content":"Hello"}], "model":"gpt-3.5-turbo"}'