应使用 Promise.allSettled 替代 Promise.all，因其返回每个请求的 status、value 或 reason，便于分类错误、定位问题、按需响应；需主动提取错误上下文、区分错误类型、触发业务动作，并兜底监听 unhandledrejection。
在多路并发请求中，不希望一个失败就中断全部，同时又要明确知道哪些出错了、为什么错——关键不是“阻止报错”，而是“让失败可观察、可归类、可响应”。
用 Promise.allSettled 替代 Promise.all
Promise.all 一旦有任意一个 Promise rejected，整个结果就失败，你拿不到其余成功的数据；而 Promise.allSettled 会等所有 Promise 结束（无论 fulfilled 或 rejected），返回统一结构的数组，每个项都带 status 和 value/reason。
- status 为 "fulfilled" 时，reason 字段不存在，value 是正常结果
- status 为 "rejected" 时，value 字段不存在，reason 是拒绝原因（通常是 Error 实例）
- 结果顺序严格对应输入任务顺序，方便按索引定位问题请求
提取并分类错误信息
拿到 allSettled 的结果后，主动筛选 rejected 项，提取有用上下文：错误类型、消息、堆栈、甚至关联的请求 URL（建议把任务函数封装成带元信息的对象）。
- 避免只打印 reason.toString() —— 可能丢失堆栈和属性
- 检查 reason 是否为 Error 实例，再读取 name、message、stack
- 对非 Error 拒绝（如 Promise.reject('timeout')），可统一包装为 CustomError 方便后续处理
按需做业务级响应
收集错误不是终点，而是为了触发合适动作：比如重试特定失败项、降级展示默认数据、上报监控系统、或向用户提示部分加载失败。
立即学习“Java免费学习笔记（深入）”；
- 不要把所有失败一视同仁：网络超时可自动重试，401 错误应跳转登录，500 则需提示稍后重试
- 若需重试，建议单独构造新 Promise 数组，避免污染原始结果逻辑
- 上报错误时带上任务标识（如 'user-fetch'、'profile-load'），便于聚合分析
兜底监听 unhandledrejection 防遗漏
即使用了 allSettled，仍可能有未 await 的 Promise 或漏处理的链式 .then 中抛错。全局监听可捕获这些“逃逸”错误，仅作日志上报，不用于业务逻辑。
- 监听 window.addEventListener('unhandledrejection', e => { report(e.reason) })
- 注意过滤跨域脚本错误（e.reason 可能为 null 或非 Error）
- 不在此处 throw 或 reject，否则可能触发二次事件
