promise.any在面对多个异步操作时，只关注第一个成功的结果，只要有一个promise成功，就会立即返回该结果；若全部失败，则会收集所有错误并抛出一个包含errors数组的aggregateerror。1. 它适用于冗余数据源、内容加载等场景，例如从多个cdn获取资源，哪个快就用哪个；2. 在多渠道认证中，后台可尝试多种登录方式，只要一个成功即可通过；3. 资源回退机制中，如加载js库时主cdn失败可尝试备用cdn或本地缓存；4. 与promise.race不同，它不会因首个promise失败而终止，而是坚持到有成功结果为止，提升了系统韧性；5. 当所有promise失败时，通过aggregateerror.errors可集中查看所有失败原因，便于日志记录和问题排查。
Promise.any这个API，说白了，就是当你有好几个异步操作并行执行时，你只关心其中任意一个能成功完成就行。它会等待并返回第一个成功解决的Promise的结果，而如果所有的Promise都失败了，它才会告诉你一个聚合的错误。这和我们平时处理多个选项，只取最优或最快成功的那一个场景非常契合。
当我第一次接触到Promise.any时，其实脑子里立马就浮现出一些很实际的场景。比如，你可能正在尝试从好几个不同的CDN节点或者备用API接口去拉取同一份数据。正常情况下，我们当然希望越快越好，但更重要的是，它得是成功的。如果第一个尝试的接口挂了，或者响应慢得离谱，我们肯定希望系统能自动去尝试第二个、第三个，直到有一个能顺利返回结果。Promise.any正是为此而生。
它的核心逻辑在于“求同存异”——它只在乎“成功”这个共同点，只要有一个成功了，它就满足了。至于其他的Promise是成功了但慢了，还是直接失败了，Promise.any都不再关心。但如果真的不幸，你提供的所有Promise都“阵亡”了，那么Promise.any会抛出一个AggregateError。这个错误类型很特别，它里面会包含一个数组，记录了所有Promise失败的原因。这对于我们排查问题，或者给用户更具体的失败提示，简直是太有用了。
和Promise.race比起来，Promise.race是“谁先到谁赢”，不管你是成功还是失败。如果第一个Promise是个快速失败的，Promise.race立马就失败了。但Promise.any则更有韧性，它会坚持到找到第一个成功者，或者所有人都失败了才放弃。这种差异，决定了它们各自的适用领域。Promise.all就更不用说了，那是要求“全员成功”才算成功，否则只要有一个失败，它就失败了。所以，Promise.any填补了一个非常重要的空白：即“只要有一个行就行”的需求。
为什么在追求鲁棒性时，Promise.any比Promise.race更胜一筹？
在我看来，选择Promise.any而非Promise.race，很大程度上是出于对系统“韧性”的考量。想象一下，你正在尝试从三个不同的服务A、B、C中获取用户头像。服务A可能因为网络波动突然响应超时了，但服务B和C其实是健康的。
如果这时候你用的是Promise.race([fetch(A), fetch(B), fetch(C)])，一旦服务A的请求超时并导致Promise被拒绝（rejection），那么整个Promise.race就会立即以服务A的拒绝原因而失败。用户可能就看不到头像了，或者看到一个错误提示，尽管服务B和C本来是可以提供头像的。
但如果你用的是Promise.any([fetch(A), fetch(B), fetch(C)])，情况就大不一样了。即使服务A超时失败了，Promise.any并不会立即宣告失败。它会继续等待服务B或服务C的结果。只要B或C中有一个成功返回了头像，Promise.any就会以那个成功的结果解决。这就像是你有多个备选方案，只要其中一个能跑通，你的任务就算成功了。这种特性在面对不确定性高、需要多路冗余或回退机制的场景下，简直是救命稻草。它确保了只要有一条路能走通，我们就不会轻易放弃。
当所有Promise都失败时，Promise.any如何处理错误？
这是一个非常有意思且实用的点。不像Promise.all那样，只要一个Promise失败就立即失败，Promise.any只有在所有输入的Promise都失败了之后，才会抛出错误。而且，它抛出的不是一个简单的错误，而是一个AggregateError。
likeshop单商户开源商城系统，公众号商城、H5商城、小程序商城、安卓APP商城、苹果APP商城代码全开源，免费商用。适用场景：B2C商城，新零售商城，社交电商商城，分销系统商城，分销电商商城，小程序商城，商城源码，商城系统，单商户，多商户，电商系统，直播，uniapp，uni-app，B2B2C，B2B，O2O，ERP，Wechat，交易系统，内容系统，雷达，crm。
这个AggregateError对象，它有一个非常关键的属性：errors。这个errors属性是一个数组，里面包含了所有导致Promise.any最终失败的那些Promise的拒绝原因。举个例子，如果你的三个API请求都失败了，一个是因为网络错误，一个是因为服务器500，另一个是因为数据格式不匹配，那么AggregateError.errors数组里就会包含这三个具体的错误对象。
async function tryMultipleFetches() {
const urls = [
'https://api.example.com/fail1', // 假设这个会404
'https://api.example.com/fail2', // 假设这个会500
'https://api.example.com/fail3' // 假设这个会网络错误
];
const promises = urls.map(url =>
fetch(url).then(res => {
if (!res.ok) {
throw new Error(`HTTP error! Status: ${res.status} for ${url}`);
}
return res.json();
}).catch(error => {
console.error(`Fetch failed for ${url}:`, error.message);
throw new Error(`Failed to fetch ${url}: ${error.message}`); // 重新抛出更具体的错误
})
);
try {
const result = await Promise.any(promises);
console.log("Success:", result);
} catch (error) {
if (error instanceof AggregateError) {
console.error("All promises failed!");
error.errors.forEach((err, index) => {
console.error(`Error ${index + 1}:`, err.message);
});
} else {
console.error("Unexpected error:", error);
}
}
}
// tryMultipleFetches();这段代码片段展示了如何捕获并处理AggregateError。通过遍历error.errors，我们就能清晰地知道每一个尝试失败的具体原因。这对于我们做日志记录、用户反馈或者后续的错误处理逻辑都非常重要。它提供了一种集中管理和分析多重失败的机制，而不是简单地抛出一个模糊的“Something went wrong”。
Promise.any在哪些场景下能显著提升用户体验或系统可靠性？
我觉得，Promise.any的价值远不止于技术实现上的优雅，它能直接转化成用户能感知到的“顺畅”和“可靠”。
冗余数据源与内容加载： 这是最典型的应用场景。比如，你的网站图片托管在多个CDN上，或者视频有多个备用流。使用
Promise.any可以同时向这些源发起请求，哪个先成功就用哪个。这不仅能加速内容加载（因为总能拿到最快的那个），还能大大提升系统的容错能力。即使某个CDN暂时性故障，用户也能从其他正常的CDN获取到内容，避免了白屏或加载失败的尴尬。对于用户来说，感知到的就是“这个网站加载真快，而且从没出过错”。多渠道认证或登录： 设想一个系统支持多种登录方式：邮箱/密码、OAuth（Google/GitHub）、短信验证码。用户点击登录后，可能系统会同时尝试一些后台的认证逻辑（比如检查token有效性），或者提供多种认证入口。
Promise.any可以用于内部逻辑：如果用户同时尝试多种登录方式（虽然前端不常见），或者后台需要验证多个身份凭证，只要其中一个验证成功即可。这提升了认证的灵活性和成功率。-
资源回退机制： 比如，你尝试加载一个大型JavaScript库。你可以先尝试从主CDN加载，如果失败了，再尝试从备用CDN，最后甚至可以尝试从你自己的服务器加载一个本地缓存版本。这构成了一个非常健壮的加载链。
async function loadScriptSafely(urls) { const scriptPromises = urls.map(url => new Promise((resolve, reject) => { const script = document.createElement('script'); script.src = url; script.onload = () => resolve(url); // 成功加载就resolve url script.onerror = () => reject(new Error(`Failed to load script from ${url}`)); document.head.appendChild(script); }) ); try { const loadedUrl = await Promise.any(scriptPromises); console.log(`Script loaded successfully from: ${loadedUrl}`); // 可以在这里执行脚本加载后的初始化逻辑 } catch (error) { if (error instanceof AggregateError) { console.error("All script loading attempts failed:", error.errors.map(e => e.message)); } else { console.error("Unexpected error during script loading:", error); } // 提供用户友好的错误提示或回退方案 } } // loadScriptSafely([ // 'https://cdn.jsdelivr.net/npm/some-lib@1.0.0/dist/some-lib.min.js', // 'https://unpkg.com/some-lib@1.0.0/dist/some-lib.min.js', // '/local-cache/some-lib.min.js' // ]);这段代码虽然只是一个简化示例，但它展示了如何用
Promise.any实现一个多路加载的策略，从而在各种网络环境下都能尽可能地保证资源可用性。
总的来说，Promise.any提供了一种“多管齐下，择优而取”的策略。它让我们的异步代码在面对不确定性和潜在故障时，能够表现得更加智能和有弹性，最终提升了产品的用户体验和整体系统的可靠性。
