TanStack Ship vs Makerkit: B2B 多租户 vs 边缘原生独立 SaaS

本文由 Huifer 撰写，TanStack Ship 的独立开发者和维护者。我用三天时间试用评估了 Makerkit 的 B2B 功能。它的组织架构、角色体系和多租户基础设施确实比当前 TanStack Ship 开箱即用的方案成熟得多。如果我要服务多个企业级客户、他们有复杂的工作区权限需求，那 Makerkit 将是决定性的选择。但对于独立开发者或小团队主导的订阅产品，TanStack Ship 的增长工具链和边缘部署能力更直接对味。

已核实来源：TanStack Ship GitHub · Makerkit 文档 · TanStack Start 文档 更新于：2026-07-20 · 更新日志

TL;DR: 当多租户 B2B 结构、团队角色和企业级应用模型是你第一天最硬的刚需时，选 Makerkit。当你想以 TanStack Start 在 Cloudflare Workers 上快速起步、且需要内置归因、活动、推荐奖励和营收运营时，选 TanStack Ship。两者没有绝对优劣。真正的坑是用长功能清单去买一个产品，却忽视了产品中最不能妥协的那个不变量。

真正的分叉口：租户架构 vs 增长运营

两款产品都消除了认证、计费、应用骨架和部署中的重复工作。真正的分歧在于跨过基线之后各自在优化什么。Makerkit 的公开文档强调的是围绕账户、团队、成员和权限组织的 SaaS 应用。TanStack Ship 强调的是边缘原生的 TanStack 架构，以及从获客到营收分析的全链路运营闭环。

这个区别比逐行对比功能更重要。一个多租户 B2B 产品，如果工作区边界薄弱，即使活动看板做得再好也会出问题。一个创始人主导的订阅产品，即使做好了角色检查，如果归因、优惠、推荐积分和 MRR 报表分散在各自的电子表格里，运营依然会陷入盲区。

我的原则很简单：选那个已经在建模你承受不起建模失误的风险的 starter。先把这个风险说出来，完整功能清单 才有用武之地。

快速推荐表

这条建议不是让你在任意客户规模下都去买 Makerkit。"五人以上企业客户"是我给出的实际警告——权限和账户复杂度会比你预想的来得更早，不是什么科学阈值。

架构与部署模式

TanStack Ship 基于 TanStack Start 和 TanStack Router，目标是 Cloudflare Workers，整合 D1、R2、KV 和 Queues 来满足产品存储需求。设计原则偏好类型安全的路由、服务端函数、边缘兼容的依赖项，以及单一运维平台。如果你的团队本来就想用这套技术栈，一致性本身就消除了集成选型成本。

Makerkit 文档中的技术栈面向 React SaaS 生态，以数据库驱动的账户和团队模式为核心。其 B2B 优势来自于将租户视为一等公民的应用概念，而非可选的 organization_id 列。购买前请查阅其当前文档，因为支持的框架、云服务商和包边界可能会变化。

为什么框架契合度是商业决策

框架熟悉度直接影响交付风险。一个使用 Next.js 的团队用 Makerkit 可能会更快上手，即使 Cloudflare 架构表面看起来成本更低。已经使用 TanStack Router 的团队可能在将路由所有权和数据加载约定翻译到另一个框架时浪费大量时间。两个学习曲线都不是免费的。

我比较的是依赖边界，不是看 logo。有多少 SDK 能在这个运行时里执行？Session 存在哪里？哪个数据库负责租户隔离？后台任务如何重试？一位工程师能否不跨越三个部署系统就追踪从注册、结账到授权变更的全流程？这些问题比"边缘 vs 无服务器"这种泛泛口号更能预测第六个月的运维状态。

关于 TanStack 特定的取舍，对比中心 提供了更完整的背景。当 B2B 账户深度比技术栈整合更重要时，Makerkit 仍然是一个合理的答案。

先测数据所有权，再做 UI

暴露 starter 假设最快的方式，是为五条记录画出所有权图：用户、工作区、订阅、发票和项目。问自己：一位用户能否属于多个工作区？订阅属于个人还是账户？当最后一个所有者离开时，共享资源怎么处理？然后在一条路由和一条数据库查询里强制执行这些答案。

对于 B2B 产品，我还会测试：邀请链接复用、移除管理员、跨工作区 URL 猜测，以及工作区被归档后才收到的账单事件。这些不是冷门边界情况——它们揭示的是租户是架构基础还是装饰贴片。Makerkit 的模型更接近从这些问题出发。

对于独立订阅产品，我跑另一套测试：从第一个匿名请求开始保持活动身份，贯穿注册和结账全程，然后在管理后台报表里展示归因后的订单。这一小段流程能揭示增长数据是连贯的领域还是一堆集成组件的集合。TanStack Ship 更接近这个工作流。

在给仪表盘加样式之前，两套测试都做。一套打磨好的模板可能隐藏所有权模型不匹配的问题长达数周，而一个小的授权或归因测试一下午就能让错配暴露无遗。选型完成后保留这套测试——它会成为解释为什么选了这个架构的可执行文档。

Makerkit 更强的地方

多租户账户建模

Makerkit 的核心优势不是"有角色"这么简单。它给 B2B 创始人提供了一套更强的概念词汇：个人账户、团队账户、成员、邀请和权限。这些概念成为账单和授权的脊柱。在上线后再去重建这些概念是有风险的，因为届时每张表、每条路由和每个后台任务可能都已经假设了另一套所有权模型。

TanStack Ship 有认证、用户管理和基于角色的访问控制，但我不会声称它与成熟的嵌套组织系统持平。如果你的路线图要求一个用户对应多个工作区、按工作区计费、委托管理权以及精细化的数据访问隔离，Makerkit 值得第一个原型验证。

面向企业形态工作的契合度

企业买家在关心推荐引擎之前，先问的是：审计能力、账户生命周期、权限变更和入职控制。Makerkit 的定位方向让这些对话更容易映射到应用概念。starter 本身无法提供合规认证，买家仍然需要内部政策、基础设施证明和法律工作，但底层模型可以减少返工。

这是我会主动暴露 Makerkit 优势的地方，我不想让一个有偏向的比较掩盖事实。我宁可把不适合的读者送去 Makerkit，也不愿卖出一个从租户架构重写开始就注定痛苦的 TanStack Ship 授权。

TanStack Ship 更强的地方

增长运营是产品的内置部分

TanStack Ship 打通了 SSR 兼容的 UTM 采集、跨会话归因、活动优惠、短链、推荐积分、邮件活动和营收报表。价值在于连接。一条活动可以影响结账流程，产生的订单保留归因链路，管理后台可以跨渠道对比而不需要另一套分析集成项目。

Makerkit 提供了更扎实的 B2B 应用基础，但创始人需要确认：从获客到营收的完整工作流是已经存在还是需要自己组装。"Stripe 接入"不等于活动归因或运营报表也包含在内。如果两种侧重都不匹配，参见替代方案目录 查看其他 starter 的形态。

边缘原生的 TanStack 所有权

TanStack Ship 围绕 Cloudflare Workers 设计，而非将运行时当作次要的部署目标。这影响了依赖选择、请求上下文、存储、异步工作和可观测性。对于锁定 Cloudflare 的团队，收益是架构可预测性，不是每个请求都更快的保证。

我不会发布一个通用的延迟冠军。地理位置、数据库位置、缓存状态、套餐等级和路由代码是决定结果的主导因素。用相同用户旅程对生产级部署做实测。

#!/usr/bin/env bash
set -euo pipefail

for base in "$MAKERKIT_PREVIEW_URL" "$TANSTACK_SHIP_PREVIEW_URL"; do
  echo "Testing $base"
  for path in / /sign-in /dashboard; do
    curl --silent --output /dev/null \
      --write-out "$path status=%{http_code} ttfb=%{time_starttransfer} total=%{time_total}\n" \
      "$base$path"
  done
done

在接近目标客户所在地区的节点上分别跑暖请求和冷请求，保留原始输出，对比等价路由。不要拿别人首页的 Lighthouse 分数来证明认证后的仪表盘性能。

比较实现工作量，不比勾选清单

在评估任一 starter 之前，我把需求转化为加权、可测试的陈述。权重反映的是需求缺失时对业务的损害程度；分数反映的是原型实际证明了什么，而不是落地页暗示了什么。

type Requirement = {
  name: string
  weight: 1 | 2 | 3 | 4 | 5
  makerkit: 0 | 1 | 2
  tanstackShip: 0 | 1 | 2
}

const requirements: Requirement[] = [
  { name: 'workspace isolation', weight: 5, makerkit: 2, tanstackShip: 1 },
  { name: 'UTM revenue attribution', weight: 4, makerkit: 0, tanstackShip: 2 },
  { name: 'Cloudflare-native jobs', weight: 3, makerkit: 0, tanstackShip: 2 },
]

const total = (key: 'makerkit' | 'tanstackShip') =>
  requirements.reduce((sum, item) => sum + item.weight * item[key], 0)

console.table({ makerkit: total('makerkit'), tanstackShip: total('tanstackShip') })

用你自己的证据替换这些示例需求和临时分数。加上迁移工作量、服务商约束、授权条款、支持预期，以及你必须删除的功能。删除也很重要：未使用的企业级抽象概念同样会拖慢独立产品的速度，就像缺失的租户功能可能危及 B2B 数据一样。

原型一条纵向切片

在每个候选方案中构建：注册、账户创建、邀请、账单和一条受保护资源。然后加入你每周都要执行的那个操作：对于 B2B 可能是修改成员角色，对于消费者订阅可能是追踪一条付费活动到营收。记录配置摩擦、涉及代码、失败测试和悬而未决的问题。

三天给了我足够证据理解 Makerkit 的模型，但不足以覆盖所有生产场景。读者应将本文视为决策框架，当前供应商文档才是权威。

诚实的局限性及长期成本

TanStack Ship 多租户深度较弱是当前的局限性。不要假设路线图里的功能已经存在就下单。它还要求团队掌握 TanStack Start 和 Cloudflare 基础能力。这种学习投入只有在最终架构与产品匹配时才有价值。

Makerkit 可能包含你不需要的 B2B 深度，而你的增长运营体系可能仍然需要定制开发。它的框架和技术栈选择应基于你的团队来评估，而不能仅因为和我的偏好不同就打上"锁定"的标签。定价和授权条款波动较大，所以我有意不在此固定价格表——做决策当天请核实 TanStack Ship 定价 和 Makerkit 当前购买页面。

支持质量同样难以用徽章来评判。在评估期间提交一个真实的技术问题，根据回答来做判断。starter 的长期价值包括更新、迁移说明，以及维护者在披露重大变更时的清晰程度。

决策树

选 Makerkit：当账户层级是你产品中最不能妥协的不变量；多个用户在客户工作区内协作；按账户的角色和计费是眼前需求；你的团队偏好其文档化的技术栈；企业形态的入职流程比内置获客工具更重要。

选 TanStack Ship：你是独立开发者或技术小团队；TanStack Start 和 Cloudflare Workers 是主动的选择；产品以订阅驱动为主而非组织驱动；归因、活动、推荐、积分、邮件和营收运营如果不做进产品里，就会在下一个开发周期吃掉你的时间。

两个都先不选：当商业模式还不够清晰时。先做一个小规模的框架原生原型，可能会发现你需要的是市集型平台、用量计费、私有化部署或其他两个 starter 都不深入的方向。

最终建议

在这场对比中，Makerkit 是 B2B 多租户更好的起点。TanStack Ship 更适合它本来服务的边缘原生独立开发者或小团队订阅 SaaS。这个结论尊重了两款产品，因为它锚定的是受众和系统风险，而不是声称某个代码库在每一行都胜出。

写下你的五个不妥协需求，原型化风险最高的纵向切片，按你自己的工程师时薪给缺失的工作定价。更便宜的授权如果遗漏了你的核心不变量，可能是昂贵的选择；更深的套餐如果深度方向错了，也可能是浪费。

如果第二个画像匹配你的产品，先从 TanStack Ship 的免费版开始，检查功能清单，在选付费套餐前先验证架构。