如果你这两年一直在写 React，大概率已经直接或间接用过 TanStack 的东西——可能是 React Query（现在归到该项目下统一叫 Query），可能是 `@tanstack/react-table`。但如果你对它的印象还停留在”一个好用但零散的库集合”，那你可能错过了事情的全貌。
过去两年，TanStack 从一堆各自为战的优质前端库，逐步整合成了一套覆盖数据获取、路由、表单、表格、虚拟滚动、数据库、AI、热键、性能控制的全栈工具链。2026 年 5 月，这套生态不再只是”替代 Redux 的更好方案”——它直接挑战 Next.js 的统治地位，而且走的路线很不一样。
从 React Table 到 React Query
创始人 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、Lit 全都有适配版），标志着 Tanner 不满足于当一个 React 插件作者。
拼图一块块补齐
从 2022 到 2025，TanStack 的生态拼图按一个清晰的节奏陆续补齐。而且每一步解决的都是真实痛点，不是凭空造概念：
– Router（2023）：React 生态里第一个真正全类型安全的路由器。URL 参数、search params 全部从代码里自动推断类型，路由定义就是一个有父子关系的树，设计上比 React Router 严谨不少。同一个库同时支持 React 和 Solid。
– Form（2024）：headless 表单，同样类型安全拉满。异步校验（比如检查用户名是否已被注册）是头等公民，debounce、loading 状态、取消请求都内置好了。比 React Hook Form 那套更类型驱动。
– Table（2024 重写）：前身是 react-table，重写后支持了更多框架。分页、排序、筛选、分组、列固定全部基于 headless 模式实现。
– Virtual（2024）：虚拟滚动。大量列表场景必备，保证 60fps。
– Pacer（2025）：防抖、节流、限频、队列、批处理——性能控制工具。用 lodash 也能做，但 Pacer 类型更安全，所有常见场景都覆盖了。
– DB（2025，Beta）：这算是一个质变的节点。它不再是”管理 API 数据的缓存”，而是一个客户端优先的响应式数据库，支持 live queries、乐观更新、集合级别变更追踪。如果你做过一个需要本地实时同步数据的应用（协作编辑器、股票看板），你会明白这个库解决的是什么问题。
– AI（2025/2026，Alpha）：开源 AI SDK，统一跨多个 provider 的接口。OpenAI、Anthropic、Gemini、Ollama 都能接。跟 Vercel AI SDK 定位不同——它强调框架无关、纯开源、无平台锁定。type-safe tool calling、流式响应、thinking 模型支持，这些都是标准配置。
– HotKeys（2026，Alpha）：类型安全的热键库，支持快捷键序列、组合键录制。做编辑器或 SaaS 工具的人会很喜欢。
– CLI + MCP Server（2026）：CLI 脚手架和 MCP 协议服务器，方便 AI 代理直接跟 TanStack 项目交互。这个设计挺聪明——Tanner 在给”AI 写代码”时代做基础设施，而不是跟风写 wrapper。
– Config（2025）：打包工具链，lint、build、test、version、publish 一条龙。想自己写 npm 包但不打算从头配工具链？开箱即用。
– Intent（2026，Alpha）：Agent Skills 机制——你发布的 npm 包可以附带一份”给 AI 代理看的技能说明书”，AI 能自动发现并调用。这是 Tanner 对”AI 原生开发”的回答。
Start：真正的全栈定音
前面那么多库，说到底还是一个前端生态。真正让 TanStack 从”库集合”升级成”完整生态”的，是 Start 框架。
2025 年底到 2026 年，Start 从 Beta 走到 RC/稳定版本。它的核心定位非常清晰：客户端优先的全栈框架，而不是服务端优先。
这跟 Next.js 的哲学完全是反过来的：
| 对比维度 | Next.js | Start |
|---|---|---|
| 核心架构 | 服务端优先（SSR/SSG/ISR 默认开启） | 客户端优先（SPA 模式默认，SSR 按需开启） |
| 路由 | 文件系统路由，绑定 App Router | 文件路由 + 代码路由双模，基于Router |
| 类型安全 | TypeScript 兼容 | TypeScript 原生，路由/参数/API 全链路类型推断 |
| 数据获取 | Server Components / Server Actions | isomorphic loaders + 内置 Query |
| 构建工具 | Turbopack | Vite + Nitro |
| 服务器函数 | Server Actions（RSC 模型） | server function（显式 RPC） |
| 框架锁定 | Vercel 平台最顺 | 多平台部署（Nitro adapters） |
| SSR 模式 | 全局文档 SSR + RSC | 全文档 SSR + Streaming |
翻译成人话就是：Next.js 默认假定你要一个服务端渲染的网站，在这个基础上加客户端交互。Start 默认假定你要一个客户端单页应用，在这个基础上加 SSR——如果 SEO 有需要的话。
哪个对？看场景。做内容网站（博客、电商、营销页），Next.js 的路由更省事。做数据密集型应用（仪表盘、内部工具、SaaS 后台），Start 的 SPA-first 设计会让你少掉很多头发。而且 TanStack Start 的 SSR 是可选的——你需要的时候再打开，而不是默认开着逼你去关。
2026 年的生态全景
截至 2026 年中，完整的 TanStack 栈长这样：
“`
📊 数据层： Query（API 缓存/同步）
DB（客户端响应式数据库）
Store（跨框架响应式 store）
🗺️ 路由层： Router（类型安全路由）
Start（全栈框架 = Router + SSR + Server Fn）
🎨 UI 层： Table（headless 表格/数据网格）
Form（类型安全表单+校验）
Virtual（虚拟滚动）
HotKeys（热键系统）
⚡ 性能层： Pacer（防抖/节流/限频/批处理）
🤖 AI 层： AI（多 provider AI SDK）
🛠️ 工具层： Config（包发布工具链）
CLI（脚手架/MCP）
Intent（Agent Skills）
DevTools（统一调试面板）
“`
这套栈的核心哲学其实就一句话：每个库解决一个具体问题，不耦合，但天然互补。 你可以只用 Query，也可以 Router + Query + Form 组合，也可以直接上 Start 全套。
对比其他主流技术栈
Start vs Next.js
Start 的核心竞争力是灵活性和类型安全。不同场景下的选择：
✅ 适合用 Start 的场景：SaaS 后台、数据仪表盘、内部工具、需要复杂客户端交互的 SPA
❌ 换个方案更合适的场景：内容型网站、对 SEO 有严格要求的首页、需要 ISR 的大规模静态页面
Query vs 原 React Query
改名前叫 React Query，改名后就是现在的 Query。功能上差不多，但改名后支持了 Vue、Solid、Svelte 甚至 Angular。如果你团队未来可能切换框架，选 Query 比较省心。
vs T3 Stack
T3 Stack（tRPC + Next.js + Prisma + Tailwind）走的也是类型安全路线，但核心是 tRPC——端到端类型安全的 API 调用。它的路线更偏向前端自成体系，不绑定特定后端。两者可以共存（tRPC + Query），但 Start 鼓励你用 server function 代替 tRPC。
这个生态意味着什么
从工程角度看，它做的事情跟 Next.js 本质上不同：Next.js 给了你一套约定，你遵守约定它帮你搞定一切；它给了你一堆积木，你自己决定怎么搭。
这意味着更高的学习曲线，但也意味着更大的自由度。你不需要为了 SEO 强上 RSC，不需要被 Turbopack 牵着走，不需要为了 Server Actions 放弃对客户端交互的控制。
如果你是个独立开发者或者小团队，选 Start + Query + Form 这一套，你能在类型安全的前提下，快速搭出一个不输 Next.js 体验的全栈应用。而且以后如果换了平台（比如从 Vercel 到 Cloudflare），你换的是适配器，不是整个架构。
我该从哪里入门
这个问题的答案取决于你现在在哪：
1. 已经在用 Query：先看看 Router，路由和查询绑定之后体验提升很大
2. 在用 Next.js 但被 RSC 整得头疼：看看 Start，它的 client-first 思路你大概率会更舒服
3. 从零开始新项目：用 Start + Query + Form + Virtual，这套组合覆盖了 90% 的日常开发
4. 在写 npm 包：看看 Config 和 Intent，发布流程和 AI 集成都省了
最后说两句
2026 年了，前端框架之争已经从”哪个性能好”变成了”哪个让你在不妥协的情况下做事更快”。TanStack 的进化路线证明了一件事：一个没有”大厂”支撑的开源生态，只要每个库都解决真问题，整合起来的力量完全可以挑战那些有整个公司撑腰的框架。
—
📖 推荐阅读
这些是跟前端工程师相关的文章，你可能会感兴趣：