async/await 中的异常处理最佳实践是使用 try/catch 块包裹异步代码，确保捕获和处理可能抛出的错误，提升程序稳定性和可维护性。

async/await 中的异常处理核心机制是 try...catch，它能捕获 await 后的 Promise 被拒绝时抛出的错误，就像处理同步异常一样；2. 当 await 一个被拒绝的 Promise 时，JavaScript 运行时会将其表现为在当前行抛出同步错误，从而可以被 surrounding 的 try...catch 捕获；3. 常见模式包括细粒度捕获（在 async 函数内针对特定 await 操作捕获）和粗粒度捕获（在调用处捕获整个流程错误），以及“Go 风格”返回 [error, result] 元组的方式；4. 常见陷阱包括错误被吞噬（catch 中未处理或重新抛出）、忘记使用 await 导致错误无法被捕获，以及 Promise.all 的“快速失败”特性导致部分错误被忽略；5. 在大型应用中应通过全局错误监听（如 unhandledRejection）、自定义错误类、统一日志记录、错误监控平台集成和标准化 API 错误响应来实现统一的异常管理，确保错误不被遗漏并能及时响应，从而构建健壮的应用系统。

在 async/await 的世界里，异常处理的核心机制其实和同步代码没太大区别，那就是 try...catch。说白了，async/await 只是把基于 Promise 的异步操作，包装成了一种看起来像同步代码的写法，让 Promise 的拒绝（rejection）能被 try...catch 语句捕获，就像同步代码抛出错误一样。最佳实践在于理解何时何地捕获，以及如何优雅地向上层传播或处理这些错误。

解决方案

处理 async/await 中的异常，最直接有效的方式就是使用 try...catch 块。当一个 await 表达式等待的 Promise 被拒绝时，这个拒绝的值会被作为错误抛出，然后 try...catch 就能捕获到它。

async function fetchData() {
  try {
    // 假设这个函数可能会因为网络问题或服务器错误而抛出异常
    const response = await fetch('https://api.example.com/data');
    if (!response.ok) { // 检查HTTP状态码，非2xx通常视为错误
      // 明确抛出错误，让上层捕获
      throw new Error(`HTTP error! Status: ${response.status}`);
    }
    const data = await response.json();
    console.log('数据获取成功:', data);
    return data;
  } catch (error) {
    // 捕获fetch或json解析过程中可能发生的错误
    console.error('数据获取失败:', error.message);
    // 可以选择重新抛出错误，或者返回一个默认值/错误对象
    throw error; // 向上层传播错误
  } finally {
    // 无论成功或失败，都会执行的清理工作
    console.log('数据获取尝试结束。');
  }
}

// 调用示例
(async () => {
  try {
    const result = await fetchData();
    // 只有在fetchData成功时才执行
    console.log('最终结果:', result);
  } catch (e) {
    // 捕获fetchData内部未处理或重新抛出的错误
    console.error('顶层捕获到错误:', e.message);
  }
})();

这里的关键点是，你可以在 async 函数内部的任何 await 表达式周围放置 try...catch，也可以在调用 async 函数的地方放置 try...catch。这取决于你希望在哪个粒度上处理错误：是处理特定的异步操作错误，还是处理整个异步流程的错误。

async/await如何处理Promise的拒绝？

在我看来，async/await 最巧妙的地方，就是它如何将异步的 Promise 拒绝，转换成了我们熟悉的同步错误抛出机制。这背后其实是 JavaScript 运行时的一个约定：当你在 async 函数内部 await 一个 Promise，如果这个 Promise 最终状态是 rejected（被拒绝），那么 await 表达式就会“表现得”像在当前行抛出了一个同步错误。这样一来，你就不需要再写 .catch() 方法链，直接用 try...catch 就能搞定，极大简化了异步错误处理的逻辑。

举个例子，假设你有一个 Promise 会失败：

function unreliablePromise() {
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      reject(new Error('哎呀，出错了！'));
    }, 100);
  });
}

async function processData() {
  console.log('开始处理数据...');
  try {
    const data = await unreliablePromise(); // 这里的Promise会拒绝
    console.log('数据处理成功:', data); // 这行代码永远不会执行
  } catch (error) {
    console.error('捕获到错误:', error.message); // 错误在这里被捕获
  }
  console.log('处理结束。');
}

processData();
// 输出:
// 开始处理数据...
// 捕获到错误: 哎呀，出错了！
// 处理结束。

可以看到，unreliablePromise 拒绝后，await 就像抛出错误一样，直接跳到了 catch 块。如果 async 函数内部没有 try...catch 块来捕获这个错误，那么这个错误就会像普通同步错误一样，向上冒泡到调用栈的更高层，最终可能导致 Node.js 进程崩溃（在没有全局错误处理的情况下），或者在浏览器中成为一个未捕获的 Promise 拒绝。所以，理解这个错误传播机制，是正确使用 async/await 进行异常处理的基础。

处理async/await异常时有哪些常见的模式和陷阱？

在实际开发中，处理 async/await 异常时，我们确实会遇到一些模式和坑，有些是经验之谈，有些则是需要特别注意的细节。

常见的模式：

1. 细粒度捕获与粗粒度捕获结合：

   • 细粒度捕获：在 async 函数内部，对每个可能失败的 await 操作进行 try...catch。这适用于你需要对特定错误进行恢复性处理（比如重试、提供默认值）的情况。

     async function getUserProfile(userId) {
       try {
         const user = await db.findUser(userId);
         return user;
       } catch (dbError) {
         console.warn(`无法从数据库获取用户 ${userId} 的信息，尝试从缓存加载。`, dbError.message);
         // 尝试从缓存获取
         const cachedUser = await cache.get(userId);
         if (cachedUser) return cachedUser;
         throw new Error(`用户 ${userId} 不存在或无法访问。`); // 最终还是抛出错误
       }
     }

   • 粗粒度捕获：在调用 async 函数的地方，使用 try...catch 来捕获整个异步流程的错误。这通常用于向用户展示错误信息，或者进行全局的错误日志记录。

     async function main() {
       try {
         const profile = await getUserProfile('someId');
         console.log('用户资料:', profile);
       } catch (e) {
         console.error('处理用户资料时发生未知错误:', e.message);
         // 给用户显示一个友好的错误提示
         displayErrorMessage('加载用户资料失败，请稍后再试。');
       }
     }

2. “Go 风格”错误处理（返回 [error, result] 元组）： 这种模式在某些场景下非常有用，特别是当你不想中断执行流，而是想在每个异步操作后立即检查错误时。

   // 辅助函数
   function to(promise: Promise): Promise<[Error | null, T | undefined]> {
     return promise.then(data => [null, data]).catch(err => [err, undefined]);
   }
   
   async function processMultipleRequests() {
     const [err1, user] = await to(fetchUser());
     if (err1) {
       console.error('获取用户失败:', err1.message);
       return; // 或者进行其他错误处理
     }
   
     const [err2, posts] = await to(fetchPosts(user.id));
     if (err2) {
       console.error('获取帖子失败:', err2.message);
       return;
     }
   
     console.log('用户和帖子都获取成功:', user, posts);
   }

   这种模式让错误处理变得非常显式，避免了深层嵌套的 try...catch，但我个人觉得它有点“反模式”，因为它绕过了 async/await 旨在提供的同步错误处理的便利性。不过，在某些需要精细控制错误流程的场景下，它确实有其价值。

常见的陷阱：

1. “吞噬”错误（Swallowing Errors）： 这是最危险的陷阱之一。在 catch 块里捕获了错误，但是没有做任何处理（比如打印日志、向上抛出、返回错误状态），导致错误悄无声息地消失了。这会让你在调试时抓狂。

   async function doSomethingRisky() {
     try {
       await someFailingOperation();
     } catch (e) {
       // ❌ 错误被吞噬了，外部调用者永远不知道这里出错了
       // 什么都没做！
     }
   }

   最佳实践： 至少要记录日志，或者将错误重新抛出，或者返回一个明确的错误状态。

2. 忘记 await： 如果你调用了一个 async 函数但忘记了 await，那么这个 async 函数返回的 Promise 就会立即被执行，但它的拒绝不会被当前 try...catch 块捕获，因为它不是一个被 await 的操作。

   async function callWithoutAwait() {
     try {
       failingAsyncFunction(); // ❌ 忘记了 await
       console.log('这行代码可能会在错误发生前执行');
     } catch (e) {
       console.error('这个catch块捕获不到failingAsyncFunction的错误');
     }
   }
   // failingAsyncFunction 的错误会成为一个未处理的 Promise 拒绝

   最佳实践： 始终记得 await 你期望等待的 async 函数或 Promise。

3. Promise.all 的“快速失败”特性： 当你使用 Promise.all 并行执行多个异步操作时，只要其中一个 Promise 拒绝，Promise.all 就会立即拒绝，并且只返回第一个拒绝的错误。其他 Promise 即使成功或失败，它们的处理结果也不会被 Promise.all 返回。

   async function processAll() {
     const p1 = Promise.resolve(1);
     const p2 = Promise.reject(new Error('P2 failed'));
     const p3 = Promise.resolve(3);
   
     try {
       const results = await Promise.all([p1, p2, p3]); // P2会使Promise.all立即拒绝
       console.log(results);
     } catch (e) {
       console.error('Promise.all 捕获到错误:', e.message); // 只会捕获到 P2 的错误
     }
   }
   processAll();

   最佳实践： 如果你需要所有 Promise 都执行完毕，无论成功与否，然后统一处理结果和错误，应该使用 Promise.allSettled。它返回一个数组，每个元素都描述了对应 Promise 的最终状态（status: 'fulfilled' 或 status: 'rejected'）和结果/原因。

   async function processAllSettled() {
     const p1 = Promise.resolve(1);
     const p2 = Promise.reject(new Error('P2 failed'));
     const p3 = Promise.resolve(3);
   
     const results = await Promise.allSettled([p1, p2, p3]);
     results.forEach((result, index) => {
       if (result.status === 'fulfilled') {
         console.log(`Promise ${index + 1} 成功:`, result.value);
       } else {
         console.error(`Promise ${index + 1} 失败:`, result.reason.message);
       }
     });
   }
   processAllSettled();

这些模式和陷阱，说实话，即便经验丰富，也难免会犯错，关键在于如何快速发现并纠正。

如何在大型应用中统一管理async/await的异常？

在大型应用中，仅仅依靠散布在各处的 try...catch 是不够的。我们需要一个更系统、更统一的异常管理策略，确保所有错误都能被妥善处理、记录，并能及时发现。

1. 全局错误捕获机制：

   • Node.js 环境： 使用 process.on('unhandledRejection') 和 process.on('uncaughtException')。unhandledRejection 会捕获所有未被 catch 的 Promise 拒绝（包括 async/await 中未被 try...catch 捕获的错误），而 uncaughtException 捕获同步代码中未被捕获的错误。这就像一个兜底的网，防止应用崩溃。

     process.on('unhandledRejection', (reason, promise) => {
       console.error('未处理的 Promise 拒绝:', reason);
       // 记录日志，发送警报
       // ⚠️ 在生产环境中，通常会选择优雅地关闭进程
       // process.exit(1);
     });
     
     process.on('uncaughtException', (err) => {
       console.error('未捕获的同步异常:', err);
       // 记录日志，发送警报
       // ⚠️ 同样，生产环境中应考虑优雅关闭
       // process.exit(1);
     });

   • 浏览器环境： 使用 window.addEventListener('unhandledrejection') 和 window.addEventListener('error')。

     window.addEventListener('unhandledrejection', (event) => {
       console.error('未处理的 Promise 拒绝:', event.reason);
       // 上报错误到监控系统
     });
     
     window.addEventListener('error', (event) => {
       console.error('未捕获的同步错误:', event.error);
       // 上报错误到监控系统
     });

     这些全局监听器是最后的防线，它们能帮助你发现那些你代码中遗漏的 try...catch。

2. 自定义错误类： 创建自己的错误类，让错误信息更具语义化和可识别性。这比仅仅抛出 Error 实例要好得多。

   class DatabaseError extends Error {
     constructor(message: string, public code: number = 500) {
       super(message);
       this.name = 'DatabaseError';
     }
   }
   
   class AuthenticationError extends Error {
     constructor(message: string, public code: number = 401) {
       super(message);
       this.name = 'AuthenticationError';
     }
   }
   
   async function login(username, password) {
     const user = await db.findUser(username);
     if (!user) {
       throw new AuthenticationError('用户不存在。');
     }
     if (user.password !== password) {
       throw new AuthenticationError('密码错误。', 403);
     }
     return user;
   }
   
   // 在上层捕获时，可以根据错误类型进行更精细的处理
   try {
     await login('test', '123');
   } catch (e) {
     if (e instanceof AuthenticationError) {
       console.error(`认证失败: ${e.message} (Code: ${e.code})`);
     } else if (e instanceof DatabaseError) {
       console.error(`数据库操作失败: ${e.message}`);
     } else {
       console.error('未知错误:', e.message);
     }
   }

   自定义错误类让错误处理逻辑更清晰，也方便前端根据错误类型展示不同的提示。

3. 统一的日志记录： 无论错误在哪里被捕获，都应该通过一个统一的日志系统（如 Winston, Pino, Log4js 等）进行记录。日志应该包含足够的信息，如错误栈、发生时间、请求ID（如果有的话）、用户ID等，以便于调试和追溯。

   import logger from './utils/logger'; // 假设你有一个日志工具
   
   async function processRequest(req, res) {
     try {
       // ... 业务逻辑
     } catch (e) {
       logger.error(`处理请求 ${req.path} 时发生错误:`, e);
       res.status(500).send('服务器内部错误');
     }
   }

4. 错误监控与告警： 将错误日志集成到错误监控平台（如 Sentry, New Relic, Bugsnag, Datadog 等）。这些工具能聚合错误、去重、提供详细的错误上下文，并在错误率过高或出现严重错误时自动发送告警，帮助团队及时发现并解决问题。

5. API 错误响应标准化： 对于 Web API，确保所有错误响应都遵循统一的格式，例如包含 code、message、details 等字段，方便前端或其他客户端解析和处理。

这些实践能帮助你构建一个健壮的、易于维护的、对错误有高可见度的应用程序。错误处理不是一蹴而就的，它是一个持续优化和完善的过程。