layui upload 的 number 参数仅限制文件选择数量，不控制并发上传；真正并发控制需手动实现队列调度或改用 fetch 分批上传。
layui upload 的 number 参数根本不管并发数
设 number: 3 并不会限制“同时发 3 个请求”，它只影响单次文件选择弹窗里最多能勾选几个文件——而且仅对点击按钮触发的 <input type="file"> 有效，拖拽上传、重复点击都会绕过。浏览器本身有同域并发限制（通常 6 个），但那是 HTTP 层级的硬限制，你无法用 layui 配置项干预。
真正可控的并发控制必须手动节流 + 队列调度
要让最多只有 3 个上传请求在跑，得自己管住 obj.upload() 的调用节奏：
-
auto: false关闭自动上传，把所有待传文件先存进数组（比如pendingFiles = []） - 定义
maxConcurrent = 3和运行中计数器running = 0 - 每次准备调用
obj.upload(index, file)前，检查if (running < maxConcurrent)，否则入队等待 - 在
done或error回调里执行running--，并立即尝试启动下一个排队任务
注意：obj.upload() 是 layui 内部方法，不接受数组，必须逐个调用；index 要从 obj.pushFile() 返回的对象里取键名，不能硬写数字。
更干净的做法：放弃 layui upload 流程，改用 fetch 分批
如果你需要精确、可预测的并发控制（比如稳定压测或避免后端限流），直接跳过 layui 的上传逻辑：
- 设
auto: false，在choose中用obj.pushFile()拿到全部File对象 - 写一个
uploadBatch(files)函数，每次取maxConcurrent个，构造FormData发送 - 用
Promise.allSettled()等这批完成，再取下一批 - 后端接口必须支持接收
files[]字段的 multipart 请求（PHP/Node.js/Spring Boot 都需显式处理数组型文件字段）
这个方案不依赖 layui 的内部状态机，没有回调嵌套陷阱，也避开了 obj.upload() 的隐式行为——比如它会偷偷重试失败请求，而你用 fetch 可以完全掌控重试逻辑。
容易被忽略的关键点
number 和 acceptNum 都是选择阶段的“软限制”，它们不感知已删除、已上传、已取消的文件；拖拽进来的文件永远绕过这两个参数；老版本 layui（如 2.7）压根不支持 acceptNum；真正的并发瓶颈不在前端按钮上，而在后端接口吞吐和浏览器连接池——所以测试时别只看前端界面是否卡住，得抓包确认实际发出的请求数和时间间隔。
