1. 项目背景
"我昨天跟你们的 AI 客服聊了 20 分钟，今天再点进去，它完全不记得我了！"这是用户投诉的最高频词之一。Chat App 的多轮对话记忆默认只在同一个"会话"内生效，一旦用户关闭浏览器、会话过期、或者 conversation_id 丢失，对话上下文就归零了。
这背后涉及一个核心问题：Dify 如何管理会话（Conversation）和消息（Message）的生命周期？会话什么时候创建？历史消息存哪里？什么时候截断？跨天的对话能恢复吗？在 Workflow 和 Agent 中，对话变量（conversation 级变量）和用户变量（user 级变量）又有什么区别？
这些问题不仅在 Chat App 中重要，当你需要用 API 编程调用 Dify 时更关键——你需要手动管理 conversation_id，确保多轮请求归属同一个会话；你需要理解消息的存储和检索机制，避免上下文的"丢失"和"错乱"。本章将深入 Dify 的会话模型，从数据库表结构到 API 用法，从 Chat App 的滑动窗口到 Workflow 的 conversation 变量，帮你真正"掌控对话"。
2. 项目设计
小胖：（满脸委屈）“大师，我写的聊天机器人有个严重 bug——用户说’我叫小胖’，过了几轮能记住。但是用户关掉浏览器，第二天再打开，AI 就像失忆了一样问’你好，请问有什么可以帮你？'这咋整？”
大师：“你碰到的是’会话持久化’问题。Dify 的对话记忆不是存在客户端浏览器的 Cookie 里，而是存在服务端的数据库里。每次对话对
