上传失败时应保存原始 FileList 并复用，避免清空 input.value；重试调用独立上传函数传入该列表；区分可重试状态码（如500/503）或服务端 retryable 字段；FormData append 须带 file.name。
上传失败时怎么让 input[type="file"] 保持原文件状态
浏览器出于安全限制，一旦 input[type="file"] 触发了表单提交或 JS 清空过 value，它的值就无法通过 JS 重新赋值（哪怕赋成原来的路径也不行）。所以“重试”不是靠恢复文件，而是保留用户选择意图，避免重复点选。
- 别写
fileInput.value = ""或fileInput.value = fileInput.value—— 这会清空且不可逆 - 上传失败后，直接复用原始
FileList对象：把event.target.files存到变量里，重试时用它构造新 FormData - 如果用了封装库（如 axios），确保没在请求拦截器里无意调用
formData.delete("file")或覆盖了原始 File 对象
重试按钮点击后如何不触发二次选择
关键在绕过 input[type="file"] 的交互限制：它只响应用户真实点击，不能被 JS click() 激活（现代浏览器会静默忽略）。所以重试逻辑必须脱离“再次点开文件选择框”这个思路。
- 把上传逻辑抽成独立函数，例如
uploadFiles(fileList)，失败后直接调用它，传入之前存的FileList - 重试按钮不要绑定
click到input元素上，否则白忙活 - 如果 UI 要求按钮样式像“重新选择”，那就纯用 CSS 模拟，背后仍是调用已有文件数据
服务端返回 500/400 后前端怎么区分是否可重试
不是所有失败都适合重试。比如 413 Payload Too Large 或 400 Bad Request（参数错、类型不符）重试毫无意义，反而可能反复失败。
DeepBI DHTML 页面生成器
下载
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 检查响应状态码：
500、502、503、504和部分429可考虑重试；400、401、403、413基本要提示用户改操作 - 服务端最好在错误响应体里加
retryable: true字段，比硬编码状态码更可靠 - 加简单退避：第一次失败后等 500ms 再重试，第二次等 1s，最多试 2 次 —— 避免瞬间连打压垮接口
FormData 里传 File 对象为什么上传后服务端收不到
常见于手动创建 FormData 并 append 文件但漏掉关键细节。浏览器对 File 和 Blob 的处理很敏感。
- 确保 append 时第三个参数传了文件名：
formData.append("file", file, file.name)—— 不传的话某些后端（如 Express multer）会解析失败 - 别用
JSON.stringify()包一层再塞进 FormData，FormData 不吃 JSON 字符串 - 如果用了
fetch，别设headers: { "Content-Type": "multipart/form-data" }—— fetch 会自动设 boundary，手动设反而破坏结构
事情说清了就结束。真正卡住人的往往不是“怎么加个重试按钮”，而是上传链路里哪一环悄悄清掉了 files、或者服务端错误没分清类型就盲目重试。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
