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