选择能提升发布速度的初创公司前端技术栈
选择MVP前端技术栈的决策指南：Next.js还是Vite，Tailwind搭配shadcn/ui，TanStack Query加上Zustand，Supabase还是tRPC，以及应避免的技术组合。
处于起步阶段的团队往往会在尚未开发出任何界面之前，就花费数周时间争论Next.js与Remix、Redux与Zustand，或是GraphQL与tRPC之间的优劣。初创公司很少因为框架选择而失败，它们失败的原因是开发速度过慢。本指南为新产品规划了一套实用的前端技术栈，解释了每一层的选型理由，并指出了那些会悄悄降低开发效率的选项，帮助你能在下午之内做出决策并继续推进项目。
技术栈应优化的目标
初创公司的前端开发有三个核心优先级：上市速度、开发者体验以及类型安全。规模扩展目前还不在考虑范围内。你无需在产品发布当天就应对数百万并发用户，只需在资金耗尽之前实现产品与市场的契合。下面列出的每一款工具都是根据这一目标来评估的，那些仅仅为了在简历上显得好看而存在的工具则会被排除在外。
核心框架：两种路径，由产品类型决定
对大多数团队而言，可选方案仅限于使用 App Router 的 Next.js 或通过 Vite 构建的普通 React 单页应用。关键问题在于该产品是否需要让未登录的用户也能快速找到并查看内容。
适用于对 SEO 敏感且面向公众的产品：Next.js App Router
SaaS 营销页面、市场平台以及那些注重搜索可见性、首次加载速度或全栈功能的场景都适合使用 Next.js。它内置了 React Server Components，因此可以在服务器端获取数据，且这些组件不会向浏览器发送任何 JavaScript 代码。将 API 路由和 UI 代码放在同一个仓库中，也能减少小型团队的上下文切换成本。
价格方面存在一定的学习曲线。团队中的每个人都需要明白服务器组件与客户端组件的边界所在，而定位错误是导致混乱错误的常见原因。
用于需要登录才能访问的应用的 Vite 加 React Router
内部控制面板、类似 Figma 或 Canva 那样高度交互的工具，以及需要身份验证才能使用的 B2B 产品，从服务器端渲染中获得的收益甚微。Vite 能实现近乎即时的开发服务器启动，采用更简单轻量的纯单页应用架构，无需处理 SSR 水合过程中的各种问题。如果 SEO 不是重点考虑因素，这种方案通常意味着更少的复杂组件。
样式与用户界面：Tailwind CSS 与 shadcn/ui
庞大的手动编写样式表，以及像 Material UI 或 Bootstrap 这样体积庞大且难以定制的组件库，不适合那些需要每日迭代开发的团队。
使用 Tailwind CSS 进行样式设计
以实用功能为首要考虑的样式设计已成为主流默认方式。生成的 CSS 文件体积小巧，类名不会冲突，且可直接在 JSX 中进行样式设置。初期使用时可能会感觉效率较低，但一旦这些实用功能名称变成条件反射，构建界面就会变得非常快速。
用于组件的 shadcn/ui
shadcn/ui 并非传统意义上的 npm 依赖项。它是一组基于 Radix UI 构建的可访问、可重复使用的组件，可直接复制到你的代码库中。由于你拥有源代码，要修改下拉菜单的动画效果或按钮的内部行为只需简单编辑即可，无需与库的 API 作斗争，而且其默认样式已经十分精致。
相应的代价是你需要自行负责维护：上游的修复不会通过版本升级自动带来，因此只有在确实需要时才应主动拉取更新。
状态与数据获取：将服务器状态与客户端状态分开
将 API 响应存储到全局 Redux 存储中已不再是被推荐的默认做法。更合理的划分方式是将数据放在服务器端，而将状态仅存在于 UI 中。
TanStack Query 用于处理服务器端状态
数据获取、缓存、加载与错误状态处理以及后台重新获取功能都可以通过 TanStack Query（原名 React Query）来解决。它能够处理这些问题，同时省去团队在编写数据获取逻辑时所需的大部分冗余代码。如需具体的结构示例，请参阅我们的指南 关于如何构建 TanStack Query 数据层。
Zustand 用于处理客户端状态
全局 UI 状态，比如侧边栏是否打开或当前使用的是哪种主题，非常适合用 Zustand 来管理。它的体积极小（不到 1 KB），几乎不需要冗余代码，也无需在应用各处添加提供者组件。
规则很简单：如果数据来自数据库，就应放在 TanStack Query 中；如果只是用于描述 UI，那就应放在 Zustand 中。将两者混用正是许多新手代码库中出现状态问题的根源。
后端简化方案：Supabase 或搭配 Drizzle 的 tRPC
初创公司的前端工程师往往也需要负责后端工作，而 UI 与数据库的交互方式会对性能产生很大影响。
没有后端团队时的选择：Supabase
Supabase 是 Firebase 的开源替代品，它提供 Postgres 数据库、自动生成的 REST 和 GraphQL API、实时订阅功能以及身份验证机制。一个可用的后端系统甚至可以在一个下午内搭建完成。需要提前规划数据访问的安全措施，因为对于基于 BaaS 的系统而言，数据库规则就是其 API 的安全模型。
需要自定义后端时的选择：tRPC 和 Drizzle
在搭配自定义后端的 Next.js 中，tRPC 能够无需代码生成步骤即可实现端到端的类型安全 API。只要在服务器端修改架构，客户端就会立即显示出 TypeScript 错误。Drizzle ORM 会在其下方添加一个轻量级且带有类型的数据库层。这种架构要求两端都使用 TypeScript，理想情况下应位于同一个代码库中。那些逐步采用 tRPC 的团队可能会发现我们关于 通过逐步部署 tRPC 捕获 API 合同偏差 的文章很有用。
工具与开发者体验
这一层对用户来说是不可见的，但它决定了代码库是否易于维护：
- 严格模式的 TypeScript。 这是不可或缺的。它能在生产环境之前发现错误，同时也能为新成员提供文档参考。
应避免的组件：哪些不需要加入
快速开发同样取决于你选择不使用什么技术：
- 微前端。虽然它能解决多个独立团队之间的协调问题，但初创公司只需一个团队，应直接构建单一应用或单仓库结构。
- 用于MVP的Redux。除非产品是复杂的、以离线功能为主的协作工具，否则它只会增加你并不需要的繁琐流程。
- 自定义设计系统。花费数周时间设计定制化的按钮样式，就意味着没有时间专注于用户需求。可以先从shadcn/ui开始，根据品牌调整CSS变量，之后再做优化。
速查表
- 框架：面向公开、注重SEO的产品使用Next.js App Router；面向已登录用户的应用则使用Vite搭配React Router。
- 样式处理：Tailwind CSS。
- 组件库：基于Radix UI的shadcn/ui。
- 服务器端状态管理：TanStack Query。
- 客户端状态管理：Zustand。
- 后端服务：没有后端团队时可使用Supabase；需要定制后端则可用tRPC搭配Drizzle。
- 工具规范：严格的TypeScript代码规范以及Biome工具。
- 托管平台：Vercel或Cloudflare Pages。
总结
最理想的技术栈是那种不会妨碍你工作的。像 Next.js、Tailwind、shadcn/ui 和 TanStack Query 这样经过验证的工具不仅能加快代码生成速度，还能为你节省时间，让你有更多精力与用户沟通、迭代功能以及找到产品与市场的契合点。这些选择也并非一成不变：一旦实际使用情况显示出瓶颈所在，就可以更换相应的技术层。做出决定后将其记录下来，把节省下来的时间投入到产品开发中。
相关阅读
- 三种能优化 React 应用架构的 TypeScript 模式 — 了解 Repository、Observer 和 Builder 模式如何利用 TypeScript 的类型系统来打造更简洁、更易维护的 React 和 Next.js 代码库。