> 📘 本案例有深度详解(含真实提示词与全程调试):案例15 · 出海 Mini-CRM(含 Stripe 支付)

【关键工具】 Windsurf + Supabase + Stripe

【70% Vibe】

一个麻雀虽小五脏俱全的 SaaS:用户注册登录、客户看板、付费订阅、流水记录,UI 充满现代科技感。这是独立开发者"出海变现"最经典的形态。用 Windsurf 操控代码、Supabase 做后端数据库、Stripe 做支付,一个能收钱的产品骨架就立起来了。

【30% Engineering】

这是整个篇章里 30% 含金量最高的案例之一,因为它直接关系到"钱"和"多用户数据安全"。

第一是 Stripe 支付回调(Webhook)的签名验证。当用户付款后,Stripe 会回调你的服务器告诉你"这笔钱到账了"。但如果你不验证这个回调的签名,攻击者就能伪造一个"付款成功"的假回调,不花一分钱就解锁你的付费功能。这是支付集成里最经典、也最致命的漏洞。签名验证是把这道门焊死的唯一办法。

第二是数据库的多租户隔离(Multi-tenancy)。SaaS 意味着很多客户共用同一套系统、同一个数据库。你必须从架构上保证:A 客户绝对、永远看不到 B 客户的数据。任何一个疏漏,都可能导致客户数据互相串号——这对一个商业产品是灾难性的信任崩塌。

flowchart TB
    subgraph 攻击者视角
        F[伪造"付款成功"回调]
    end
    F --> S{服务器是否验签?}
    S -->|未验签 ❌| Hack[白嫖付费功能<br/>直接资损]
    S -->|严格验签 ✅| Reject[识破伪造<br/>拒绝处理]
    style Hack fill:#ffe5e5,stroke:#d33
    style Reject fill:#e5ffe9,stroke:#3a3

安全红线

支付回调必须验签,多租户必须隔离。 这两条是付费 SaaS 不可逾越的底线。AI 能在几分钟内帮你接好 Stripe 的"happy path"(一切正常的流程),但它默认不会替你堵上"有人故意作恶"的那条路——而那条路,正是你必须亲手守住的 30%。