uni.uploadfile不支持直接传数组，必须手动循环调用：app/小程序端遍历tempfilepaths逐个上传，h5端需用file实例数组并设files字段；须控制并发、完善三回调、显式管理状态。
uni.uploadFile 不能直接传数组，必须手动循环调用
uni.uploadFile 是 uni-app 原生 API，只接受单个 filePath（App/小程序）或 files（H5），不支持传数组、也不识别 tempFiles 对象。常见错误如 uploadFile:fail invalid file path，基本都是因为把 tempFilePaths 数组直接塞进 filePath 字段导致的。
真实做法是：先调用 uni.chooseImage 或 uni.chooseMessageFile 拿到 tempFilePaths，再用 for / for...of / map 遍历上传。H5 平台要额外注意——filePath 被完全忽略，必须改用 files: [{ uri: FileInstance, name: 'file', fileName: 'xxx.jpg' }]。
- App 和小程序端：每个
uni.uploadFile调用对应一个临时路径，name字段建议统一为'file'或后端约定的数组名（如'files[]'） - H5 端：必须从
<input type="file">的event.target.files中取File实例，不能用任何“路径字符串” - 多文件共用的
formData（如用户 ID、业务类型）可直接写在每次调用的配置里，无需额外拼接
并发控制不是可选项，而是平台硬限制
微信小程序明确限制同时活跃的 socket 连接数（通常 ≤10），App 端也有系统级连接池限制。盲目用 Promise.all 发起 20 个 uni.uploadFile，大概率触发失败、超时或静默丢包。
推荐做法是实现轻量级上传队列，控制并发数在 3–5 之间。可用 for...of + await 串行（简单但慢），或用 p-limit 类库、手写 Promise 队列（平衡速度与稳定性）。
- 避免
Promise.all：一个失败整批 reject，无法定位哪个文件出错，也不利于重试 - 用
try/catch包裹每个上传任务，单独记录成功/失败状态，方便 UI 展示“重试按钮” - 上传任务 ID 建议带索引（如
upload-${i}），便于和原始tempFilePaths[i]关联
上传状态必须显式管理，不能只依赖 success 回调
只写 success 不写 fail 和 complete，会导致三种典型问题：上传失败无提示、loading 状态卡死、用户重复点击提交按钮。
每个 uni.uploadFile 调用都应绑定三类回调，并同步更新本地文件列表中的状态字段（如 status: 'uploading' | 'success' | 'failed'）。
-
onProgressUpdate可用于实时更新进度条，但注意它只在 App 和小程序生效，H5 不支持 -
fail必须捕获具体错误码：fail net::ERR_CONNECTION_REFUSED是网络问题，fail invalid file path是路径无效，fail request:fail timeout是超时 -
complete用来统一收尾：隐藏 loading、启用提交按钮、触发下一步逻辑
request 封装层如何兼容文件上传
如果你已封装了 request（带 token、loading、拦截器等），不要绕过它去直接调用 uni.uploadFile。应在封装中新增 uploadFile 方法，把原生能力“桥接”进来。
关键点是参数归一化：接受 filePaths: string | string[]，内部自动转为数组并循环调用；复用已有 header（如 Authorization）、hideLoading 控制；返回 Promise 数组，顺序与输入一致。
- 后端接收多文件时，
name字段需匹配：PHP 用files[]，Node.js Koa 用ctx.request.files.files，Spring Boot 用@RequestParam("files[]") MultipartFile[] files - 上传任务取消不可靠：原生
uploadTask.abort()在部分安卓机型上无效，更稳妥的是用变量标记“是否已取消”，在success/fail中判断跳过后续逻辑 - 大文件上传建议加 size 校验前置：遍历
tempFiles时读.size，超限直接uni.showToast提示，避免上传一半才失败
fail 当摆设，或者用 Promise.all 把错误吞掉了。
