一、问题背景

导购助手项目中，AI 智能体的接口响应时间约 120 秒，远超微信小程序的 60 秒最大超时限制（wx.request 超时上限为 60s）。用户在等待 AI 回复时，小程序端会直接断开连接，体验中断。

二、方案对比

方案一（主方案）：同接口轮询（单接口 + randomId）

在原有接口基础上改造，不新增独立接口。通过 randomId 参数区分首次调用和轮询调用。

调用流程：

第一次调用（不传 randomId）：

1. 客户端发起请求，调用原有接口（不携带 randomId）

2. 服务端创建 AI 任务，生成随机数 randomId 并存入 Redis

3. 立即返回：{ randomId, status: wait, callCount: 0 }

后续轮询调用（携带 randomId + callCount）：

1. 客户端携带 randomId 再次调用同一接口

2. 服务端通过 randomId 到 Redis 查询任务状态

3. 数据就绪 → 返回 { randomId, status: success, data }

4. 任务失败 → 返回 { randomId, status: faild }

5. 未就绪 → 线程 sleep(10s)，再次查询

6. - 有数据 → success；仍无数据 → status: wait, callCount+1

7. callCount 超过上限（如 12 次）→ 直接返回 faild

返回参数：

• randomId：随机数 ID，标识任务

• status：响应状态（success / faild / wait）

• callCount：当前调用次数，超过上限自动中断

• data：成功时携带的 AI 回复数据

优点：

• 代码改动最小：只需在原有接口新增参数判断逻辑

• 不引入新协议：纯 HTTP，小程序原生支持

• 超时可控：callCount 上限直接对应最大等待时间

缺点：

• 用户需等待完整结果，无法流式体验

• 服务端 sleep 占用线程资源

---

方案二（备选）：双接口分离（init + responseTrue）

将启动任务和查询状态拆分为两个接口，职责更清晰。

调用流程：

第一步：调用 init 接口

1. 客户端调用 init 接口（如 /api/guide/init），传入用户消息

2. 服务端创建 AI 任务，启动异步处理

3. 返回任务标识（如 taskId），不等待 AI 完成

第二步：轮询 responseTrue 接口

1. 客户端反复调用 responseTrue 接口（如 /api/guide/responseTrue）

2. 接口只返回三种状态之一：

• true：数据已就绪，可以去拉取了

• false：任务失败

• wait：还在处理中，继续轮询

第三步：获取数据

1. 当 responseTrue 返回 true 后，客户端再次调用 init 接口获取实际响应数据

2. 注：这里 init 接口的职责包含了「启动任务」和「获取已就绪的数据」两个功能

返回参数（responseTrue 接口）：

• 仅返回 true / false / wait，简洁明了

• 可通过 HTTP 状态码或 JSON 体返回

优点：

• 职责分离：启动与状态查询解耦，接口更清晰

• 状态接口轻量：只返回布尔/枚举值，响应极快

• 调用模式直观：前端逻辑容易理解

缺点：

• 两个接口增加维护成本

• 仍然需要轮询，体验与方案一类似

---

方案三（高级）：WebSocket 长连接

实现最复杂，但用户友好度最高。AI 边生成边推送到客户端，实现打字机效果。

调用流程：

1. 用户进入对话页面后，建立 WebSocket 连接

2. 用户发送消息，服务端接手并转发给 AI 智能体（流式调用）

3. AI 每生成一段内容，通过 WebSocket 实时推送到小程序端

4. 小程序端逐步展示回复，呈现打字机效果

5. AI 回复结束后发送完成信号，关闭或保持连接等待下一轮

优点：

• 用户体验最佳：实时流式输出，无等待感

• 无超时问题：连接保持后不受 60s 限制

• 可扩展：支持主动推送促销、推荐商品等功能

缺点：

• 实现最复杂：需维护连接状态、心跳、重连逻辑

• 小程序切后台后 WebSocket 可能断开，需处理重连

• 开发周期比前两种长

适用场景：

• 当轮询方案的等待体验不满足业务需求时升级为此方案

• 需要实时交互、流式输出的场景

---

三、补充说明：SSE（Server-Sent Events）

SSE 是 WebSocket 的轻量替代方案，但需要注意平台兼容性。

平台兼容：

• 微信小程序：❌ 不适用

• - 小程序原生不支持 EventSource API

• - 小程序目前仅支持 WebSocket 进行流式数据传输

• Web 应用（H5/PC）：✅ 适用

• - 浏览器原生支持 EventSource，实现简单

• - 仅需 HTTP 协议，无需额外依赖

SSE 特点：

• 单向推送：服务端 → 客户端，适合 AI 对话输出场景

• 实现比 WebSocket 简单（仅 HTTP 协议）

• 浏览器自动重连

• 不适合需要客户端→服务端实时通信的场景

结论：如果只接小程序，优先考虑方案一/二/三（WebSocket）。SSE 仅作为 Web 端备选。