构建全栈 SaaS 应用
很多 Next.js 教程能带你做完一个“能运行的产品演示”，但离真正的 SaaS 还差一整层工程现实：
- 账号体系是否可扩展。
- 订阅和权限是否能对齐。
- 后台和用户端是否能共享同一套模型。
- 上线后出了问题怎么追。
SaaS 的难点不是把页面做出来，而是把“产品规则”落进系统边界。
1. 先把 SaaS 的核心对象定义清楚，再写页面
一个最小 SaaS 通常至少有这几层对象：
| 对象 | 作用 | 常见错误 |
|---|---|---|
| User | 登录主体 | 直接把权限全挂到 user 上 |
| Workspace / Tenant | 团队或组织边界 | 单用户模型难扩团队 |
| Subscription | 计费套餐 | 只做页面展示，不落权限 |
| Resource | 真正的业务数据 | 没有 tenant 隔离 |
如果你一开始只设计 User，而没有 Workspace 或订阅对象，后面做团队版和计费升级会很痛苦。
2. 目录结构要围绕“领域”和“权限边界”组织
对 SaaS 来说，比起纯组件分层，更重要的是业务边界清晰：
app/
(marketing)/
(auth)/
dashboard/
api/
lib/
auth/
billing/
db/
permissions/
这样做的好处是：认证、计费、权限和数据访问的边界更清晰，不会让每个页面各写一套判断逻辑。
3. 认证只是入口，权限才决定产品能不能扩展
很多项目做完登录就觉得认证系统完成了，结果一到团队版就开始崩。
更稳的思路是：
- 认证解决“你是谁”。
- 授权解决“你能做什么”。
- 计费解决“你在什么套餐下能做什么”。
这三件事如果不拆开，后面每加一个套餐或角色，复杂度都会乘法上涨。
4. 一个常见失败案例：先写计费页面，后补订阅状态，结果权限全靠 if 判断
事故链路通常是：
- 先接入支付。
- 前端根据套餐名隐藏按钮。
- 后端没有真正校验权限。
- 用户只要知道接口就能越权调用。
根因是把“展示层限制”误当成“权限系统”。
修复方式应该是：
- 订阅状态落库。
- 权限判断放到服务端。
- 前端只负责同步展示，不负责最终裁决。
5. SaaS 的真正护城河，常常是后台运营能力而不是首页
一个可维护的 SaaS 后台至少要能支持：
- 用户与 workspace 管理。
- 订阅状态查看。
- 异常订单与退款处理。
- 配额、日志与操作审计。
这些能力如果一开始完全不设计，后期运营成本会远高于功能开发成本。
6. 部署与观测要提前进入架构，而不是发布前补一层
SaaS 项目上线后最常见的问题是：
- 某个用户报错，无法定位。
- 某个套餐功能打不开，不知道是权限还是配置问题。
- 计费链路失败，但没有统一日志。
因此从早期就要准备：
- request id
- 关键行为日志
- 订阅事件追踪
- 错误边界与回滚开关
7. 上线前 Checklist
- User、Workspace、Subscription、Resource 四层对象已分清。
- 认证、授权、计费状态不是混在一起判断。
- 服务端是真正的权限裁决层。
- 后台已能查看用户、套餐、日志与异常订单。
- 关键操作有审计记录与 request id。
- 支付、续费、退款与降级都有状态流转定义。
- 营销站、登录、控制台边界已隔离。
- 已准备最小可回滚的部署方案。
FAQ
Next.js 适合做 SaaS 吗？
适合，尤其适合内容站、营销站和控制台共存的产品。但前提是你把认证、权限和数据边界先设计好。
SaaS 一开始一定要做多租户吗？
不一定，但至少要预留 tenant 或 workspace 这层抽象，不然后续升级代价很高。
订阅状态只在前端控制可以吗？
不可以。前端只负责展示，真正的功能开关必须在服务端校验。
