Promise.all会阻塞加载状态直至所有请求完成，导致UI卡顿；推荐用Promise.allSettled实现“尽力而为”并发加载，或为Promise.all添加超时控制，并按模块粒度管理loading状态。
Promise.all 会阻塞整个加载状态直到所有请求完成
如果你用 Promise.all 包裹多个 API 请求，但其中某个请求特别慢（比如 5 秒），那整个加载状态就会卡住 5 秒——哪怕其他请求 200ms 就返回了。这不是 Promise.all 的 bug，而是它“全成功才 resolve”的语义决定的。
常见错误现象：loading 状态一直为 true，UI 卡顿，用户以为页面卡死；后端日志显示部分接口早已返回，前端却没响应。
实操建议：
- 确认业务是否真的需要「全部完成才更新 UI」——多数场景其实只要「任一失败就报错，其余成功即可用」，这时该用
Promise.allSettled - 如果必须等全部成功（比如表单提交 + 文件上传 + 权限校验三者缺一不可），那就接受这个阻塞逻辑，并加超时兜底
- 别在
Promise.all外层直接设loading = true→await Promise.all(...)→loading = false，这会让 loading 状态无法反映真实进度
用 Promise.allSettled 替代 Promise.all 更适合加载状态管理
Promise.allSettled 不会因为某个请求失败就中断，它总是返回一个包含每个子 promise 状态（fulfilled 或 rejected）的对象数组，更适合做「尽力而为」的并发加载。
使用场景：仪表盘拉取用户信息、订单列表、通知未读数——三个接口彼此独立，一个挂了不该让另外两个白跑。
实操建议：
- 把每个请求包装成独立 promise，避免在
Promise.allSettled内部 throw（否则你得额外 catch） - 检查每个结果的
status字段再决定如何更新 state，例如：const results = await Promise.allSettled([fetchUser(), fetchOrders(), fetchNotifications()]);<br>results.forEach((res, i) => {<br> if (res.status === 'fulfilled') {<br> setData(prev => ({ ...prev, [keys[i]]: res.value }));<br> } else {<br> console.warn(`Request ${keys[i]} failed:`, res.reason);<br> }<br>}); - 注意：
Promise.allSettled是 ES2020 特性，IE 完全不支持，如需兼容请用promise-all-settledpolyfill 或手动实现
给 Promise.all 加超时控制防止加载状态无限等待
即使你坚持用 Promise.all，也该限制最长等待时间。否则网络抖动或后端异常会让 loading 状态永远不关闭。
性能影响：超时本身不耗资源，但能避免用户长时间等待带来的跳出率上升；同时避免因单个慢请求拖垮整个页面交互流。
实操建议：
- 不要自己手写
setTimeout+Promise.race，容易漏掉清理逻辑；推荐用现成工具函数，比如：function timeout(promise, ms) {<br> return Promise.race([<br> promise,<br> new Promise((_, reject) =><br> setTimeout(() => reject(new Error(`Timeout after ${ms}ms`)), ms)<br> ),<br> ]);<br>}<br>// 用法<br>await Promise.all([<br> timeout(fetchUser(), 3000),<br> timeout(fetchOrders(), 3000),<br>]); - 超时时间建议设为 P95 响应时长的 1.5 倍，而不是拍脑袋定 5s —— 查查你的监控数据
- 超时错误要和业务错误区分开，比如在 UI 上提示「部分数据加载较慢，正在重试…」而不是「请求失败」
加载状态粒度比「全局 loading」更实用
统一 loading 状态听起来简洁，但实际体验差：用户看到「加载中」却不知道是哪个模块卡住了，也无法单独刷新某一块。
容易踩的坑：用一个 isLoading boolean 控制整个页面的 loading spinner，结果用户点开订单页，发现用户头像还在转圈，但订单数据早已就位。
实操建议：
- 按模块维护独立 loading 状态，比如
userLoading、ordersLoading、notificationsLoading - 如果真要聚合出一个「整体加载中」指示器（比如顶部进度条），用
some([userLoading, ordersLoading, notificationsLoading])计算，而不是反向推导 - 服务端接口若支持批量查询（如
/api/batch?resources=user,orders,notifications），优先走单请求 + 后端聚合，省去前端并发协调的复杂度
真正难的不是怎么写 Promise.all，而是想清楚「哪些数据必须一起到，哪些可以错峰更新，哪些失败了可以静默降级」——状态设计比语法细节重要得多。
