在當今的支付業務領域，其涉及的環節繁多，涵蓋了創建訂單、發起支付、等待第三方回調、退款以及關閉等多個關鍵步驟。

由于環節復雜且異常場景層出不窮，如果僅僅依賴一個簡單的 status 字段來隨意更新訂單狀態，極易引發邏輯混亂、漏單現象，同時也會給后續的審計工作帶來極大的困難。

為了解決這些問題，眾多支付系統紛紛引入了狀態機（State Machine）這一強大工具，用于管理支付訂單在不同階段的狀態轉移。與此同時，配合使用狀態變更記錄表（也稱為歷史表）進行詳細記錄，為后續的審計和問題排查提供有力支持。

圖片

一、為何支付系統需要狀態機

1. 業務復雜度的應對

支付流程猶如一幅錯綜復雜的畫卷，從訂單創建伊始，到支付成功或失敗，再到可能的退款或關閉操作，其間存在著各種各樣的中間狀態和異常情況。

例如，用戶可能因為各種原因遲遲不進行付款操作；第三方回調信息可能由于網絡等因素丟失；部分退款的情況也時有發生。

這些復雜的業務場景使得簡單的狀態管理方式難以勝任，而狀態機的引入則為解決這些問題提供了有效的途徑。

2. 提升可維護性與可審計性

• 可維護性：狀態機能夠清晰地列出狀態與事件之間的對應關系，就像一張精確的地圖，為團隊成員指引方向。這避免了團隊成員隨意修改訂單狀態，減少了溝通成本和排查問題的時間。關注工眾號：碼猿技術專欄，回復關鍵詞：1111 獲取阿里內部Java性能調優手冊！團隊成員可以根據狀態機的規則，快速了解系統的運行邏輯，提高開發和維護的效率。
• 可審計性：支付業務涉及資金流動，受到嚴格的監管和合規要求。因此，對每一步狀態變更進行詳細的留痕記錄是必不可少的。狀態變更記錄表可以記錄下狀態變更的時間、原因、操作者等重要信息，為后續的審計工作提供了完整的證據鏈。

3. 有序處理異常場景

在支付過程中，異常場景時有發生，如第三方回調可能延遲或失敗；用戶可能在支付中途取消訂單；退款過程需要多次與第三方進行確認等。

狀態機的引入使得這些異常場景的處理更加有序，能夠確保系統內狀態的一致性。通過狀態機的規則，可以對不同的異常情況進行分類處理，避免系統出現混亂。

綜上所述，對于中大型支付系統而言，狀態機幾乎是不可或缺的設計工具，它能夠幫助系統更好地應對復雜的業務場景，提高系統的穩定性和可維護性。

二、常見支付狀態的解析

在實際的支付業務中，支付狀態的定義并非一成不變，而是需要根據具體的業務需求進行靈活調整。下面為大家呈現一個常見且相對完整的支付狀態集合，你可以根據自身業務的特點進行增減或合并。

1. CREATED（已創建）

當訂單在支付中心成功生成，但尚未正式發起支付時，訂單處于此狀態。這是訂單生命周期的起始階段，標志著訂單的初步創建。

2. PENDING（待支付）

一旦向第三方發起支付請求，或者生成了支付鏈接/二維碼供用戶進行支付操作，但尚未收到最終的支付結果時，訂單進入待支付狀態。此時，系統需要等待用戶完成支付或第三方返回支付結果。

3. PROCESSING（支付中 / 處理中）

部分支付渠道會返回「處理中」的狀態信息，這意味著第三方需要一定的時間來完成扣款確認操作。在某些業務場景中，可能會將「待支付」和「支付中」這兩個狀態合并為一個狀態，以簡化業務邏輯。

4. SUCCESS（支付成功）

當收到第三方支付成功的回調信息，或者主動查詢到支付成功的結果時，訂單正式完成支付，進入支付成功狀態。這是支付流程的一個重要里程碑，標志著交易的順利完成。

5. FAIL（支付失敗）

若第三方支付明確表示失敗，或者用戶超時未付款，訂單將進入支付失敗狀態。一旦進入此狀態，通常情況下訂單將無法再進行支付操作。

6. REFUNDING（退款中）

對于已經支付成功的訂單，當用戶或系統發起退款請求后，訂單進入退款中狀態，此時需要等待第三方的退款結果。在這個階段，系統需要與第三方進行溝通，確保退款操作的順利進行。

7. REFUNDED（退款成功）

當第三方確認退款成功后，訂單進入退款成功狀態。如果是部分退款的情況，需要在訂單或退款表中詳細記錄已退金額和剩余可退金額，以便進行后續的管理和查詢。

8. CLOSED（已關閉 / 已取消）

若訂單在支付成功之前被取消，例如用戶主動取消訂單或系統因超時自動關閉訂單，訂單將進入已關閉狀態。一旦訂單處于此狀態，將不可再進行支付或退款操作。

這些狀態基本涵蓋了常見的支付生命周期。你可以根據實際業務場景的需求，對狀態進行簡化或細化。例如，如果業務場景不需要「PROCESSING」或「REFUNDING」狀態，可以將其去除；若需要更加精細的退款流程，也可以進一步細化「部分退款」「多次退款」等狀態。

三、典型狀態流轉示例詳解

狀態機的核心機制在于通過當前狀態和觸發事件來確定下一個狀態。下面為大家展示一個簡化的示例，清晰地呈現了常見的事件觸發和狀態變化情況。

圖片

以上示例僅為通用情況，實際業務中可能會根據部分退款、多次退款、多渠道回調等復雜情況進行更加精細的設計。

四、狀態變更記錄表的設計要點

4.1 為何需要單獨的記錄表

• 審計與追溯：資金相關的業務對留痕要求極高，通過狀態變更記錄表，可以在事后詳細查看每一次狀態變化發生的時間、原因以及操作者等重要信息。關注工眾號：碼猿技術專欄，回復關鍵詞：1111 獲取阿里內部Java性能調優手冊！這為審計工作提供了有力的支持，確保業務操作的合規性。
• 問題排查：當用戶提出投訴或系統出現故障時，狀態變更記錄表可以幫助我們快速還原訂單的完整生命周期，定位問題的根源。通過查看狀態變更的歷史記錄，我們可以了解訂單在各個階段的狀態變化情況，找出可能存在的問題。
• 統計分析：基于狀態變更表，我們可以進行豐富的統計分析工作。例如，統計訂單在各狀態停留的時間分布，了解業務流程的效率；分析失敗率和退款率等指標，為業務優化提供數據支持。

4.2 表結構示例

常見的狀態變更記錄表（也可稱為 payment_status_history 或 payment_order_history 等）可以按照以下結構進行設計：

圖片

需要注意的是，一個訂單從創建到完成，可能會多次變更狀態，每次狀態變更都需要插入一條新的記錄，而不是只保留一條記錄。各字段的含義如下：

• order_id：用于區分該記錄屬于哪個訂單，確保記錄與訂單之間的關聯關系。
• from_status / to_status：記錄本次狀態變更的起點和終點，清晰展示狀態的變化過程。
• event：具體的事件名稱，如 PaymentSuccess 或 CloseOrder，明確觸發狀態變更的原因。
• operator：記錄是由誰或哪個系統觸發了本次變更，方便后續的責任追溯。
• remark：可以寫入失敗原因、第三方返回碼等輔助信息，為問題排查和分析提供更多的線索。
• create_time：記錄狀態變更的發生時間戳，便于進行時間維度的統計和分析。

五、項目中狀態機的落地方式

5.1 手寫狀態機

在大多數項目中，手動編寫狀態機映射或狀態流轉表是一種常見的做法。以下是具體的實現步驟：

首先，定義支付狀態和支付事件的枚舉類：

圖片

然后，在代碼中使用映射或 if-else / switch 邏輯來控制當前狀態和事件到下一個狀態的轉換規則。每次更新訂單狀態時，需要按照以下步驟進行操作：

1. 查詢訂單的當前狀態。
2. 判斷是否允許觸發對應的事件。
3. 如果允許，則將訂單狀態更新為目標狀態。
4. 插入一條狀態變更記錄到 payment_status_history 表中。

以下是一個示例代碼：

圖片

5.2 使用 Spring StateMachine

Spring 提供了 Spring Statemachine 庫，該庫可以更加系統化地管理復雜的狀態、事件和轉移。

它支持分層狀態機、并行狀態機等高級功能，還可以配置監聽器在狀態變更時自動將相關信息寫入數據庫。該庫適用于狀態過多、流程極其復雜或需要可視化管理的場景。

然而，如果團隊對該框架不太熟悉，且業務需求不算特別復雜，手寫狀態機往往已經能夠滿足需求。

關于Spring StateMachine 可以看陳某之前的文章：項目終于用上了Spring狀態機，非常優雅！

六、關鍵關注點解析

1. 冪等性的保障

支付回調可能會多次觸發，為了確保系統的穩定性和數據的準確性，需要保證重復回調不會導致重復更新或錯誤更新。可以在數據庫層面進行冪等校驗，例如，如果訂單狀態已經是 SUCCESS，再次收到成功回調時可以直接忽略該請求。

2. 異常場景的處理

• 第三方回調丟失：當第三方回調信息丟失時，訂單可能會一直停留在 PENDING 狀態。為了解決這個問題，需要定期主動查詢第三方支付結果，確保訂單狀態能夠及時更新。
• 超時關閉：如果用戶長時間未支付，訂單可以自動從 CREATED 或 PENDING 狀態轉為 CLOSED 狀態，以釋放系統資源，避免無效訂單的占用。
• 退款失敗：若第三方退款失敗，訂單需要回到 SUCCESS 狀態，并且可以再次發起退款請求，確保用戶的退款需求能夠得到妥善處理。

3. 部分退款的處理

如果業務允許部分退款，需要額外記錄已退金額和剩余可退金額等信息。同時，狀態機也需要支持部分退款成功、多次退款等更復雜的場景，以滿足業務的多樣化需求。通過合理設計狀態機和數據庫表結構，可以確保部分退款業務的順利進行。

4.數據一致性

通常使用數據庫事務保證訂單表與狀態變更表的同步更新；

大規模系統可采用消息隊列或分布式事務方案。

5.對賬與統計

完整的支付系統還需要對賬邏輯（對比第三方交易流水），并將狀態變更表的數據用于審計與統計分析。

七、總結

1.狀態機設計：

列出核心狀態（CREATED、PENDING、SUCCESS、FAIL、REFUNDING、REFUNDED、CLOSED 等）和對應事件；

明確當前狀態 + 事件 -> 下一個狀態的規則，保證每次狀態變更都有明確觸發。

2.狀態變更記錄表：

建議使用多條記錄的方式保存狀態流轉歷史，每次變更都插入一條；

表中至少包含訂單標識、原狀態、新狀態、觸發事件、操作人、時間、備注等核心字段；

方便后續審計、問題排查與統計分析。

3.關鍵落地點：

確保冪等與異常場景處理；

考慮部分退款、多次退款等業務需求；

根據團隊熟悉程度，選擇手寫狀態機或Spring StateMachine；

在大規模或合規要求高的場景中，要特別重視審計和數據一致性。

通過以上設計，一個支付系統就能夠在單體或微服務架構中實現對訂單全生命周期的有效管理，保持狀態清晰、有序，滿足合規與審計需求，并在異常場景下依舊具備較好的可維護性和可追溯性。