开源SaaS付费订阅模板：Next.js+Stripe+Supabase快速搭建指南

为什么你需要一个SaaS付费模板

独立开发者和小团队搭建SaaS应用时，用户认证、付费订阅、数据库同步这些基础设施往往要耗费数周时间，真正决定产品成败的核心功能反而一拖再拖。

这种现象在业内被称为「基础设施税」——根据多项开发者调研，一个典型SaaS应用从零搭建认证+付费+数据库同步这三层基础设施，平均耗时2-4周，而这些功能对用户来说几乎是「隐形」的，用户感知到的只有核心产品价值。Next.js、Supabase、Stripe这三者的组合之所以成为独立开发者社区的事实标准，正是因为它们各自解决了一个关键问题：Next.js提供全栈框架减少技术选型成本，Supabase以开源PostgreSQL为核心提供BaaS能力，Stripe则是全球支付合规的最低门槛路径。

开发者Sean（频道名ShanTech Stories）开源了一套基于 Next.js + Supabase + Stripe 的生产级SaaS模板，采用MIT协议，涵盖认证、暗色模式、Stripe集成和现代UI组件，全部使用TypeScript和Tailwind CSS编写。下面梳理这套模板的完整搭建流程和核心架构设计。

Stripe支付系统配置

创建产品与优惠券

付费体系的第一步是在Stripe后台创建产品。进入Stripe Dashboard的Product Catalog，新建一个Recurring（周期性）类型的产品并设置月度订阅价格，模板中演示的方案是$0.99/月。

Stripe产品目录配置

产品创建完成后，可以在Coupon标签页配置优惠券，比如设置一个50%折扣的优惠码，限制前50位用户使用，为早期推广提供灵活的营销手段。

设置Payment Link与试用期

在Stripe的Payment Links中创建支付链接时，有几个关键配置项：

免费试用期：比如7天免费试用，用户无需立即付款
促销代码：勾选允许用户输入优惠码
支付完成后跳转：将用户重定向回应用的Dashboard页面，而不是Stripe默认的确认页

这本质上是一个低代码工具——通过勾选配置项就能生成完整的支付页面，集成门槛大幅降低。

Webhook：让应用实时响应Stripe事件

这是整个Stripe集成中最关键也最容易踩坑的环节。Webhook的作用是让你的应用实时监听Stripe的事件——用户完成付款、取消订阅或试用到期时，Stripe会主动向你的服务器发送通知。

理解Webhook的本质有助于避免常见误区：Webhook是「反向API」——传统API是你主动查询数据，而Webhook是服务方在事件发生时主动推送数据到你指定的URL。Stripe的事件驱动架构意味着支付状态的变更（付款成功、退款、订阅续费失败等）会在毫秒级别通知到你的服务器，而不需要你轮询Stripe API。这在订阅制SaaS中尤为关键：用户的信用卡可能在续费时被拒，Stripe会通过invoice.payment_failed事件通知你，你的系统才能及时降级用户权限或发送提醒邮件。Webhook的安全性通过Signing Secret保障——Stripe用密钥对每个请求签名，你的服务器验证签名后才处理事件，从而防止伪造请求攻击。

Webhook路由代码结构

模板中Webhook的API路由位于 app/api/stripe/webhook/route.ts，监听以下几类事件：

customer.subscription.*：订阅状态变更（创建、更新、删除）
checkout.session.*：结账会话完成
invoice.*：发票相关事件
payment_intent.*：支付意图事件

注意：不要订阅所有事件类型，只选择应用实际需要处理的事件，否则会带来不必要的延迟和资源消耗。

认证系统：Google Cloud + Supabase

Google OAuth配置

模板采用Google登录作为认证方式，底层使用的是OAuth 2.0协议——现代身份认证的行业基石。整个流程涉及三方：用户浏览器、你的应用服务器（这里是Supabase）、Google授权服务器。当用户点击「Google登录」时，浏览器被重定向到Google，Google验证用户身份后，将授权码发送到预先注册的Redirect URI（即Supabase的回调地址）。Supabase收到授权码后，用Client Secret向Google换取Access Token，再从Google获取用户信息完成登录。

需要在Google Cloud Console中创建OAuth 2.0凭据，核心步骤如下：

在API Services > Credentials中创建OAuth Client ID
设置Authorized JavaScript Origins（本地开发填localhost:3000，生产环境填部署域名）
配置Authorized Redirect URLs，指向 /auth/callback

认证回调URL配置

Supabase认证集成

Supabase作为BaaS（Backend as a Service），极大简化了认证流程。在Supabase的Authentication设置中启用Google Provider，填入从Google Cloud获取的Client ID和Client Secret即可。

双向配置是关键：Google Cloud需要提前知道合法的回调地址（防止授权码被劫持到恶意网站），Supabase需要Client Secret才能完成Token交换。两个系统通过交换密钥和回调URL建立信任关系——任何一方配置缺失，整个OAuth流程都会在不同阶段失败，这也是初次配置时最常见的报错来源。

Supabase与Google Cloud的双向配置

在Supabase的URL Configuration中，需要配置三个地址：

站点主URL
/auth/callback（认证回调）
/login（登录页面）

数据库设计与触发器

模板预置了四张核心数据表，通过SQL Editor一键创建：

表名	用途
`users`	用户基本信息
`user_preferences`	用户偏好设置（如是否完成引导流程）
`user_trials`	试用期跟踪（开始时间、结束时间、是否取消）
`subscriptions`	订阅信息（与Stripe保持同步）

其中最巧妙的设计是数据库触发器（Trigger）。PostgreSQL触发器是一种在特定数据库事件发生时自动执行预定义函数的机制，它解决的是「认证系统与业务数据库的解耦同步」问题——Supabase的Auth系统维护自己的auth.users表，而业务逻辑需要的用户数据（偏好设置、试用状态等）存储在独立的业务表中。

如果用应用层代码来处理这个同步（即用户注册后调用API写入多张表），会面临网络失败、代码异常导致数据不一致的风险。触发器在数据库层面保证原子性：当Supabase Authentication检测到新用户注册时，自动调用 handleNewUser 函数，将用户信息同步插入users、user_preferences和user_trials三张表——要么全部成功，要么全部回滚，从根本上消除了数据孤岛问题。subscription表则通过Webhook与Stripe实时同步，形成完整的数据闭环。这是「数据库优先」架构思想的典型应用。

部署到Vercel与最终联调

Vercel部署流程

将应用部署到Vercel非常简单：导入GitHub仓库，粘贴所有环境变量（Supabase URL、API Keys、Stripe Keys等），点击Deploy，通