WebSocket不直接支持文件上传，应采用“HTTP上传+WebSocket推送”混合方案：前端用HTTP传文件并携带uploadId，后端关联WebSocket会话实时推送进度。
WebSocket 本身不直接支持文件上传，它只是全双工通信通道。要实现大文件上传进度的后端实时反馈，需结合传统 HTTP 文件上传（如 multipart/form-data 或分片上传）与 WebSocket 主动推送机制——即：前端用 HTTP 传文件，后端在处理过程中通过已建立的 WebSocket 连接，主动向该用户推送进度消息。
为什么不能只靠 WebSocket 传大文件？
WebSocket 协议没有内置文件传输语义，也缺乏分块、断点续传、MIME 类型识别等 HTTP 原生支持的能力。浏览器 FormData 无法直接通过 WebSocket 发送；手动读取 File 对象并分片发送虽可行，但需自行实现校验、顺序控制、错误重传，复杂度高且易出错。实际项目中，更推荐“HTTP 上传 + WebSocket 推送”的混合方案。
前后端协作的关键设计
核心思路是：上传请求携带唯一标识（如 uploadId），后端启动上传任务后，将该 ID 与 WebSocket Session 关联；上传过程中，服务端定期计算进度，并通过 WebSocket 向对应客户端推送 JSON 消息。
-
前端：用
fetch或XMLHttpRequest发起上传，同时维持一个长连接的 WebSocket（URL 可带 token 或 uploadId） -
后端（以 Node.js/Express + ws 为例）：在接收上传时，生成 uploadId → 存入内存 Map 或 Redis；启动文件写入/解析流程，期间定时更新进度对象；通过 WebSocket server 查找绑定该 uploadId 的 client，推送
{"type":"progress","uploadId":"xxx","percent":65} -
关联逻辑：可在 WebSocket 连接建立后，让前端立即发一条
{"action":"bind","uploadId":"xxx"}消息，后端将其 session 与 uploadId 映射缓存
注意上传过程中的状态一致性
大文件上传可能跨分钟级，需防范连接中断、重复绑定、超时清理等问题：
立即学习“前端免费学习笔记（深入）”；
- WebSocket 断开时，后端应清除对应 uploadId 的绑定关系，避免消息误推
- 上传完成或失败后，主动推送
{"type":"done","status":"success"}或{"type":"error","msg":"disk full"}，前端据此关闭监听 - 建议为每个 uploadId 设置 TTL（如 30 分钟），超时自动清理进度状态，防止内存泄漏
- 若需多实例部署，WebSocket 绑定关系需存到 Redis 等共享存储，而非进程内存
替代方案：使用 Server-Sent Events（SSE）更轻量？
如果只需单向进度推送（服务端→前端），且兼容性可接受（不需支持 IE），SSE 是更简洁的选择：它基于 HTTP 长连接，天然支持重连、事件类型区分，无需维护双协议连接。但若业务中已深度依赖 WebSocket（如还需实时通知审核结果、协作编辑等），继续复用 WebSocket 更合理。
