Promise.any的实用场景解析

Promise.any是JavaScript中处理并发异步操作的利器，尤其适用于需要从多个来源获取数据，只要一个成功即可的场景。它会并行执行多个Promise，并返回第一个成功Promise的结果，若全部失败，则会抛出一个包含所有错误信息的AggregateError。本文深入解析了Promise.any的应用场景，包括从多个CDN加载资源、多渠道认证登录、资源回退机制等，展示了它如何提升系统韧性和用户体验。与Promise.race不同，Promise.any不会因首个Promise失败而终止，而是坚持到有成功结果为止。通过示例代码，本文还演示了如何捕获和处理AggregateError，以便集中查看失败原因，方便问题排查，助力开发者构建更健壮、更可靠的Web应用。

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。

这个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的价值远不止于技术实现上的优雅，它能直接转化成用户能感知到的“顺畅”和“可靠”。

1. 冗余数据源与内容加载： 这是最典型的应用场景。比如，你的网站图片托管在多个CDN上，或者视频有多个备用流。使用Promise.any可以同时向这些源发起请求，哪个先成功就用哪个。这不仅能加速内容加载（因为总能拿到最快的那个），还能大大提升系统的容错能力。即使某个CDN暂时性故障，用户也能从其他正常的CDN获取到内容，避免了白屏或加载失败的尴尬。对于用户来说，感知到的就是“这个网站加载真快，而且从没出过错”。

2. 多渠道认证或登录： 设想一个系统支持多种登录方式：邮箱/密码、OAuth（Google/GitHub）、短信验证码。用户点击登录后，可能系统会同时尝试一些后台的认证逻辑（比如检查token有效性），或者提供多种认证入口。Promise.any可以用于内部逻辑：如果用户同时尝试多种登录方式（虽然前端不常见），或者后台需要验证多个身份凭证，只要其中一个验证成功即可。这提升了认证的灵活性和成功率。

3. 资源回退机制： 比如，你尝试加载一个大型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提供了一种“多管齐下，择优而取”的策略。它让我们的异步代码在面对不确定性和潜在故障时，能够表现得更加智能和有弹性，最终提升了产品的用户体验和整体系统的可靠性。

终于介绍完啦！小伙伴们，这篇关于《Promise.any的实用场景解析》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布文章相关知识，快来关注吧！