按理说，

Vibe Coding 全栈实战：章鱼哥解题 ｜对话持久化与使用者数据隔离

上一期我们把前后端鉴权链路打通后后端终于能识别“这个请求来自哪个使用者”。但这只是身份链路的起点，

在实际使用中，学生往往会连续提问、追问同一概念。若页面刷新后对话消失，或切换登录账号时没有清晰的消息边界，体验就会大打折扣。为了解决这些痛点，本期我们将把使用者身份接进对话链路。让当前对话能保存、能恢复，后续消息能够继续进入同一个 thread。说起来，

一、为什么只会回答还不够

前几期已经完成了一个回答链路：

使用者输入问题 → 后端检索教材 → 组装上下文 → LLM 生成回答 → 前端流式展示

虽然程序能“回答”。但无法保证它是一个连贯的对话产品。学生通常不是一次性提问，而是在同一段内容上多次交流。若每次请求都被当作孤立的问题处理，就会导致：

• 页面刷新后历史消息丢失
• 发送新消息时后端只能当成孤立问题处理
• 不同使用者的消息没有明确隔离边界
• 前端只能靠 localStorage 暂存。换设备也无法从后端恢复当前对话

需要实现身份 → 对话 → 消息历史 → 当前对话恢复的完整流程。

二、这一期要做什么

改动可拆分为三条线：

1. 后端对话编排：
2. 消息持久化：
3. 前端对话恢复：init 事件返回给前端。

*本期不做多对话侧边栏、重命名、置顶、删除等功能，以免分散注意力*

三、后端：从流水线到 StateGraph

Mega flow simplified:

flowchart TD
START --> CLASSIFY
CLASSIFY -->|textbook| RETRIEVE
CLASSIFY -->|unrelated| REFUSE
RETRIEVE --> RESPOND
RESPOND --> END
REFUSE --> END
CLASSIFY -. 自动 checkpoint .-> CP1
RETRIEVE -. 自动 checkpoint .-> CP2
RESPOND -. 自动 checkpoint .-> CP3
REFUSE -. 自动 checkpoint .-> CP4
CP1 --> PG
CP2 --> PG
CP3 --> PG
CP4 --> PG

This fixed‑flow approach keeps boundaries clear: each node has a deterministic responsibility。easing debugging.

四、消息如何保存下来

User pain point: Alice 刷新页面看到空白，对不起我之前说的内容全没了。

• No business table design: 我们直接利用 PostgresSaver 保存 graph checkpoint，而不是手写 .
• Main design: conversation_id = LangGraph thread_id;user_id = 当前登录使用者;messages = LangGraph state 内部列表。其实，
• Persistent checkpoints: checkpoint 包含 alerts。intent,context_chunks,sources,AIMessage...,并非仅仅是业务表字段。恢复时从 checkpoint 提取 ,并映射引用来源到前端字段。
• User isolation: 在 graph config 中加入 user_id=login_user.id;,后续查询时过滤掉别人的 thread。确保不会把别人的聊天恢复给你。
• Create & reuse conversation ID:

  if { // first message }
  conversationId = uuidv4;// backend generates
  graph.config.thread_id = conversationId;}
  POSTGRESER.saveCheckpoint;
  

五、conversation_id 怎么回到前端

This is often most fragile part.

• User pain point: "我每次发送新问题都被程序当成新的聊天不知道为什么答案不连贯".
1. Pagenav: call GET /api/conversations/current to fetch current history . If history exists。render immediately.
2. SSE stream initiation:
   • If conversationId is null => backend generates a new UUID.
   • SSE emits an init event back with that UUID so front-end can store it for subsequent requests.

    The init event is small but critical: it tells front-end which thread to reuse for all future messages in this session.

FE→BE POST /api/chat/stream {question,conversationId?}
if BE generate UUID;
BE→FE SSE init {conversation_id}
FE store conversationId locally;
BE→Graph stream…

六、前端：从 Chat UI 到 ChatController

- 使用者痛点：打开聊天页面却看不到之前的问题和答案；发完一条就被覆盖了，-> 我们用 useChatController 把所有状态集中管理，再让 UI 单纯渲染。-

# 如何验证是否实现了“当前对话可以恢复”? 1️⃣ 发第一条问题 -> 看是否收到 init SSE 并获取 conversationID。2️⃣ 刷新页面 -> 调用 GET /api/conversations/current，看是否得到相同 ID 和历史消息。3️⃣ 再发第二条问题 -> 前面拿到的 ID 是否被携带，而且响应仍属于同一线程。4️⃣ 切换账号 -> 用不同 userID 请求，一样的 conversationID 是否被过滤掉。5️⃣ 检查 Postgres 数据库里对应 thread 的 checkpoints 是否包含完整 HumanMessage 与 AIMessage。🔍 如果全部通过那就说明你已完成了第一个可复用“当前会话”的功能。🛠️ 如果有失败点，可以检查： • Front-end 未正确存储/读取 `conversationId`？• Back-end 未在 SSE init 中回传？• Graph 配置中缺少 `user_id` 或 `thread_id`？🧪 一步步排查即可，✔️ 完成此验收，即可放心进一步实现多会话列表、标题生成等高级功能。diff + ✅ 成功：确认 Conversation ID 正确回传且持续使用 - ❌ 未成功：请检查上面列出的关键点并逐项定位错误原因。💡 记住：**User Isolation** 是主要！任何时候都要确保只有相同 `user_id` 能访问对应 `thread`。否则你再精细设计多会話列表也无济于事。🔗 如果想快速验证 PostgresSaver 工作，你可以直接查看数据库： sql SELECT * FROM langgraph_checkpoints WHERE thread_id = 'your_conversation_uuid';如果看到完整 JSON 状态记录，就是成功啦！📦✨ 🎉祝你编码愉快~ 🚀💻💬