我花了 300 小時做了 SaaS 系統，只為不在支付上出事故
整理版優先睇
親手打造 SaaS 支付系統，用 300 小時測試換來嘅安心
呢篇文章係一個獨立開發者嘅親身經歷。佢花咗 300 幾小時去做一個 SaaS 訂閲支付系統，原因係支付入面嘅邊界場景實在太多太容易出錯，例如亂序 Webhook、懶過期漏洞呢類問題，唔係普通測試就揾曬。佢覺得寫 code 已經唔難，AI 可以幫手，但保證正確先係真正嘅門檻。佢最終做咗一個叫 Pay4SaaS 嘅系統，覆蓋咗 30+ 個邊界場景，目的係賣俾認真做 SaaS 變現嘅開發者，等佢哋可以放心收錢。
呢位開發者分享咗佢嘅焦慮來源：即使 code 跑起嚟冇報錯，都唔代表正確。支付最難係邊界場景太多，多到唔知自己唔知啲乜。佢親力親為，80% 時間用喺測試同想場景，重複檢查訂閲表、積分表、支付平台狀態，少睇一個都係隱患。佢引用咗獨立開發圈嘅 Marc Lou 同阮一峯嘅觀點，強調 AI 時代測試係新護城河。
最後佢話，Pay4SaaS 系統唔係淨係功能列表，而係佢踩過或提前諗到嘅坑嘅結晶，包括試用期防重複、併發扣減、升降級按比例結算、Webhook 冪等、亂序 Webhook 防護、懶過期自癒等。佢想賣俾嗰啲想將支付消費做踏實嘅開發者，等佢哋可以自由地瞓覺、等收款通知，而唔使擔心出錯。
- 支付系統最難唔係寫 code，而係邊界場景太多，測試先係真正護城河。
- 作者親身花咗 300 小時，其中八成時間用喺測試同想場景，保證正確。
- AI 可以寫 code，但唔知業務邏輯會唔會出錯，測試一定要自己做。
- Pay4SaaS 系統覆蓋咗 30+ 個常見邊界場景，例如亂序 Webhook、懶過期自癒。
- 認真做 SaaS 變現嘅開發者應該買呢份「確定性」，等自己可以放心瞓覺。
Pay4SaaS — SaaS 變現基礎設施
一個覆蓋 30+ 邊界場景嘅支付系統，專為獨立開發者設計，目前售價 ¥999。
測試到懷疑人生：300 小時嘅心路歷程
12 月下旬嗰排，作者喺度測訂閲定價邏輯，本來以為就快做完，點知望一望清單，仲有 30 幾個場景排緊隊。佢形容嗰種感覺唔係絕望，而係好似行到路盡頭，轉個彎又係一條路，飯都食唔出味，瞓覺都夢緊測試。
佢話嗰種感覺係「你知道自己唔知道啲乜」，每次發現新問題，個心就會諗：仲有幾多個我唔知嘅？
呢種焦慮好具體：code 跑起嚟冇報錯唔代表正確，支付嘅邊界場景實在太多，例如亂序 Webhook、懶過期漏洞，一錯就唔只損失用戶，仲有信譽。
邊界場景係最大嘅敵人
- 亂序 Webhook：用戶續費成功，但過期通知遲咗幾秒，直接將剛續嘅訂閲覆蓋成過期。
- 降級後升級：用戶降級未生效又升級，系統冇清走 pending 降級，到期後降級反噬。
- 懶過期漏洞：Creem、PayPal 嘅過期 Webhook 冇到，用戶過期咗但系統仲顯示 active，白用兩星期。
呢啲例子只係冰山一角，作者話每次遇到都覺得「仲有幾多個我唔知嘅？」答案係冇人知，但上線後用戶會幫你揾，嗰陣時你唔在場，風險好大。
AI 時代，測試先係護城河
作者引用咗獨立開發圈嘅 Marc Lou 同阮一峯嘅觀點：AI 令寫 code 冇門檻，但測試先係新護城河。有個工程師用 1100 美元一週復刻咗 Next.js，證明 code 唔係護城河，測試用例先係。
AI 可以生成 code、補全、重構，但 AI 唔知你嘅業務邏輯邊度會出問題，唔知用戶會點用，唔知併發時會發生咩事。
所以測試用例係開發者自己嘅責任，冇人幫到手，除非有人已經做過一遍，將結果留低。
Pay4SaaS：幫你走過啲坑，換嚟放心
因為擔心呢啲問題，作者做咗 Pay4SaaS，一個覆蓋咗 30+ 邊界場景嘅系統，唔係功能列表，而係佢真實踩過或提前諗到嘅坑。
- 1 試用期防重複：試用過嘅賬號再付款唔會再走試用邏輯。
- 2 併發扣減：同一時間多個請求消費 credits，唔會多扣唔會少扣。
- 3 升降級按比例結算：升級立即補差價，降級保留權益到期末先切換。
- 4 Webhook 冪等：同一事件重複觸發，數據庫唔會重複寫入。
- 5 Credits 歸零保護：餘額不足時拒絕操作，唔會變成負數。
- 6 亂序 Webhook 防護：遲到嘅過期通知唔會覆蓋已續費嘅訂閲。
- 7 懶過期自癒：每次訪問自動檢測並修復過期但未標記嘅訂閲。
每一個場景都有對應嘅測試用例，買走嘅唔係 code，係作者幫你走過一次坑之後留低嗰份確定性同放心。
適合邊啲人？認真做 SaaS 變現嘅你
作者話呢個系統係賣俾認真做 SaaS 訂閲變現嘅開發者，唔係試水嗰啲。獨立開發嘅自由在於時間自由、收入自由，但前提係收費件事本身要正確、要放心。
如果你都試過嗰種「唔知仲有幾多坑」嘅感覺，¥999 買一份安心，而家係最低價。
佢相信，呢個投資可以令你瞓覺都安心，等收款通知自然嚟。
01
2月下旬嘅一個下晝，我正在測試訂閲呢個定價模式嘅邏輯，繼續前日未做完嘅場景，做完打個剔，然後睇落去。
嗰日測完第 16 個，我習慣性咁向下碌咗一下清單。
仲有 30 幾個喺度排隊。
我大嘆咗一口氣，眼神冇哂光，呆坐喺度。
唔係攰，亦都唔係想放棄。
只係忽然之間有一種好具體嘅感覺——我以為自己就快做完，但原來個底根本唔喺嗰度，因為每個用例唔係話測完就得，仲可能會引發新嘅問題。
呢種感覺好難形容。唔係絕望，而係一種更低沉嘅嘢。就好似你以為行到條路嘅盡頭，點知係個彎，轉過去又係一條路。
嗰幾日食飯，喺個嘴度嚼緊，但係唔知道食緊乜，冇味，個頭濛濛哋。
夜晚攤落嚟，個腦仲喺度諗緊啲場景——呢個測咗未，嗰個邊界條件有冇覆蓋到，併發嗰陣 credits 會唔會扣多咗，降級咗之下個週期收嘅費用啱唔啱，搞錯咗，損失嘅唔只係用戶、收入，仲有信譽……
就算瞓着咗，發夢都仲喺度測試。
02
我後來諗，呢種焦慮係為咗乜。
程式碼行到冇報錯，唔代表係啱。
支付呢件事，最難嘅唔係邏輯本身，而係邊界場景太多，多到你唔知自己唔知啲乜。
亂序 Webhook。用戶續費成功，但訂閲過期嘅通知遲咗幾秒，直接將啱啱續咗嘅訂閲覆蓋成過期。
降級之後升級。用戶降級仲未生效，又升級咗，系統冇清走 pending 降級，到期之後將啱啱升咗嘅級又降返落嚟。
懶過期漏洞。creem、PayPal 嘅過期 Webhook 冇到，用戶訂閲早就過期咗，但系統一路顯示「active」，白用咗兩個禮拜。
每次遇到呢種情況，個心都會有一個念頭彈出嚟，仲有幾多個係我唔知嘅？
呢個問題冇答案。我哋冇可能窮舉所有情況。但係上線之後，用戶會幫我哋揾到。
嗰個時候，我哋唔在場。我哋可能同屋企人食緊飯，休息緊，去緊旅行。程式碼行緊，用戶俾緊錢，或者俾咗錢發現唔啱，嚟揾我哋。
呢種感覺，諗起就。。。我唔想經歷。
03
所以我親力親為，用咗 300 幾個鐘，將呢件事做完。
咁多時間，唔係全部寫程式碼，寫程式碼其實加埋冇幾日。
300 個鐘有 80% 用喺測試度，諗緊仲有咩場景未覆蓋到，構造邊界條件，再反覆行，再改，再行一遍，睇下後台訂閲表、積分表，睇下支付平台嘅訂閲狀態，再睇下頁面展示，呢啲操作，唔知重複咗幾百次。但係少睇一個，後面全部都係隱患。
獨立開發圈嘅標誌性人物 Marc Lou，前幾日發咗一條 tweet。
我第一次見到呢句話嘅時候，就深深共鳴咗。
是啊，喺 AI 能夠幫所有人寫程式碼嘅年代，寫程式碼已經冇門檻喇。
阮一峯前幾日都發咗一篇博文，AI 時代，測試係新嘅護城河。一個工程師用咗 1100 美元，用一個禮拜復刻咗 Next.js，程式碼已經唔係護城河，測試用例先係。
的確，程式碼唔難，難嘅係，保證啱，尤其係，涉及交易嘅事，做錯咗，唔係損失用戶利益就係損失自己利益。
行得到同行得到安心、正確、唔俾人惹麻煩，係兩回事，咁點樣保證正確？只有透過大量測試先得，冇第二個方法。
程式碼呢件事，而家真係唔難。AI 可以生成、可以補全、可以重構。但係 AI 唔知道你嘅業務邏輯邊度會出問題，唔知道用戶會點樣用，唔知道併發嘅時候會發生咩事。
佢生成程式碼，但係出問題之後，用戶失望、投訴、流失，嗰啲全部都係我哋要收拾嘅爛攤子。
所以測試用例係我哋自己嘅事。冇人可以幫手做呢件事——除非有人已經做過一次，將結果留低咗。
04
因為擔心呢啲，所以我整咗 Pay4SaaS，佢一次過覆蓋咗 30+ 個邊界場景，唔係功能列表，係我真實踩過或者提前諗到、然後驗證過嘅嗰啲坑。例如——
試用期防重複 — 試用過嘅帳號再俾錢，唔會再行試用邏輯，呢個之前仲專登寫咗篇文章。
併發扣減 — 同一時間多個請求消費 credits，唔會扣多亦唔會扣少。
升降級按比例結算 — 升級即刻補差價，降級保留權益到期末先切換。
Webhook 冪等 — 同一事件重複觸發，數據庫唔會重複寫入。
Credits 歸零保護 — 有少量積分，併發操作嘅時候，餘額不足就拒絕操作，唔會變成負數。
亂序 Webhook 防護 — 遲到嘅過期通知唔會覆蓋已續費嘅訂閲。
懶過期自愈 — 每次訪問自動檢測並修復過期但未標記嘅訂閲。
每一個場景，都有對應嘅測試用例。買走嘅唔係程式碼，係我幫你將呢啲坑行過一次之後，留下嚟嘅嗰份確定性同放心。
05
我想賣俾嘅，係認真做 SaaS 訂閲變現嘅開發者。唔係試水嘅，係想將支付消費呢件事做實、做長久嗰種。
獨立開發最好嘅地方係自由。時間自由，收入自由，唔使匯報，唔使開會，程式碼上線咗，瞓一覺，醒嚟睇收款通知。但係呢一切嘅前提係，收費呢件事本身係啱嘅，係放心嘅，否則全部都係空談。
如果你都喺呢條路上，都有過嗰種「唔知仲有幾多坑」嘅感覺——
¥999，pay4saas.cn，一個令你放心收錢嘅 SaaS 變現基礎設施，嚟睇下適唔適合你。價格會階段性調整，而家係最低價。
01
2 月下旬的一天下午，我在測訂閲這個定價模式的邏輯，繼續前天沒做完的場景，做完打個勾，往下看。
那天測完第 16 個，我習慣性地往下翻了一眼清單。
還有 30 多個在排隊。
我長嘆了一口氣，眼神無光，呆坐在那裏。
不是累，也不是想放棄。
就是忽然有一種很具體的感覺——我以為自己快完成了，但底根本不在那裏，因為每個用例不是說測完就行了，還可能引發新的問題。
這種感覺很難描述。不是絕望，是一種更低沉的東西。像你以為走到了路的盡頭，結果是個轉彎，轉過去又是一條路。
那幾天吃飯，在嘴裏嚼着，可不知道在吃什麼，沒有味道，頭濛濛的。
晚上躺下來，腦子裏還在過那些場景——這個測了沒有，那個邊界條件有沒有覆蓋到，併發的時候 credits 會不會多扣，降級了下週期收的費用對麼，弄錯了，損失的不僅是用戶，收入，還有信譽……
即使睡着了，做夢還在測試。
02
我後來想，這種焦慮的是什麼。
代碼跑起來沒報錯，不代表對。
支付這件事，最難的不是邏輯本身，是邊界場景太多，多到你不知道自己不知道什麼。
亂序 Webhook。用戶續費成功，但訂閲過期的通知晚到了幾秒，直接把剛續的訂閲覆蓋成過期。
降級後升級。用戶降級還沒生效，又升級了，系統沒清掉 pending 降級，到期後把剛升的級又降回去了。
懶過期漏洞。creem、PayPal 的過期 Webhook 沒到，用戶訂閲早過期了，但系統一直顯示“active”，白用了兩週。
每次遇到這種情況，心裏都會有一個念頭冒出來，還有多少個我不知道的？
這個問題沒有答案。我們不可能窮舉所有情況。但上線之後，用戶會幫我們找到。
那個時候，我們不在場。我們可能在和家人吃飯，在休息，在旅行。代碼在跑，用戶在付錢，或者付了錢發現不對，來找我們。
這種感覺，想想就。。。我不想經歷。
03
所以我親力親為，花了 300 多小時，把這件事做完。
這麼多時間，不是全寫代碼，寫代碼其實加起來沒幾天。
300 小時 80% 在測試上，在想，還有什麼場景沒覆蓋到，在構造邊界條件，再反覆跑，再改，再跑一遍，看看後台訂閲表，積分表，看看支付平台的訂閲狀態，再看看頁面展示，這些操作，不知道重複了幾百遍了。但是少看一個，後面都是隱患。
獨立開發圈的標誌性人物 Marc Lou，前幾天發了一條推特。我第一次看到這句話的時候，就深深共鳴了。
是啊，在AI能幫所有人寫代碼的年代，寫代碼已經沒有門檻了。
阮一峯前幾天也發了一個博文，AI 時代，測試是新的護城河。一個工程師花 1100 美元，用一週復刻了 Next.js，代碼已經不是護城河，測試用例才是。
的確，代碼不難，難的是，保證對，尤其是，涉及交易的事，做錯了，不是損失用戶利益就是損失自己利益。
能跑和能跑的安心、正確、不給人找麻煩，是 2 回事，那怎麼保證，正確？只有通過大量測試才行，別無他法。
代碼這件事，現在真的不難。AI能生成，能補全，能重構。但AI不知道你的業務邏輯哪裏會出問題，不知道用戶會怎麼用，不知道併發的時候會發生什麼。
它生成代碼，但出問題以後，用戶失望、投訴、流失，那都是我們要收拾的爛攤子。
所以測試用例是我們自己的事。沒有人能替做這件事——除非有人已經做過一遍，把結果留下來了。
04
因為，擔心這些，所以我做了 Pay4SaaS，它一下覆蓋了 30+ 個邊界場景，不是功能列表，是我真實踩過或者提前想到、然後驗證過的那些坑。比如——
試用期防重複 — 試用過的賬號再付款，不會再走試用邏輯，這個之前還專門寫了個文章。
併發扣減 — 同一時間多個請求消費 credits，不多扣不少扣。
升降級按比例結算 — 升級立即補差價，降級保留權益到期末才切換。
Webhook 冪等 — 同一事件重複觸發，數據庫不會重複寫入。
Credits 歸零保護 — 有少量積分，併發操作時，餘額不足時拒絕操作，不會變成負數。
亂序 Webhook 防護 — 遲到的過期通知不會覆蓋已續費的訂閲。
懶過期自愈 — 每次訪問自動檢測並修復過期但未標記的訂閲。
每一個場景，都有對應的測試用例。買走的不是代碼，是我替你把這些坑走過一遍之後，留下來的那份確定性和放心。
05
我想賣給的，是認真做 SaaS 訂閲變現的開發者。不是試水的，是想把支付消費這件事做踏實、做長久的那種。
獨立開發最好的地方是自由。時間自由，收入自由，不用匯報，不用開會，代碼上線了，睡一覺，醒來看收款通知。但這一切的前提是，收費這件事本身是對的，是放心的，否則都是空談。
如果你也在這條路上，也有過那種「不知道還有多少坑」的感覺——
¥999，pay4saas.cn，一個讓你放心收錢的 SaaS 變現基礎設施，來看看適不適合你。價格會階段性調整，現在是最低價。