Dify多轮对话中断后需无缝接续：前端生成并持久化session_id，重连时复用该ID及execution_id；后端通过resume API恢复PAUSED状态工作流；同时启用上下文消息截取防token超限。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
当Dify工作流在多轮对话中因网络抖动、前端刷新或服务重启意外中断，用户返回后需无缝接续未完成的对话流程，而不是从头开始或报错退出。
确保会话标识全程一致
第一步：在前端发起首次请求时，生成一个稳定且可复用的 【session_id】，推荐格式为 sess_{user_id}_{timestamp}（如 sess_u12345_1729489200），并存入 localStorage 或 IndexedDB。
第二步：后续所有请求（包括重连）必须携带该 session_id，通过 HTTP Header X-Session-ID 传入，不可每次调用都重新生成。
第三步：若用户清除了浏览器缓存导致 session_id 丢失，需在重连前主动查询后端会话恢复接口（如 /api/v1/session/restore?user_id=u12345），由服务端根据用户 ID 查 Redis 中未过期的活跃会话并返回原 session_id。
这一步漏掉会导致 Dify 认为是全新会话，历史 messages 全部丢弃——即使 Redis 里还存着数据，也因 key 不匹配而无法加载。
前端流式重连逻辑实现
方法一：WebSocket 断线重连（适用于长连接模式）
监听 onclose 事件，检测 event.code === 1006（异常关闭）时触发重试；使用指数退避策略，第1次等1秒，第2次等2秒，第3次等4秒，最多重试5次；每次重连必须复用原始 【session_id】 和 【execution_id】（若已获取）。
方法二：Fetch 流式中断续传（适用于 HTTP SSE）
在 response.body.getReader() 抛出网络错误后，记录已接收的 chunk 数量和最后一条完整 message 的 index；重连请求时在 header 中添加 X-Resume-From: 42，后端据此跳过已成功推送的前42条消息，从第43条继续流式输出。
注意：SSE 重连默认会带 last-event-id，但 Dify 原生不识别该字段，必须自行在中间层解析并注入上下文参数。
后端强制恢复中断会话
当用户明确点击“继续上次对话”按钮，且前端能提供原始 execution_id（如 exec-abc789），后端应直接调用 Dify 工作流恢复 API：
POST /api/workflows/{workflow_id}/resume
请求体必须包含：
{ "execution_id": "exec-abc789", "inputs": { "resume_flag": true } }
该操作将唤醒处于 PAUSED 状态的工作流实例，并从最近保存的检查点继续执行；若状态已是 INTERRUPTED_ERROR，则此请求会失败，需引导用户重启任务。
这一步不能省略“execution_id”，仅靠 session_id 无法定位具体哪一次中断的执行实例——一个 session_id 可能对应多次独立启动的工作流。
自动截断旧消息防止爆 token
进入 Dify 后台 →「工作流」→「上下文注入」节点 → 开启「启用历史消息截取」→ 设置「保留最近 8 轮」→ 勾选「优先保留带 metadata 的消息」。
这样即使用户断开又重连多次，Dify 也会自动丢弃早期无 metadata 标记的普通问答轮次，只留下含关键状态（如 {"step":"address_collected"}）的消息，确保上下文精简且语义完整。
不设截断上限可能导致模型输入超长，直接触发 400 错误并中断响应流——此时用户看到的是空白或报错，而非等待中的加载态。
