一、參數定位：回調函數的角色與邊界

<i id='y14rq'></i>

.then() 接收的兩個參數本質上是狀態處理器，分別對應 Promise 的兩種終結狀態。它們的定位需從三個層面理解：

1.1 狀態專屬處理器

onFulfilled 僅在 Promise 成功（fulfilled）時觸發，接收成功值作為參數；onRejected 僅在失敗（rejected）時觸發，接收失敗原因。這種嚴格的狀態隔離避免了條件判斷的冗余，但要求開發者明確區分業務邏輯的成功與失敗路徑。

1.2 異步執行的契約

無論 Promise 何時完成，兩個回調始終通過微任務隊列異步執行。即使對已完成的 Promise 追加 .then()，其回調也會延遲到當前同步代碼結束后觸發。這種設計保證了主流程的連貫性，卻也容易引發對執行時序的誤解。

1.3 鏈式調用的樞紐

每個 .then() 返回新 Promise，其狀態由回調的返回值決定：

• 返回普通值：生成成功狀態的 Promise
• 拋出異常或返回拒絕值：生成失敗狀態的 Promise
• 返回 Promise 對象：等待其完成并透傳狀態

這種隱式轉換機制使鏈式調用能夠無縫銜接同步與異步操作，但要求開發者精準控制返回值類型。

二、執行邏輯：狀態變更后的觸發規則

回調函數的執行遵循嚴格的時序與狀態規則，其核心邏輯可分解為三個階段：

2.1 狀態鎖定與隊列管理

當 Promise 狀態從 pending 變更后，所有關聯的回調會被加入微任務隊列。此時即使再次修改狀態（理論上不可行，因狀態不可逆），新回調也會等待下一次狀態變更。這種機制確保了回調總能獲取最終狀態。

2.2 微任務與事件循環的交互

回調的執行優先級高于宏任務（如定時器），但低于當前同步代碼。在事件循環中，微任務會在每個宏任務階段結束后集中處理，直到隊列清空。這種特性使得多個快速完成的 Promise 回調能夠按順序執行，而非并發處理。

2.3 延遲調用的實際影響

考慮以下場景：一個已完成的 Promise 立即調用 .then()，其回調仍會延遲執行。例如，在用戶交互事件中追加異步處理，需注意回調可能無法立即響應業務需求。此時可通過顯式同步標記或狀態管理來協調時序。

三、數據流控制：值與原因的傳遞機制

回調函數的參數傳遞是 Promise 鏈的核心功能，其規則決定了數據如何在異步流程中流動：

3.1 成功值的傳遞鏈

onFulfilled 接收的成功值會沿鏈向下傳遞，傳遞規則包括：

• 直接透傳：若回調無返回值，下一個 onFulfilled 會接收當前成功值
• 值轉換：若回調返回新值，下一個 onFulfilled 會接收轉換后的值
• Promise 解包：若回調返回 Promise，會等待其完成并透傳最終值

這種機制使得數據能夠在異步流程中逐步加工，而無需顯式管理中間狀態。

3.2 失敗原因的捕獲與轉換

onRejected 接收的失敗原因可通過三種方式影響后續流程：

• 靜默吸收：若回調無返回值或返回普通值，錯誤會被視為已處理，后續鏈接收成功狀態
• 錯誤轉換：若回調返回成功值或 Promise，可將錯誤狀態轉為成功狀態
• 錯誤透傳：若回調拋出異常或返回拒絕值，錯誤會繼續向下傳遞

這種靈活性允許開發者根據業務需求選擇錯誤處理策略，但也易因疏忽導致錯誤被忽略。

3.3 隱式狀態轉換的陷阱

回調的返回值類型會隱式決定后續 Promise 的狀態。例如：

• 返回 null 或 undefined 會生成成功狀態的 Promise
• 拋出字符串錯誤會生成拒絕狀態的 Promise
• 返回已拒絕的 Promise 會透傳拒絕狀態

若未明確理解這些規則，可能導致鏈式調用意外中斷或狀態錯誤。

四、典型錯誤模式與修正方案

4.1 錯誤處理鏈斷裂

問題表現：鏈中某環節的錯誤未被捕獲，導致后續邏輯靜默失敗。
根本原因：省略了 onRejected 或未使用 .catch()。
修正策略：

• 在鏈末尾顯式添加 .catch()
• 在每個 .then() 中同時提供 onRejected
• 使用混合模式：部分環節用 .then() 的 onRejected，末尾用 .catch()

4.2 異步時序誤解

問題表現：在同步代碼中依賴異步回調的即時性，導致數據不一致。
根本原因：忽視微任務隊列的延遲執行特性。
修正策略：

• 避免在同步代碼中直接讀取異步回調的修改
• 通過額外狀態標記或事件通知協調時序
• 使用 async/await 語法簡化時序控制

4.3 返回值類型混淆

問題表現：意外返回 Promise 導致流程中斷，或返回普通值導致錯誤被忽略。
根本原因：未明確區分同步返回值與異步返回值。
修正策略：

• 在需要等待異步結果的環節返回 Promise
• 在錯誤處理環節確保返回非拒絕值以終止錯誤傳遞
• 使用類型檢查工具驗證返回值類型

五、高級應用模式

5.1 條件分支實現

通過 onFulfilled 和 onRejected 的返回值，可構建復雜的條件邏輯。例如，根據數據有效性決定后續流程：

• 成功時返回加工后的數據
• 失敗時返回默認值或觸發恢復機制

5.2 并行操作協調

結合集合方法（如 Promise.all()）時，可通過 onRejected 處理部分失敗：

• 統一捕獲所有操作的錯誤
• 根據部分成功結果調整業務邏輯
• 實現“部分成功”場景的降級處理

5.3 資源生命周期管理

在 onRejected 中實現資源釋放邏輯，確保異常情況下資源不被泄漏。例如：

• 數據庫連接在操作失敗時關閉
• 文件句柄在寫入失敗時釋放
• 網絡請求在超時時終止

六、與其他方法的協同

6.1 與 .catch() 的互補關系

.catch(onRejected) 是 .then(null, onRejected) 的語法糖，但更推薦使用 .catch() 以避免以下問題：

• 嵌套 .then() 時，第二個 onRejected 無法捕獲第一個 onFulfilled 的錯誤
• 鏈式調用中，.catch() 可集中處理多個環節的錯誤

6.2 與 .finally() 的配合

.finally() 適用于無論成功或失敗均需執行的邏輯（如日志記錄、狀態重置）。其回調不接收參數，且需返回可等待對象以避免中斷流程。

6.3 與 async/await 的互操作

在 async 函數中，.then() 的鏈式邏輯可轉化為 try/catch 塊。兩種風格的對比：

• Promise 鏈：適合線性異步流程，顯式表達數據流
• async/await：適合復雜邏輯，通過同步語法簡化異步控制

實際開發中，可根據場景選擇或混合使用兩種風格。

七、總結與關鍵實踐

1. 明確參數角色：onFulfilled 處理成功路徑，onRejected 處理失敗路徑，避免混用邏輯。
2. 控制數據流：通過返回值類型精確決定后續狀態，防止意外狀態轉換。
3. 完善錯誤處理：采用結構化錯誤處理，確保錯誤不被靜默忽略。
4. 協調執行時序：理解微任務隊列的延遲特性，避免同步代碼依賴異步結果。
5. 選擇協同模式：根據場景靈活組合 .then()、.catch()、.finally() 和 async/await。

掌握這些核心機制后，開發者能夠構建出既健壯又靈活的異步流程，有效應對復雜業務場景的需求。在實際項目中，建議通過流程圖或狀態機模型輔助設計 Promise 鏈，以直觀驗證數據流與錯誤處理邏輯。