WebSocket不直接查数据库，而是由后端异步执行分布式查询并维护任务进度，通过WebSocket将结构化进度消息（如progress、stage）实时推送给前端，前端据此更新UI；需处理连接恢复、任务完成/失败通知，并避免阻塞、高频推送等陷阱。
WebSocket 本身不直接查询数据库，它只是在浏览器和服务器之间建立一条全双工、低延迟的通信通道。要实现“网页端实时跟踪分布式数据库查询进度”，关键在于后端服务如何将查询任务的执行状态（如已扫描分片数、已完成百分比、当前阶段等）通过 WebSocket 主动推送给前端。HTML5 的 WebSocket API 负责接收并响应这些消息。
1. 后端需为每个查询任务分配唯一 ID 并维护进度状态
当用户在网页发起一个耗时的分布式查询（例如跨 12 个节点的聚合分析），后端应立即生成一个任务 ID（如 task_7a2f9e4b），启动异步查询流程，并在内存或轻量存储（如 Redis）中初始化该任务的进度对象：
- status: "running"
- progress: 0
- scanned_shards: []
- message: "正在连接数据节点..."
随着各分片查询完成，后端主动更新该状态，并通过 WebSocket 将增量进度广播给对应客户端连接（通常按任务 ID 关联 WebSocket Session）。
2. 前端用 WebSocket 监听任务进度事件
页面发起查询后，立即创建 WebSocket 连接，并在 onmessage 中解析结构化进度消息。推荐使用 JSON 格式统一约定字段：
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
立即学习“前端免费学习笔记（深入）”；
// 示例消息
{
"type": "progress",
"task_id": "task_7a2f9e4b",
"progress": 65,
"stage": "reducing",
"elapsed_ms": 2840
}
前端可据此更新 UI 元素，例如：
- 用 <progress> 标签显示百分比
- 动态渲染阶段提示文字（如“正在合并结果…”）
- 记录耗时并预估剩余时间（progress > 0 且有增速时可简单线性估算）
3. 处理连接异常与任务生命周期对齐
WebSocket 连接可能断开，而查询任务仍在后端运行。因此需设计健壮的状态同步机制：
- 前端连接重建后，发送 {"type":"resume","task_id":"..."} 请求当前进度
- 后端收到 resume 指令时，查 Redis 或任务管理器，返回最新状态
- 查询完成后，推送 {"type":"done","result_url":"/api/results/xyz"}，前端跳转或加载结果
- 超时或失败时推送 {"type":"error","message":"节点 timeout"}
4. 避免常见陷阱
实际部署中容易忽略但影响体验的关键点：
- 不要在 WebSocket 连接里直接执行数据库查询：必须异步调度（如用线程池、协程或消息队列），否则会阻塞整个 WS 连接处理线程
- 避免高频无意义推送：进度从 0% → 1% → 1% → 2%… 可做节流（例如最小间隔 300ms，或仅当 progress 变化 ≥ 2% 才发）
- 注意同源限制与反向代理配置：Nginx/Apache 需显式开启 WebSocket 支持（Upgrade 和 Connection 头透传）
- 任务 ID 必须全局唯一且可追溯：便于日志关联、问题排查和审计，建议结合时间戳 + 随机段生成
