企业官网建设流程全解析

如果你这两年一直在写 React，大概率直接或间接用过 TanStack 的东西——可能是 React Query（现在叫 Query），可能是@tanstack/react-table。

但如果你的印象还停留在「一个好用但零散的库集合」，那你可能错过了事情的全貌。

过去两年，TanStack 从一堆各自为战的优质前端库，演变成了一套覆盖数据获取、路由、表单、表格、虚拟滚动、数据库、AI 的全栈工具链。2026 年，这套生态不再只是「替代 Redux 的更好方案」——它长出了一个叫 Start 的全栈框架，开始跟 Next.js 正面竞争，而且路子完全不同。

从 React Table 到 React Query，再到 Start

创始人 Tanner Linsley 最早做的是 React Table。那时候前端表格组件要么又重又贵（AG Grid 那种），要么功能太弱。他搞了一个完全 headless 的方案——库只管逻辑，不管 UI，表格长什么样你自己定。这个设计哲学后来成了 TanStack 所有库的基因。

2019 年的 React Query 才是真正的转折点。它的核心洞察其实很简单：服务端数据和客户端状态是两回事，不该混在一起管。你定义一个 key，写一个 fetch 函数，Query 自动帮你做缓存、后台刷新、错误处理、乐观更新。在那之前你得在useEffect里手写一堆 loading/error 判断，而且几乎每个组件都得重来。

这个库当年火到什么程度？Redux Toolkit 专门加了个 RTK Query，React Router 6 的 loader 机制也明显受了影响。说 React Query 重新定义了前端跟 API 打交道的姿势，不算夸张。

2021 年项目改名去掉 React 前缀，全面拥抱多框架（Vue、Solid、Svelte、Angular 都有适配版）。这一步表明 Tanner 不满足于只当个 React 插件作者。

2026 年的 TanStack 生态拼图

从 2022 到 2026，TanStack 的生态拼图一个接一个地补齐：

Query（原名 React Query），服务端数据缓存的事实标准，38K+ GitHub stars，周下载量破 300 万。

Router（2023），React 生态里第一个全类型安全的路由器。URL 参数、search params 全部自动推断类型，路由定义是一个有父子关系的树。跟 React Router 的路由配置比，类型方面的差距挺明显的。

Form（2024），headless 表单，类型安全拉满。异步校验是头等公民，debounce、loading 状态、取消请求都内置了。

Table（2024 重写），headless 表格，分页、排序、筛选、分组、列固定全部基于 headless 模式，支持多框架。

Virtual（2024），虚拟滚动，大量列表场景必备，保证 60fps。

Pacer（2025），防抖、节流、限频、队列、批处理——性能控制工具。

DB（2025，Beta），客户端优先的响应式数据库，支持 live queries、乐观更新、集合级别变更追踪。做过协作编辑器或股票看板的话，你会明白它解决的是什么问题。

AI（2025/2026，Alpha），开源 AI SDK，统一多 provider 接口。OpenAI、Anthropic、Gemini、Ollama 都能接。跟 Vercel AI SDK 定位不同——框架无关、纯开源、无平台锁定。

HotKeys（2026，Alpha），类型安全的热键库，支持快捷键序列，做编辑器或 SaaS 工具的人会喜欢。

CLI + MCP Server（2026），CLI 脚手架和 MCP 协议服务器，方便 AI 代理直接跟 TanStack 项目交互。

Intent（2026，Alpha），Agent Skills 机制——你发布的 npm 包可以附带一份「给 AI 代理看的技能说明书」，AI 能自动发现并调用。这是 Tanner 对「AI 原生开发」的回答。

完整栈用一张图看：

📊 数据层： Query + DB + Store 🗺️ 路由层： Router + Start（全栈框架） 🎨 UI 层： Table + Form + Virtual + HotKeys ⚡ 性能层： Pacer 🤖 AI 层： AI SDK 🛠️ 工具层： Config + CLI + Intent

核心哲学：每个库解决一个具体问题，不耦合但天然互补。你可以只用 Query，也可以 Router + Query + Form 组合，也可以直接上 Start 全套。

Start：真正的重头戏

真正让 TanStack 从「库集合」升级成「完整生态」的，是Start框架。

2026 年 3 月 Start v1.0 正式发布。它的核心定位跟 Next.js 正好相反：

翻译成人话：Next.js 默认假设你要一个服务端渲染的网站，在这个基础上加客户端交互。Start 默认假设你要一个客户端单页应用，在这个基础上加 SSR——如果 SEO 有需要的话。

哪个更合理？看场景。做内容网站（博客、电商、营销页），Next.js 省事。做数据密集型应用（仪表盘、内部工具、SaaS 后台），Start 会让你少很多头疼事。

Platformatic 的独立基准测试显示：Start 在 1000 req/s 下延迟 13ms，高于 React Router 的 18ms 和 Next.js。说实话这种数字对普通项目意义不大，但至少说明它的底层性能不拉胯。

有个 Reddit 上的真实迁移案例：Inngest 团队把应用从 Next.js 迁到 Start，页面加载时间从 10-12 秒降到 2-3 秒。一个工程师花了两周。

我该从哪里入门？

分情况：

• 已经在用 Query：先看 Router，路由和查询绑在一起后体验提升很大
• 在用 Next.js 但被 RSC 搞得很烦：看看 Start，它的客户端优先设计会让你松口气
• 还不熟悉任何库：从 Query 开始，它解决的是最普遍的问题

TanStack 做的事跟 Next.js 本质上不同。Next.js 给你一套约定，你遵守约定它帮你搞定一切。TanStack 给了你一堆积木，你自己决定怎么搭。

这意味着更高的学习曲线，但更大的自由度。你不需要为了 SEO 强上 RSC，不需要被 Turbopack 牵着走，不需要为了 Server Actions 放弃对客户端交互的控制。

2026 年了，前端工具链的选择越来越不是「谁更好」的问题，而是「谁更适合你」。TanStack 给「客户端优先」这个阵营提供了一个确实能用的选项。

本文基于 auraimagai.com 完整版文章 TanStack 从零散的库走向完整全栈生态，包含完整的生态全景、Query 入门教程和 Start vs Next.js 的深度对比。