北京
Codename One這個版本里，Commerce是最容易被誤讀的功能。所以開頭必須把話說清楚：Commerce永遠不會替代應用內購買，也永遠不會。錢仍然走蘋果、谷歌或者你自己選的支付渠道。Codename One不碰資金流、不抽成、不經手任何一筆交易。
那它到底管什么？管的是購買之后那一堆讓人頭大的后臺雜活。第5300號PR做的事情，就是把這些基礎設施搭起來——收據驗證、權限校驗、訂閱生命周期、網絡鉤子、報表。但凡真正發布過訂閱功能的人都踩過這個坑：用戶買了SKU，不等于你現在就能放心給他開權限。
續費、寬限期、退款、扣款重試、套餐變更、試用、家庭共享、商店服務器通知——這些東西不會在你上線的第一天就全體亮相，它們是一個一個找上門來的。設備端看到的是一個狀態，商店后臺記錄的是另一個版本，而你的服務器往往需要維護第三個版本的真相。Commerce就是那個可選服務層，把這一團亂麻理成一條清晰的權限判斷線。
你的應用不需要記住每一個能解鎖“專業版”的SKU編號。它只需要問一個問題：這個用戶有沒有“專業版”權限？代碼寫出來就是幾行的事——通過CommerceManager實例設置好用戶ID，然后直接查權限狀態。購買動作仍然走現有的Purchase接口，該訂閱就調訂閱方法，該買斷就調購買方法，這部分完全沒變。
購買完成之后，或者應用每次啟動的時候，要在后臺線程里做一次刷新操作。刷新動作會在你的構建配置了密鑰且開啟了Commerce功能時，把當前的收據送到云端做驗證。如果是在本地構建或者模擬器環境里跑，它會安全地退回到常規的Purchase路徑，不會因為沒聯網就崩掉。
接下來才是真正關鍵的問題：如果Commerce是按量分級的服務，開發者的調用次數超出配額之后，會發生什么？答案是驗證降級，而不是購買中斷。CommerceManager里有一個isDegraded方法，專門告訴你“云端這次沒有返回經過服務器驗證的結果”。在這種狀態下，權限檢查會回退到平臺自身的收據信號，把權限ID當作訂閱SKU來處理——當然前提是本地沒有緩存過云端驗證的結果。
這套降級邏輯比不上服務器端驗證那么豐富，但它選對了失敗方向。一個付了費的用戶，不該因為你賬號觸發了驗證量上限就被擋在門外。Commerce之所以要分級，是因為它背后跑的是實打實的基礎設施成本：收據驗證、商店接口調用、生命周期處理、網絡鉤子推送、收入分析，每一項都在消耗資源。降級機制的作用，就是讓這個商業現實不至于轉化成用戶側的故障。
Commerce補上的恰恰是那層最容易被低估的后端膠水。它不重新發明支付，只是在支付完成之后，替開發者扛住那些枯燥、繁重、出錯代價極高的校驗和同步工作。對于已經在維護訂閱業務的團隊來說，這套東西解決的不是“能不能做”的問題，而是“能不能別讓我再半夜爬起來修權限同步bug”的問題。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
