不会直接失败，但因App端原生层并发限制（通常6–10个），Promise.all触发的uni.request会出现静默丢弃、部分结果为undefined或Network无记录等问题；需用p-limit或手写队列主动限流。
uni-app 中 Promise.all 在 App 端会直接失败吗？
不会直接失败，但多数情况下会「看似成功、实则漏数据」或「部分请求静默丢弃」。App 端（尤其是 iOS WKWebView 和 Android X5 内核）对并发请求数有硬性限制，Promise.all 本身不控制并发，只是并发触发所有 uni.request，一旦超出底层限制（通常为 6–10 个），多余请求会被浏览器内核静默拒绝或延迟极久，且不抛错、不进 fail 回调。
为什么 Promise.all + uni.request 在 App 上容易出问题
根本原因是 uni.request 不是标准 fetch 或 axios，它最终委托给原生容器发起请求，而原生层对并发连接数做了节流。常见表现包括：
-
Promise.all返回的数组中某些项是undefined或空对象，但没报错 - 部分请求在 DevTools 里完全看不到 Network 记录（尤其 iOS）
- 同一组 URL，在 H5 正常，在 App 端总是固定第 7 个开始失败
- 响应时间忽长忽短，且无规律
真正可用的并发控制方案：手写队列 or p-limit
必须主动限流，不能依赖 Promise.all 自身。推荐两种轻量做法：
- 用
p-limit（需 npm 安装）：const pLimit = require('p-limit');<br>const limit = pLimit(6); // 限制同时最多 6 个<br>const promises = urls.map(url => limit(() => uniRequest({ url })));<br>const results = await Promise.all(promises); - 手写简单队列（零依赖）：
async function runInLimit(tasks, limit = 6) {<br> const results = [];<br> for (let i = 0; i const batch = tasks.slice(i, i + limit);<br> results.push(...await Promise.all(batch.map(t => t())));<br> }<br> return results;<br>}<br>// 使用：<br>const requests = urls.map(url => () => uniRequest({ url }));<br>const results = await runInLimit(requests, 6);
封装时必须绕开的坑
如果你已封装了 request 方法，注意以下三点：
- 不要在封装函数里直接
return Promise.all([...])—— 这等于把并发压力全甩给底层 - 避免在
success回调里再调uni.request并塞进同一个Promise.all，嵌套会放大并发数 -
uni.addInterceptor对并发控制无效，它只影响单个请求的生命周期，不干预调度时机
最易被忽略的是：App 端的并发限制是「原生层全局生效」，不是按页面或 JS 上下文隔离的。哪怕你分了 10 个组件各自发 5 个请求，只要同一时刻活跃请求数超限，就会相互干扰。
