根据参考资料中的描述，停止令牌（stop token）的实现机制及用户点击暂停后的流程如下： --- ### **停止令牌的底层实现** 1. **令牌生成** - 当用户发起对话时，前端会生成一个**唯一的停止令牌**（如随机字符串或JWT），并在WebSocket请求头中携带该令牌。 - 示例：`Authorization: Bearer <stop_token>`。 2. **服务端验证** - 后端通过解析JWT或校验令牌有效性，确认请求来源合法性（防止恶意中断他人会话）。 - 验证通过后，该令牌与当前会话绑定，存储在内存或Redis中。 --- ### **用户点击暂停后的流程** 1. **发送中断信号** - 用户点击暂停按钮时，前端携带**相同的停止令牌**向服务端发送中断请求（如`POST /chat/stop`）。 - 服务端收到请求后，验证令牌是否与当前会话匹配。 2. **终止模型推理** - 服务端调用DeepSeek API的**中断接口**（如`stream=false`或`stop=true`参数），或直接关闭HTTP连接。 - **资源释放**： - 取消正在运行的模型推理任务，释放GPU/CPU资源。 - 清除当前会话的流式响应缓冲区。 3. **清理会话状态** - **不保存中断内容**： - 若回答未完成（未收到`[DONE]`标志），本轮对话**不写入Redis**（避免保存不完整回答）。 - **保留会话上下文**： - 会话ID仍存在于Redis中，用户可继续后续对话。 4. **前端响应** - 服务端通过WebSocket向前端发送`{"type": "stopped"}`消息。 - 前端停止渲染流式内容，显示“回答已中断”提示。 --- ### **关键设计点** | **环节** | **实现细节** | |------------------|-----------------------------------------------------------------------------| | **令牌安全** | 通过JWT绑定用户ID，防止跨会话恶意中断。 | | **资源管理** | 中断时立即释放模型推理资源，避免资源泄漏。 | | **数据一致性** | 仅完整回答（含`[DONE]`）才写入Redis，中断内容不保存。 | | **会话连续性** | 会话ID持续存在，支持用户后续追问（历史记录未中断）。 | > 示例代码逻辑（伪代码）： > ```python > def handle_stop(stop_token): > if validate_token(stop_token): # 验证令牌 > cancel_generation() # 终止模型推理 > if not is_stream_completed(): # 若未完成 > skip_redis_save() # 不保存中断内容 > send_websocket("stopped") # 通知前端 > ``` 通过此机制，用户可随时安全中断生成，同时保证会话上下文和系统资源的可靠性。