本文由 Huifer 撰写，TanStack Ship 独立开发者兼维护者。 我在同一个基准 SaaS 规范（auth + Stripe + admin + blog + UTM）上，用 8 天时间分别测试了 ShipFast 和 TanStack Ship。本文中的构建时间和运行时数据均来自此次测试。ShipFast 在社区势能上胜出；TanStack Ship 在边缘性能和避免供应商锁定上胜出。
验证来源：TanStack Ship GitHub org · TanStack Start docs · Cloudflare Workers docs 最后更新：2026-07-23 · 更新日志
TL;DR： 如果你想要一个 Next.js + Vercel 启动包，且看重最大社区规模和最多第三方集成，ShipFast 是正确选择。如果你在意冷启动速度、边缘节点覆盖、流量出口费用，以及避免被 Vercel 锁定供应商，TanStack Ship 是正确选择。两者交付相同的业务模块——auth、billing、UTM、i18n、admin、AI tooling——但运行在不同的运行时上。下面的数字来自我在同一 SaaS 规范上运行 8 天基准测试的结果。
TL;DR — 各自适合谁
选择 ShipFast 如果：你想在这个周末就上线一个 Next.js SaaS，愿意接受 Vercel 运行时的约束，用户群体主要在北美和欧盟，以及你更看重社区规模而非边缘覆盖。ShipFast 拥有更大的社区（截至上次查询 35k+ stars）、更长的维护历史（2023 年起），以及最丰富的可直接引入的第三方集成。
选择 TanStack Ship 如果：你关注 50ms 以下的冷启动，想要资产零出口费用，需要部署到 300+ 个边缘节点，想要无 server-only 边界的类型安全路由，或者希望启动包能在 Cloudflare、Vercel 和 Netlify 之间迁移而不需要重写。TanStack Ship 更年轻（2025 年），社区较小（约 3k stars），但运行在 TanStack Start 和 Cloudflare Workers 上——这个运行时组合带来了不同的性能特征。
两者都是合法选择。错误的选择是用错误的原因选了其中一个。本文其余内容是测量数据和决策树。
我如何对两者进行基准测试
基准测试是一个 5 路由 SaaS 规范：营销落地页、注册路由、Stripe 结账路由、UTM 追踪的博客索引页，以及一个产品详情页。同样的 SaaS、同样的功能集、同样的数据库逻辑结构（ShipFast 用 Postgres，TanStack Ship 用 D1——引擎不同但逻辑表相同）。同样的负载配置：峰值 200 req/s、持续 30 req/s，来自北美、欧盟和亚太 8 个区域的合成流量。两者均通过各自的一键部署按钮部署到生产环境。
以下数字是 8 天内在边缘节点测量的 p50/p95 分位数。冷启动数字是通过在 UTC 04:00 销毁部署实例，并计时容器重启后第一个请求来测量的。TTFB 数字是在稳态负载下测量的。出口费用来自 Vercel / Cloudflare 计费面板。
我没有测量的维度
有两个维度我没有做基准测试：长期可维护性和招聘成本。两者都取决于团队熟悉度，无法在 8 天内测量。社区规模数字（35k vs 3k stars）是「在 Stack Overflow 上找到答案有多容易」的代理指标，但两者并不等同。将它们视为方向性参考，而非确定性结论。
技术栈对比：TanStack Start vs Next.js，Cloudflare vs Vercel
ShipFast 运行在 Next.js 15 + Vercel 上。运行时包括：SSR/RSC 用的 Vercel serverless functions、状态管理用的 Vercel KV、关系数据用的 Vercel Postgres、对象存储用的 Vercel Blob。部署目标是 Vercel 的网络——据上次统计为 18 个区域。
TanStack Ship 运行在 TanStack Start + Cloudflare Workers 上。运行时包括：请求处理器用的 Cloudflare Workers（V8 isolates，无 Node.js 容器）、SQLite 用的 Cloudflare D1、对象存储用的 Cloudflare R2（零出口费用）、缓存用的 Cloudflare KV。部署目标是 Cloudflare 的网络——300+ 个城市。
两个技术栈有三个共同点：全面使用 TypeScript、在同一文件树下使用 server functions 和 UI，以及 SSR 默认路由。五个不同点：路由框架（TanStack Router vs Next.js App Router）、运行时（V8 isolates vs Node.js 容器）、数据层（D1 vs Postgres）、资产层（R2 vs Blob）、网络覆盖（300+ 城市 vs 18 区域）。
后文中，简写约定：TS = TanStack Ship，SF = ShipFast。
功能矩阵：Auth、Billing、UTM、i18n、Admin、AI Tooling
两个启动包都交付了相同的六个业务模块。实现在运行时和类库选择上有所不同，但用户可见的功能集是可比的。
Module | ShipFast | TanStack Ship
------------- | --------------------------------- | ------------------------------------
Auth | NextAuth + Postgres adapter | Better Auth + D1 adapter
Billing | Stripe + Vercel KV webhook queue | Stripe + Cloudflare Queue consumer
UTM tracking | Vercel KV + middleware | D1 + middleware
i18n | next-intl | Paraglide JS + inlang
Admin panel | React Admin + Vercel Postgres | Custom + D1 (single-file CRUD)
AI tooling | Hand-written CLAUDE.md | 14 packaged Agent Skills
有一个看起来不起眼但实际上很关键的行：AI tooling。ShipFast 附带一份手写的 CLAUDE.md，描述启动包的结构。TanStack Ship 附带 14 个 Skills——版本化的 markdown 提示，在你运行 npm install 的瞬间自动出现在 Claude Code、Cursor、Windsurf 和 Codex 中。这些 Skills 与它们记录的类库版本同步更新，所以不会过期。CLAUDE.md 方法则可能过时。
性能：冷启动、TTFB、边缘覆盖
8 天基准测试规范是一个 SaaS 落地页 + auth + Stripe 结账 + UTM 追踪博客。同样的模块、同样的路由、同样的负载配置（峰值 200 req/s、持续 30 req/s）。两者均部署到生产环境。
| Metric | ShipFast | TanStack Ship | Delta |
|---|---|---|---|
| Cold start (p95) | 480 ms | 12 ms | 40× faster |
| TTFB landing (p50) | 110 ms | 38 ms | 2.9× faster |
| TTFB checkout (p50) | 220 ms | 75 ms | 2.9× faster |
| TTFB p95 | 410 ms | 140 ms | 2.9× faster |
| Edge locations | 18 | 300+ | 16× wider |
| Bundle size (initial) | 220 KB | 165 KB | 25% smaller |
冷启动数字是最具影响力的。ShipFast 的 480ms 冷启动是每个区域启动 Node.js 容器的成本；TanStack Ship 的 12ms 冷启动是启动 V8 isolate 的成本，而 Cloudflare 几乎在每个 PoP 都已经预热好了。对于流量不规律或区域差异大的应用，冷启动差异就是流畅用户体验和明显延迟之间的差异。
TTFB 优势来自两个因素：更小的包体积（需要传输的更少）和更广的边缘覆盖（网络路径更短）。对于北美 → 欧盟用户，TanStack Ship 的中位往返时间短约 40ms，因为请求直接命中 EU PoP 而不需要中转到美国区域。
注意：这些是我在自身规范上测量的数字。你的规范可能不同——路由复杂度不同、第三方 SDK 不同、数据库区域不同。比率可能保持，但绝对数字应在自己环境上重新测量。
费用：Vercel 出口 vs Cloudflare R2 零出口
出口费用是任何处理媒体文件的启动包的隐性成本驱动因素。ShipFast 的 Vercel Blob 对超出配额的出站流量收费 $0.15/GB。TanStack Ship 的 R2 出口费用为 零；你只为存储付费（$0.015/GB·月）和操作付费（每百万次 Class A 读取 $0.36）。
对于每月服务约 500 GB 用户上传图片的 SaaS，每月费用差距为 $75，持续有利 TanStack Ship，随增长而累加；达到 5 TB/月时为 $750/月。
另一个成本维度是计算资源。Vercel 对 serverless functions 按调用计费，Pro 方案包含前 100 万次调用。Cloudflare Workers 按请求计费，免费方案包含每天前 10 万次请求。对于同样的峰值 200 req/s，两者在各自的 Pro 方案下都在免费配额内。计算成本差异很小；出口成本差异很大。
AI 编辑器支持：各启动包的 Cursor / Claude Code 配置
ShipFast 附带手写的 CLAUDE.md 和 cursor.json，告诉编辑器项目结构。两个文件均由启动包维护者维护，每次发版时更新。
TanStack Ship 附带 14 个打包好的 Agent Skills，位于每个模块的 .claude/skills/<name>/SKILL.md 下。这些 Skills 与它们记录的类库版本同步。当 @tanstack/react-router 发布新版本时，记录它的 Skill 也在同一个 tarball 中交付。
一个实测：让各启动包的编辑器配置来脚手架一个带类型化 loader 和 validateSearch schema 的 TanStack Router 文件。用 ShipFast 的 CLAUDE.md，模型大约 3 步提示后输出一份路由文件，其中 loader 签名需要一次手动修正。用 TanStack Ship 的 router-code-gen Skill，模型一步提示后输出同样文件，无需手动修正。我对两个启动包各运行了 12 次测试；Skill 方式赢 11 场。
输掉的一场是 router-code-gen Skill 的 applies_to 版本范围与已安装的 @tanstack/react-router 版本不匹配，导致 Skill 被静默跳过，模型退回到预训练知识输出了一个类型化程度更低的结果。版本门控在发挥它应有的作用——拒绝给出过时的指导——但这也是用户需要知道去排查的一种失败模式。
决策树：满足___条件选 ShipFast，满足___条件选 TanStack Ship
这不是抛硬币，有明确的标准偏向其中一方。
满足以下任意条件选 ShipFast：
- 你需要最大社区 / 最丰富的第三方集成
- 你的用户集中在北美 + 欧盟
- 你已在使用 Vercel KV / Postgres / Blob
- 你想最快完成首次部署
- 你不担心 Vercel 出口费用
满足以下任意条件选 TanStack Ship：
- 你在意冷启动（流量不规律的 SaaS）
- 你大规模提供用户上传媒体（R2 零出口）
- 你需要 300+ 城市的边缘覆盖
- 你希望在 Cloudflare、Vercel 和 Netlify 之间可迁移
- 你想要无 server-only 边界的类型安全路由
- 你每天使用 Claude Code / Cursor，且重视 Skills 而非 CLAUDE.md
一个不太好归类的常见情况：已有 Next.js 代码库想迁移。如果你已有生产中的 Next.js 代码库，ShipFast 是最小阻力的路径。如果你是全新起步且团队熟悉 TanStack 规范，TanStack Ship 是更长期的押注。从一个迁移到另一个的成本是真实的（路由不同、server functions 不同）但有边界的（两者都是 TypeScript）。
两者都做对的地方
在结尾之前：两个启动包都做对了真实的事情，说出优点比隐藏它们更有用。ShipFast 最强的资产是社区。35k stars 的仓库意味着有人已经回答了你的 Stack Overflow 问题、为你的小众支付处理器写了集成指南、为你不寻常的技术栈准备了 Vercel 部署配方。这种社区知识密度难以复制。ShipFast 还拥有最成熟的 admin panel；React Admin 多年积累的边界情况覆盖非常全面。
TanStack Ship 最强的资产是它的运行时。V8 isolates + Cloudflare 的网络是 2026 年独立开发者可用的最便宜、最快、覆盖最广的部署目标。打包的 Skills 是第二强资产；ShipFast 生态中尚无可比肩的方案。
隐性成本：迁移路径
有一个在任何基准测试中都不会出现、但在扩展时很重要的维度：你被锁定的程度有多深？ShipFast 跑在 Vercel 上，就意味着被锁定在 Vercel 运行时原语上——Vercel KV、Vercel Postgres、Vercel Blob、Vercel Cron。迁移到不同云意味着重写每个适配器。Vercel 是好运行时；锁定才是成本。
TanStack Ship 跑在 Cloudflare 上，被锁定在 Cloudflare 原语上——D1、R2、KV、Queues。原则上同样故事。区别在于 TanStack Ship 的适配器更薄：应用和 D1 之间有 Drizzle ORM，应用和 Stripe 之间有 Stripe SDK，应用和消息目录之间有 Paraglide SDK。将 D1 换成 Neon 或 Turso 只需改 Drizzle 配置，不需要重写代码。将 Vercel KV 换成 Upstash 在 ShipFast 中则不是这样——适配器层级更深。
这是 TanStack Ship 的隐性论点：即便你永远留在 Cloudflare，适配器的薄度意味着你可以换掉任何一个原语而不触碰栈的其余部分。这个属性不会出现在冷启动基准测试中，但会出现在你需要迁移 D1 的那一天——可能是因为特定区域的数据主权要求。
免费克隆 TanStack Ship 启动包，访问 TanStack Ship GitHub org。该启动包以 MIT 协议开源。要了解逐功能对比，参见 TanStack Ship 功能页 和 定价方案。如果你仍在 SaaS 启动包之间犹豫，参见 TanStack Ship vs Supastarter 和 TanStack Ship vs next-forge 的对比。