什么情况下 Sushi SaaS 适合你

只有当你愿意接受 starter 的决策时，它才会节省时间。Sushi SaaS 是为需要把身份、租户、计费、用量和运营连接起来的团队准备的源码骨架，并不能让你绕过对这些系统的理解。

以下情况适合选择 Sushi SaaS

• Next.js、TypeScript、PostgreSQL、Drizzle、Better Auth 和 Stripe 符合预定技术栈。
• 客户可能个人或团队使用，而计费、积分、文件、任务与限额都属于组织。
• 资金和用量变化需要幂等、不可变台账、webhook 重放处理与对账。
• 你准备运营私有对象存储、事务邮件、限流、持久任务和本地化错误。
• 你希望本地开发流程、迁移策略、可观测性、备份、恢复演练、容器和上线审计在发布前就属于 starter。
• 客服需要独立部署、具备 MFA、读写角色、风控、账单检查和审计的管理后台。
• 团队重视强制架构边界与失败路径测试，也愿意维护它们。

价值不在页面数量，而在于这些系统共用一个租户模型和一套不变量。

以下情况应选择更小的方案

• 只是在用落地页或一次性原型验证需求。
• 产品只面向单用户、不计费，或使用托管身份与数据库平台可以减少运维。
• 必须采用的数据库、框架、身份 provider 或计费模型与现有技术栈冲突。
• 需要托管式 no-code 产品，而不是团队拥有的源码。
• 替换现有租户或合规模型比从更窄的基础开始更昂贵。

选择采用方式

保留骨架

适合大多数边界都匹配的情况。替换品牌与示例业务，配置 provider，然后在上面构建差异化流程。这样速度最快，也让未来升级更可理解。

删除完整能力

核心架构适合、某个业务域不适合时可采用。应纵向删除完整功能——UI、路由、服务、模型、schema、配置、任务、测试与文档——而不是只隐藏导航并留下无人负责的数据路径。

复制一个模式

适合已有应用。代码之外，还要带上 migration、约束、测试与运维行为。缺少幂等 key 和数据库规则的积分函数，并不是同一个模式。

从其他基础开始

当核心技术栈或所有权模型不同，这往往才是正确答案。Starter 应减少未来决策，而不是在产品开发前制造一场漫长重写。

克隆后仍存在的成本

你仍需负责 provider 账户、secret、价格、税务与退款政策、法律文案、数据保留、监控、无障碍、威胁评估和事故响应。请替换图像/视频 mock provider，并决定 Content Studio、营销、预约和推荐是否属于产品，同时设定真实恢复目标。

“面向生产”表示仓库明确暴露这些责任并提供技术控制，不表示你的部署已获得认证。

一小时适配检查

1. 运行快速开始，打开两个应用。
2. 把必须能力映射到仓库中的真实页面与 service。
3. 给每项主要决策标记保留、修改或删除：技术栈、组织、计费、积分、存储、任务、语言、管理后台与推荐。
4. 跟踪一条资金或授权流程，并阅读对应测试。
5. 估算“修改”列；如果它占多数，应选择更小的起点。

然后阅读 Sushi SaaS 的代码结构与部署与安全。本文基于 starter commit 2a1a04a。