Promise.all 返回的新 Promise 状态由传入的 Promise 终态共同决定：任一 reject 则立即 rejected，全部 resolve 才以结果数组 fulfilled；其执行不依赖微任务队列清空，而是监听各子 Promise 状态变化并用计数器机制协调。

Promise.all 会把所有传入的 Promise 实例注册为微任务，但它的执行逻辑并不只是“等所有微任务跑完”，而是依赖每个 Promise 的状态变化来推进自身状态——只有全部 resolve 才触发 then，任一 reject 就立即 reject。

Promise.all 的状态由内部 Promise 决定

Promise.all 返回的是一个新 Promise，它的状态不是由微任务队列顺序决定的，而是由传入的各个 Promise 的终态（fulfilled 或 rejected）共同决定：

• 只要有一个传入的 Promise reject，Promise.all 返回的 Promise 就立刻进入 rejected 状态，不会等待其他 Promise 完成
• 所有传入的 Promise 都必须 resolve，Promise.all 才会以包含所有结果的数组 fulfilled
• 即使某个 Promise resolve 很晚，只要没 reject，它仍会被等，但不会阻塞其他 Promise 的 resolve 通知

微任务队列中 Promise.all 的回调执行时机

Promise.all 本身不直接向微任务队列添加任务；它只是监听传入 Promise 的状态变化。当某个子 Promise resolve 或 reject 时，会把对应的处理逻辑（比如收集结果或抛出错误）作为微任务推入队列：

• 多个子 Promise 可能几乎同时 resolve，它们各自的 then 回调会按注册顺序排入微任务队列
• Promise.all 内部使用类似“计数器 + 结果数组”的机制：每完成一个 resolve，就存结果、减计数；计数归零才 resolve 自身
• reject 发生时，Promise.all 不等计数，直接 reject，并清空未完成的监听（但已进入微任务队列的回调仍会执行）

常见误区：Promise.all 不是“并发控制”，也不保证执行顺序

Promise.all 启动所有异步操作是并发的（不是串行），但结果数组的顺序严格对应输入 Promise 的顺序，与实际完成时间无关：

• 错误理解：“先发起的 Promise 一定先 resolve” → 实际取决于异步操作耗时，比如 fetch 慢、定时器快，结果顺序仍按输入位置排列
• 错误理解：“Promise.all 等待所有微任务执行完才结束” → 它只关心 Promise 状态，和微任务队列是否清空无关
• 若需限制并发数量（如同时最多 3 个请求），需配合 map + pool 模式或第三方库如 p-limit

调试建议：用 Promise.allSettled 替代容错场景

当部分失败可接受、需要获取全部结果（包括成功和失败信息）时，Promise.allSettled 更安全：

• 它总是返回 fulfilled 状态，结果是每个子 Promise 的 { status, value | reason } 对象数组
• 内部同样基于微任务响应状态变化，但不因单个 reject 而中断
• 适合日志上报、批量校验、非关键依赖并行处理等场景