能，但需将uni.request手动包装为Promise；直接使用会失败，因uni.request返回requestTask而非Promise；推荐封装requestPromisify函数并校验statusCode，或使用uni.promisify（HBuilderX 3.1.0+），并发过多时应控制数量、降级或合并接口。
uni-app里Promise.all能直接用吗
能，但要注意uni-app的请求API（uni.request）本身不返回Promise，必须手动包装成Promise才能传给Promise.all。直接写Promise.all([uni.request(...), uni.request(...)])会失败——因为uni.request返回的是requestTask对象，不是Promise实例。
怎么把uni.request转成Promise
最稳妥的方式是封装一个requestPromisify函数，统一处理成功/失败逻辑，并兼容uni.uploadFile等其他API：
const requestPromisify = (options) => {
return new Promise((resolve, reject) => {
uni.request({
...options,
success: (res) => {
if (res.statusCode >= 200 && res.statusCode reject(err)
});
});
};
使用时：Promise.all([requestPromisify({ url: '/api/a' }), requestPromisify({ url: '/api/b' })])。
注意点：
- 不要在
success里直接resolve(res)，否则拿到的是完整响应对象，通常你只想要res.data - 务必检查
statusCode，否则接口返回401/500时Promise.all仍会“成功”解析 - 如果项目已用
uni.promisify（HBuilderX 3.1.0+），可简写为const request = uni.promisify(uni.request)，但要注意它默认不校验状态码
并发太多被节流或报错怎么办
微信小程序、支付宝小程序对同时发起的网络请求数有限制（通常10个），Promise.all会一次性触发全部请求，容易触发平台限流，表现为部分请求卡住或返回fail net::ERR_CONNECTION_REFUSED这类底层错误。
应对方式：
- 控制并发数：用
p-limit或手写分批执行，比如每次最多发5个 - 避免无意义并发：确认这些接口真的需要强一致性；若只是页面初始化加载，可考虑用
async/await串行+缓存优化 - 加错误兜底：
Promise.all只要一个失败就整体reject，如需“尽力而为”，改用Promise.allSettled（注意iOS 12.2以下不支持）
Promise.allSettled在uni-app里安全吗
在H5和App端基本可用（依赖运行时环境），但微信小程序基础库低于2.11.0时不支持Promise.allSettled，调用会报undefined is not a function。真机调试时容易漏掉这个兼容问题。
稳妥方案：
- 用
try...catch包住每个requestPromisify调用，再Promise.all收集结果数组 - 或引入轻量polyfill（如
promise.allsettlednpm包），但需确认uni-app构建是否支持动态require - 更实际的做法：后端合并接口，前端一次请求拿回所有数据，比前端拼并发更可控
真正难的不是写对Promise.all，而是判断哪些请求该并发、哪些该降级、哪些该合并——这得看后端接口设计和用户等待容忍度，不是加个Promise就能解决的。
