在當(dāng)今的支付業(yè)務(wù)領(lǐng)域，其涉及的環(huán)節(jié)繁多，涵蓋了創(chuàng)建訂單、發(fā)起支付、等待第三方回調(diào)、退款以及關(guān)閉等多個關(guān)鍵步驟。

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

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

圖片

一、為何支付系統(tǒng)需要狀態(tài)機

1. 業(yè)務(wù)復(fù)雜度的應(yīng)對

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

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

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

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

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

3. 有序處理異常場景

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

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

綜上所述，對于中大型支付系統(tǒng)而言，狀態(tài)機幾乎是不可或缺的設(shè)計工具，它能夠幫助系統(tǒng)更好地應(yīng)對復(fù)雜的業(yè)務(wù)場景，提高系統(tǒng)的穩(wěn)定性和可維護性。

二、常見支付狀態(tài)的解析

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

1. CREATED（已創(chuàng)建）

當(dāng)訂單在支付中心成功生成，但尚未正式發(fā)起支付時，訂單處于此狀態(tài)。這是訂單生命周期的起始階段，標(biāo)志著訂單的初步創(chuàng)建。

2. PENDING（待支付）

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

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

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

4. SUCCESS（支付成功）

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

5. FAIL（支付失?。?/h3>

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

6. REFUNDING（退款中）

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

7. REFUNDED（退款成功）

當(dāng)?shù)谌酱_認(rèn)退款成功后，訂單進入退款成功狀態(tài)。如果是部分退款的情況，需要在訂單或退款表中詳細(xì)記錄已退金額和剩余可退金額，以便進行后續(xù)的管理和查詢。

8. CLOSED（已關(guān)閉 / 已取消）

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

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

三、典型狀態(tài)流轉(zhuǎn)示例詳解

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

圖片

以上示例僅為通用情況，實際業(yè)務(wù)中可能會根據(jù)部分退款、多次退款、多渠道回調(diào)等復(fù)雜情況進行更加精細(xì)的設(shè)計。

四、狀態(tài)變更記錄表的設(shè)計要點

4.1 為何需要單獨的記錄表

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

4.2 表結(jié)構(gòu)示例

常見的狀態(tài)變更記錄表（也可稱為 payment_status_history 或 payment_order_history 等）可以按照以下結(jié)構(gòu)進行設(shè)計：

圖片

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

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

五、項目中狀態(tài)機的落地方式

5.1 手寫狀態(tài)機

在大多數(shù)項目中，手動編寫狀態(tài)機映射或狀態(tài)流轉(zhuǎn)表是一種常見的做法。以下是具體的實現(xiàn)步驟：

首先，定義支付狀態(tài)和支付事件的枚舉類：

圖片

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

1. 查詢訂單的當(dāng)前狀態(tài)。
2. 判斷是否允許觸發(fā)對應(yīng)的事件。
3. 如果允許，則將訂單狀態(tài)更新為目標(biāo)狀態(tài)。
4. 插入一條狀態(tài)變更記錄到 payment_status_history 表中。

以下是一個示例代碼：

圖片

5.2 使用 Spring StateMachine

Spring 提供了 Spring Statemachine 庫，該庫可以更加系統(tǒng)化地管理復(fù)雜的狀態(tài)、事件和轉(zhuǎn)移。

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

然而，如果團隊對該框架不太熟悉，且業(yè)務(wù)需求不算特別復(fù)雜，手寫狀態(tài)機往往已經(jīng)能夠滿足需求。

關(guān)于Spring StateMachine 可以看陳某之前的文章：項目終于用上了Spring狀態(tài)機，非常優(yōu)雅！

六、關(guān)鍵關(guān)注點解析

1. 冪等性的保障

支付回調(diào)可能會多次觸發(fā)，為了確保系統(tǒng)的穩(wěn)定性和數(shù)據(jù)的準(zhǔn)確性，需要保證重復(fù)回調(diào)不會導(dǎo)致重復(fù)更新或錯誤更新?？梢栽跀?shù)據(jù)庫層面進行冪等校驗，例如，如果訂單狀態(tài)已經(jīng)是 SUCCESS，再次收到成功回調(diào)時可以直接忽略該請求。

2. 異常場景的處理

• 第三方回調(diào)丟失：當(dāng)?shù)谌交卣{(diào)信息丟失時，訂單可能會一直停留在 PENDING 狀態(tài)。為了解決這個問題，需要定期主動查詢第三方支付結(jié)果，確保訂單狀態(tài)能夠及時更新。
• 超時關(guān)閉：如果用戶長時間未支付，訂單可以自動從 CREATED 或 PENDING 狀態(tài)轉(zhuǎn)為 CLOSED 狀態(tài)，以釋放系統(tǒng)資源，避免無效訂單的占用。
• 退款失?。喝舻谌酵丝钍。唵涡枰氐?nbsp;SUCCESS 狀態(tài)，并且可以再次發(fā)起退款請求，確保用戶的退款需求能夠得到妥善處理。

3. 部分退款的處理

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

4.數(shù)據(jù)一致性

通常使用數(shù)據(jù)庫事務(wù)保證訂單表與狀態(tài)變更表的同步更新；

大規(guī)模系統(tǒng)可采用消息隊列或分布式事務(wù)方案。

5.對賬與統(tǒng)計

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

七、總結(jié)

1.狀態(tài)機設(shè)計：

列出核心狀態(tài)（CREATED、PENDING、SUCCESS、FAIL、REFUNDING、REFUNDED、CLOSED 等）和對應(yīng)事件；

明確當(dāng)前狀態(tài) + 事件 -> 下一個狀態(tài)的規(guī)則，保證每次狀態(tài)變更都有明確觸發(fā)。

2.狀態(tài)變更記錄表：

建議使用多條記錄的方式保存狀態(tài)流轉(zhuǎn)歷史，每次變更都插入一條；

表中至少包含訂單標(biāo)識、原狀態(tài)、新狀態(tài)、觸發(fā)事件、操作人、時間、備注等核心字段；

方便后續(xù)審計、問題排查與統(tǒng)計分析。

3.關(guān)鍵落地點：

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

考慮部分退款、多次退款等業(yè)務(wù)需求；

根據(jù)團隊熟悉程度，選擇手寫狀態(tài)機或Spring StateMachine；

在大規(guī)?；蚝弦?guī)要求高的場景中，要特別重視審計和數(shù)據(jù)一致性。

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