上传完成后前端应切换为“处理中”状态并轮询或用websocket等待后端处理结果，需区分上传完成与处理完成，配合abortcontroller取消请求，后端提供含uploadid和status的统一接口响应。
上传进度到 100% 后，后端通常还在处理文件（如压缩、转码、校验、入库等），此时前端不能直接认为“上传完成”，而应切换为“处理中”状态，用转圈加载提示用户等待结果。关键在于：**区分“上传完成”和“处理完成”两个阶段，且保持请求不中断、UI 状态清晰。**
监听上传完成，立即发起轮询或改用长连接
原生 XMLHttpRequest 或 fetch 上传结束（onload 或 then）只代表文件已发给服务端，并非业务完成。此时应：
- 隐藏上传进度条，显示「处理中…」转圈图标（可用
<div class="spinner"></div>+ CSS 动画） - 发起轮询：调用一个查询接口（如
/api/upload/status?uploadId=xxx），每 1–2 秒检查一次处理状态 - 收到
{ status: "success", data: {...} }或{ status: "failed", message: "..." }后停止轮询，更新 UI - 更优方案是后端支持 WebSocket 或 Server-Sent Events（SSE），上传完成后由服务端主动推送处理结果，避免轮询开销
用 AbortController 配合轮询，确保可取消
用户可能在处理中关闭弹窗或跳转页面，需及时清理定时器和请求：
- 创建
const controller = new AbortController() - 轮询时在
fetch(url, { signal: controller.signal })中传入 signal - 组件卸载或用户取消时调用
controller.abort()，并清除setInterval - 捕获
AbortError避免未处理的 rejected promise 报错
后端需提供明确的处理状态接口
前端能否优雅等待，高度依赖后端设计。建议后端返回统一结构：
- 上传成功响应中必须返回唯一标识，如
{"uploadId": "u_abc123", "status": "uploading"} - 状态查询接口返回字段至少包含：
status（uploading/processing/success/failed）、progress（可选，用于展示“正在生成缩略图…”等细化提示）、message（失败原因） - 避免让前端靠 HTTP 状态码（如 200/500）判断业务结果——500 是服务异常，不是“处理失败”
CSS 转圈提示要轻量且可访问
不用引入大体积 UI 库，几行 CSS 就够：
.spinner {
width: 20px;
height: 20px;
border: 2px solid #eee;
border-top-color: #007bff;
border-radius: 50%;
animation: spin 1s linear infinite;
}
@keyframes spin {
to { transform: rotate(360deg); }
}
同时加上 aria-live="polite" 和文字说明（如“文件处理中，请稍候”），保障屏幕阅读器用户感知状态变化。
