為什麼你的店鋪必須有一層「履約抽象」

症狀：換一次供應商，改一半程式碼

大部分自動發貨站的寫法是：在下單函式裡直接 fetch 某家的介面，把回傳值拼到自己頁面上。問題很快就暴露——

• 商品文案、庫存口徑、結算順序混在一起，改一處動全身。
• 上游回傳結構一變，頁面跟著崩。
• 想同時接兩家做比價？只能在 if/else 裡堆屎山。

正確的切法：五件事

不論上游長什麼樣，它對你的系統只需要提供五種能力：

1. 拉目錄：有哪些貨、什麼價、還有沒有。
2. 查庫存：下單前確認。
3. 下單：帶冪等鍵。
4. 查單：非同步結果的兜底。
5. 回調：非同步結果的主路徑。

把這五件事抽象成介面，剩下的差異（路徑、欄位名、簽章演算法、缺貨怎麼表達）全部降級成設定項。

收益

• 新增供應商 = 新增一份環境變數，業務程式碼零改動。
• 上游掛了，可以退化到快取目錄，頁面不白屏。
• 可以在多個供應商之間做路由：誰便宜、誰有貨、誰回應快，就發給誰。