必须由业务系统自行生成并透传conversation_id，它是识别同一用户多次提问的唯一依据，用于流式响应、上下文延续和会话存档，需前端UUIDv4或后端统一分配，严禁用手机号、session_id等不可控字段，且多端需加来源前缀隔离。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
在客服系统中接入火山引擎智能对话服务后，需要为每个用户会话分配唯一且可追溯的标识，否则多个聊天窗口消息混杂、上下文错乱、历史记录无法关联，人工转接时根本分不清谁是谁。
理解会话标识（Conversation ID）的作用
火山引擎的智能对话接口不自动维护会话状态，【必须由业务系统自行生成并透传 conversation_id】。这个 ID 是服务端识别“这是同一个用户第几次提问”的唯一依据，也是流式响应、上下文延续、会话存档的锚点。
它不是用户手机号或账号ID——同一用户换设备、清缓存、多开浏览器标签页，都应视为新会话；它也不是时间戳——毫秒级重复概率虽低，但并发请求下极易撞车；它必须是业务侧可控、可审计、可回收的字符串。
生成稳定唯一的 conversation_id
方法一：前端生成 UUIDv4（适合 Web 端轻量场景）
用户点击“开始咨询”按钮时，前端 JavaScript 调用 crypto.randomUUID() 生成一个 32 位无横线 UUID，例如 8a3b9c1e2f4d5a6b7c8d9e0f1a2b3c4d，拼接前缀如 web_ 后作为 conversation_id 传入请求体。
方法二：后端统一分配（推荐用于 App/小程序/多端统一管理）
用户首次发起对话请求时，后端服务调用数据库 INSERT INTO conversations (status, created_at) VALUES ('active', NOW())，用 LAST_INSERT_ID() 或 RETURNING id 获取自增主键，再通过 base32 编码（非 base64）转为 8～12 位短字符串，例如 CONV-7XK9P2M。此 ID 可直接存入 Redis 并设置 7 天过期，后续该用户同会话所有请求都复用此值。
注意：不要用用户手机号直接作 conversation_id——一旦号码被回收重放，历史会话数据将错误归属；也不要使用 session_id，它在用户关闭浏览器后即失效，无法支撑跨设备会话恢复。
在 API 请求中正确携带会话标识
第一步：确认请求体结构符合火山引擎 ChatCompletion 接口规范
conversation_id 必须放在 request body 的顶层字段，不能嵌套在 messages 或 metadata 里。官方 SDK 示例中明确要求字段名为 conversation_id，类型为 string，长度不超过 64 字符。
第二步：构造完整请求示例
```json
{
"model": "ep-2025-qwen-plus",
"messages": [{"role": "user", "content": "你好"}],
"conversation_id": "CONV-7XK9P2M",
"stream": true
}
```
第三步：验证服务端是否成功接收
在火山引擎控制台「智能对话 → 调用日志」中筛选该 conversation_id，确认每条日志的 request_id 都对应唯一 conversation_id，且 response 中返回的 usage 字段包含该 ID。若日志中 conversation_id 显示为空或 null，说明请求体未正确赋值或字段名拼写错误（如写成 conv_id、session_id、cid 等）。
多窗口共存时的会话隔离策略
当同一用户在 PC 端、微信小程序、App 同时打开三个聊天窗口，必须确保三者使用完全不同的 conversation_id。
可在生成逻辑中加入来源标识：PC 端用 pc_ 前缀，小程序用 wx_ 前缀，App 用 app_ 前缀，再各自拼接独立 UUID 或短码。这样即使用户 ID 相同，三个窗口的上下文也物理隔离，不会互相污染。
这一步不做，用户在小程序问“订单还没发货”，转到 PC 端接着问“怎么退款”，模型可能把两句话当成连续对话，错误关联订单号——因为 conversation_id 相同，服务端认为是同一会话的第二轮提问。
会话 ID 生命周期管理
① 创建：用户首次发送消息时生成，立即写入 Redis 缓存，TTL 设为 7 天。
② 续期：每次收到该 conversation_id 的新请求，执行 Redis EXPIRE key 604800 刷新过期时间。
③ 关闭：用户点击“结束会话”或客服主动关闭对话，调用后端接口将该 conversation_id 对应的 Redis key 设置为 expired 状态，并异步归档至 MySQL 的 conversations 表，status 改为 closed。
④ 回收：Redis 中过期未续期的 key 自动清除；MySQL 中 status=closed 且 last_message_time 超过 90 天的记录，由定时任务批量删除。
