主题
Nuxt AI 应用开发 · 高级项目面
Nuxt 如何实现 AI 对话的流式输出,SSE 和 WebSocket 怎么选择?
考察流式 token、SSE 生命周期、连接关闭、事件协议和实时通信选型。
面试官想考什么
- 能否先定义 AI 场景和 Nuxt 的边界?
考察流式 token、SSE 生命周期、连接关闭、事件协议和实时通信选型。 - 能否讲清端到端链路?
重点考察:提交消息 -> Nitro 创建流 -> 调用模型流 -> 转换为统一事件 -> push 到客户端 -> 客户端按 messageId 累积 -> done/error/abort 收尾。 - 能否说出工程取舍?
重点考察:SSE 基于 HTTP、重连语义清晰,适合服务端到客户端;WebSocket 双向能力强,但代理、扩缩容、心跳和连接治理更复杂。 - 能否处理线上风险?
重点考察:事件至少包含 id、type、conversationId、messageId、sequence 和 payload;客户端必须处理断开、重复、乱序、取消和服务端错误,关闭流时释放上游模型连接。
一句话回答
text
单向 token 流优先用 SSE 或 fetch streaming,服务端按结构化事件推送增量文本、工具状态和结束信号;需要双向协作、多人房间或客户端主动推送时再考虑 WebSocket。面试回答详解
这道题的核心不是“会不会调用模型”,而是能否把 Nuxt 的页面和 Nitro 服务端能力放进 AI 应用的完整闭环:输入、上下文、模型或工具、流式结果、持久化、权限、观测和失败恢复。
1. 问题边界
考察流式 token、SSE 生命周期、连接关闭、事件协议和实时通信选型。 SSE 基于 HTTP、重连语义清晰,适合服务端到客户端;WebSocket 双向能力强,但代理、扩缩容、心跳和连接治理更复杂。
2. 核心链路
提交消息 -> Nitro 创建流 -> 调用模型流 -> 转换为统一事件 -> push 到客户端 -> 客户端按 messageId 累积 -> done/error/abort 收尾。
text
用户交互 -> Nuxt 客户端状态 -> Nitro/BFF -> AI 编排
-> 模型/RAG/工具 -> 结构化或流式结果
-> 持久化、观测、评估和恢复3. Nuxt 项目落地
事件至少包含 id、type、conversationId、messageId、sequence 和 payload;客户端必须处理断开、重复、乱序、取消和服务端错误,关闭流时释放上游模型连接。
- 服务端边界:模型密钥、provider 选择、权限、工具执行和成本控制放在服务端;客户端只拿到最小必要结果。
- 状态边界:区分页面状态、会话状态、run 状态和持久化数据,避免刷新、重连或多标签页时串话。
- 协议边界:流式事件、结构化输出和错误响应要有版本化契约,不能让组件猜测 provider 的原始格式。
- 安全边界:用户输入、RAG 文档、工具结果和模型输出都可能不可信,必须做权限、校验、脱敏和审计。
4. 工程取舍
SSE 基于 HTTP、重连语义清晰,适合服务端到客户端;WebSocket 双向能力强,但代理、扩缩容、心跳和连接治理更复杂。
成熟答案要明确哪些工作适合同步请求,哪些必须进入队列或工作流;哪些数据可以缓存,哪些属于用户私有数据;哪些失败可以重试,哪些副作用只能人工恢复。
5. 生产风险与验证
事件至少包含 id、type、conversationId、messageId、sequence 和 payload;客户端必须处理断开、重复、乱序、取消和服务端错误,关闭流时释放上游模型连接。 方案上线前至少覆盖正常、超时、限流、断流、取消、重复请求、权限变化、provider 故障和版本回滚。用 trace、指标、评估集、组件测试和 E2E 验证,不把“本地能显示回答”当作完成。
可直接背诵的 30 秒回答
text
我会先把 AI 功能拆成输入、上下文、模型或工具、结果传输、持久化和观测几层。单向 token 流优先用 SSE 或 fetch streaming,服务端按结构化事件推送增量文本、工具状态和结束信号;需要双向协作、多人房间或客户端主动推送时再考虑 WebSocket。 在 Nuxt 中,页面负责交互和状态展示,Nitro 负责鉴权、模型代理、流式协议和服务端数据访问,长任务进入可恢复的任务系统。最后我会补齐权限、成本、失败恢复、评估和灰度回滚,确保它不只是一个 Demo。扩展知识
AI 应用通用链路
text
Auth -> Input Validation -> Context/RAG -> Model/Tool
-> Stream/Structured Output -> Persistence -> Trace/EvaluationNuxt 中常见的职责分配
- 页面与 composable:输入、消息列表、连接状态、重试、取消和可访问反馈。
- Nitro server/api:认证、限流、模型代理、流式协议、数据访问和错误归一化。
- 后台任务:文档索引、批量生成、长 Agent、转码和重试。
- 外部系统:模型 provider、向量库、对象存储、队列、数据库和观测平台。
常见误区
- 把 AI SDK 或模型 SDK 直接导入 Vue 页面,泄露密钥和业务边界。
- 只实现 token 流,不处理断开、取消、重复、乱序和最终一致性。
- 把 RAG 文档、工具结果和用户记忆当成可信指令。
- 只看回答是否“看起来不错”,没有 Prompt/模型/检索/工具版本和评估集。
面试官追问链
追问一:为什么不能只把 token 拼成纯文本?
- 考察点:确认候选人是否能把 AI 功能落到可靠的 Nuxt 生产链路。
- 回答方向:结合状态、权限、失败恢复、成本、可观测性和部署边界回答,不要只罗列 SDK API。
追问二:SSE 断开后如何恢复?
- 考察点:确认候选人是否能把 AI 功能落到可靠的 Nuxt 生产链路。
- 回答方向:结合状态、权限、失败恢复、成本、可观测性和部署边界回答,不要只罗列 SDK API。
追问三:反向代理为什么可能缓冲流式响应?
- 考察点:确认候选人是否能把 AI 功能落到可靠的 Nuxt 生产链路。
- 回答方向:结合状态、权限、失败恢复、成本、可观测性和部署边界回答,不要只罗列 SDK API。
推荐阅读
- Nitro WebSocket 与 SSE
- AI SDK UI
- ../advanced/05-nuxt-中如何实现流式-ssr-或流式接口并处理客户端渐进展示-interview