async/await 是 ES7 中引入的語法糖，它徹底改變了 JavaScript 中異步編程的方式。它讓我們能夠以一種看似同步的方式編寫異步代碼，極大地提高了代碼的可讀性和可維護性。

然而，凡事皆有兩面。當我們享受 async/await 帶來的便利時，一個“老朋友”卻如影隨形，那就是 try...catch。

問題的根源：無處不在的 try...catch

為了捕獲 await 后面 Promise 的 reject 狀態，我們必須將代碼包裹在 try...catch 塊中。讓我們來看一個典型的例子，比如從服務器獲取用戶信息：

import { fetchUserById } from './api';

async function displayUser(userId) {
  try {
    const user = await fetchUserById(userId);
    console.log('用戶信息:', user.name);
    // ... 更多基于 user 的操作
  } catch (error) {
    console.error('獲取用戶失敗:', error);
    // ... 相應的錯誤處理邏輯，比如顯示一個提示
  }
}

這段代碼本身沒有問題，它能正常工作。但問題在于，如果你的業務邏輯稍微復雜一點，比如需要連續請求多個接口，代碼就會變成這樣：

async function loadPageData(userId) {
 try {
    const user = await fetchUserById(userId);
    console.log('用戶信息:', user.name);

    try {
      const posts = await fetchPostsByUserId(user.id);
      console.log('用戶文章:', posts);

      try {
        const comments = await fetchCommentsForPosts(posts[0].id);
        console.log('文章評論:', comments);
      } catch (commentError) {
        console.error('獲取評論失敗:', commentError);
      }
    } catch (postError) {
      console.error('獲取文章失敗:', postError);
    }
  } catch (userError) {
    console.error('獲取用戶失敗:', userError);
  }
}

看到這些層層嵌套的 try...catch，你是否感到了一絲窒息？這種寫法存在幾個明顯的問題：

• 代碼冗余：每個異步操作都需要重復的 try...catch 結構，增加了大量樣板代碼。
• 可讀性差：核心的“快樂路徑”（Happy Path）代碼被包裹在 try 塊中，增加了縮進層次，干擾了正常的閱讀流。
• 關注點混合：成功邏輯和失敗邏輯緊密地耦合在同一個代碼塊里，使得函數職責不夠單一。

那么，有沒有一種方法可以擺脫這種困境呢？答案是肯定的。

優雅的解決方案：Go 語言風格的錯誤處理

我們可以借鑒 Go 語言的錯誤處理模式。在 Go 中，函數通常會返回兩個值：result 和 error。調用者通過檢查 error 是否為 nil 來判斷操作是否成功。

我們可以將這種思想引入到 JavaScript 的 async/await 中。創建一個輔助函數（我們稱之為 to），它接收一個 Promise作為參數，并且永遠不會被 reject。相反，它總是 resolve 一個數組，格式為 [error, data]。

• 如果 Promise 成功 resolve，它返回 [null, data]。
• 如果 Promise 失敗 reject，它返回 [error, null]。

讓我們來實現這個 to 輔助函數。

如果你不使用 TypeScript，純 JavaScript 版本如下：

這個 to 函數非常小巧，但威力巨大。它將 try...catch 的邏輯封裝在了內部，向我們暴露了一個統一、扁平的接口。

實踐應用：重構我們的代碼

現在，讓我們用新的 to 函數來重構之前的 displayUser 函數：

看看發生了什么變化：

• 沒有 try...catch 了！ 整個函數體變得非常扁平。
• 錯誤優先處理：我們首先通過一個 if 語句檢查并處理錯誤（這被稱為“衛語句”或 Guard Clause），然后提前返回。
• 可讀性極高：處理完錯誤后，剩下的代碼都是成功路徑下的核心邏輯，一目了然，不再有任何嵌套。

現在，我們再來挑戰那個恐怖的嵌套地獄 loadPageData：

簡直是天壤之別！代碼變成了線性的、可預測的流程，每個步驟的錯誤處理都清晰獨立。

新模式的優勢總結

• 代碼更扁平、更清晰：消除了 try...catch 的嵌套，讓核心邏輯處于頂層作用域。
• 減少樣板代碼：將錯誤處理邏輯封裝在可復用的 to 函數中。
• 強制性的錯誤處理：解構賦值 const [error, data] 迫使開發者正視 error 的存在，不容易遺漏錯誤處理。
• 關注點分離：通過衛語句將錯誤處理邏輯與成功邏輯分離開，代碼更易于維護。

配合 Promise.all 使用

這個模式在處理多個并發請求時同樣表現出色。

async function loadDashboard(userId) {
 const [
    [userError, userData],
    [settingsError, settingsData]
  ] = await Promise.all([
    to(fetchUser(userId)),
    to(fetchUserSettings(userId))
  ]);

 if (userError) {
    console.error('加載用戶數據失敗');
    // 處理用戶錯誤
  }

 if (settingsError) {
    console.error('加載用戶設置失敗');
    // 處理設置錯誤
  }

 // 即使其中一個失敗，另一個成功的數據依然可用
 if (userData) {
    // ...
  }
 if (settingsData) {
    // ...
  }
}

使用 Promise.all 配合 to 函數，你可以優雅地處理多個 Promise 并發執行時部分成功、部分失敗的場景，而傳統的 try...catch 會在任何一個 Promise 失敗時直接進入 catch 塊，導致所有結果丟失。

try...catch 是 JavaScript 錯誤處理的基石，我們并非要完全消滅它。實際上，我們的 to 函數內部就使用了它。關鍵在于，我們應該將它抽象和封裝起來，而不是在業務代碼中一次又一次地手動編寫。