可通过任务队列+运行计数器手动控制XMLHttpRequest并发数，如限3个同时上传；需监听onprogress和onloadend，用AbortController（fetch）或isCancelled标志（XHR）中断未发请求，并及时释放File引用防内存泄漏。
用 XMLHttpRequest 手动控制并发请求数量
HTML5 本身不提供「并发上传上限」的原生配置项，XMLHttpRequest 或 fetch 都是单个请求独立发起的。真正可控的是你自己的调度逻辑：限制同时处于 uploading 状态的请求数。
常见做法是维护一个任务队列 + 一个运行中计数器。每次准备发新请求前，检查当前活跃请求数是否小于阈值（比如 3），只有空闲才从队列取下一个任务执行。
- 不要直接循环调用
uploadFile(file)—— 这会瞬间触发全部请求 - 把每个文件包装成 Promise，并用
Promise.allSettled()或手动 await 控制节奏 - 注意监听
xhr.upload.onprogress和onloadend，后者才是真正的完成信号（不是onload）
使用 AbortController 中断排队中的上传任务
当用户取消上传或切换页面时，已入队但未发出的请求应被丢弃，否则可能浪费带宽或触发重复回调。这时候不能只靠 xhr.abort()，因为还没发出去的请求根本没创建 XMLHttpRequest 实例。
更稳妥的方式是在任务对象里保存一个 signal，并在发起前检查：
if (signal.aborted) return;同时在
fetch 中直接传入 { signal } 参数即可自动中断。
立即学习“前端免费学习笔记（深入）”；
-
AbortController对XMLHttpRequest无效，仅适用于fetch - 若必须用
XHR，需自己维护一个isCancelled标志位，在回调开头判断 - 中断正在上传的大文件时，服务端可能仍会收到部分数据，需配合后端做幂等处理
避免 FormData 引用导致内存泄漏
并发上传中常通过 new FormData().append('file', file) 构造请求体。如果文件对象（Blob 或 File）体积大、数量多，而你又没及时释放引用，容易触发浏览器内存警告甚至卡死。
关键点在于：上传完成后，应主动清除对 file 的引用，尤其在闭包或类实例属性中长期持有时。
- 不要把整个
FileList存在全局变量或 React state 中 - 上传成功后立即设
file = null，或用URL.revokeObjectURL()清理本地预览 URL - Chrome DevTools 的 Memory 面板里观察
Detached DOMTree和JS Heap可快速定位这类问题
fetch + Promise 队列实现示例（限 3 并发）
下面是一个轻量、可直接嵌入项目的并发控制器，不依赖第三方库：
function uploadWithConcurrency(files, url, maxConcurrent = 3) {
const queue = files.map(file => () =>
fetch(url, {
method: 'POST',
body: (() => {
const fd = new FormData();
fd.append('file', file);
return fd;
})()
}).then(r => r.json())
);
const running = new Set();
const results = [];
function runNext() {
if (queue.length === 0 && running.size === 0) return;
if (running.size >= maxConcurrent || queue.length === 0) return;
const task = queue.shift();
const p = task().finally(() => {
running.delete(p);
runNext();
});
running.add(p);
results.push(p);
}
while (running.size < maxConcurrent && queue.length > 0) {
runNext();
}
return Promise.allSettled(results);
}
// 使用：
uploadWithConcurrency(fileInput.files, '/api/upload', 3)
.then(results => console.log('全部完成', results));
这个实现没有加重试、取消、进度反馈，但结构清晰、无外部依赖。实际项目中，真正难的不是并发数本身，而是上传状态与 UI 的同步粒度——比如显示每个文件的独立进度条，意味着你要为每个 fetch 单独监听 ReadableStream，那又是另一层复杂度了。
