TanStack 地图
TanStack 最容易让人误会的一点是：名字都很像，能力边界却不一样。
不少人第一次接触时，会把它理解成“一个很大的前端库合集”。这个说法不算错，但真到项目里不够用。更有用的问题是：我该从哪一块开始用，会不会一上来就把整套体系背上。
先把角色分开
| 组件 | 主要解决什么 | 最常见的使用场景 |
|---|---|---|
TanStack Router | 路由、嵌套路由、URL 状态、Loader、预加载、类型安全导航 | React 应用已经变复杂，React Router 或 Next 的路由层开始不够顺手 |
TanStack Start | 在 Router 之上补齐 SSR、Streaming、Server Functions、Server Routes、部署入口 | 想做 React 全栈，但不想被单一平台深度绑定 |
TanStack Query | 服务端状态获取、缓存、失效、重取、异步状态管理 | 页面数据越来越多，自己写缓存和重试已经开始乱 |
TanStack Form | 表单状态、校验、联动、异步校验 | 表单复杂度高，而且很在意类型和性能 |
TanStack Table | 表格/数据网格逻辑层 | 自定义表格很多，现成 UI 表格组件已经卡手 |
TanStack Virtual | 大列表/大表格虚拟滚动 | 列表、消息流、表格渲染量大 |
TanStack DB | 客户端集合、查询、Live Query、本地同步式数据层 | 想把前端数据访问再往“本地数据库/响应式集合”方向推进 |
它们之间怎么串起来
最常见的演进路径通常长这样：
- 先上
TanStack Query，把服务端状态先管住 - 应用路由开始复杂后，引入
TanStack Router - 当项目需要 SSR、服务端入口、API 路由或者 Server Functions，再考虑
TanStack Start - 表单、表格、长列表复杂度继续上升时，再补
Form / Table / Virtual
也就是说，Start 并不是所有项目的起点。很多团队反而是先和 Query、Router 熟了，再决定要不要走到 Start。
Start 和 Router 的关系
这一点一定要分清：
Router是一套路由系统，本身就能单独用于 SPA，也能自己做 SSRStart是建立在Router上面的 React 全栈框架
官方文档在 TanStack Start Overview 里写得很直白：Start 100% 依赖 TanStack Router 作为路由系统，同时往上补了 full-document SSR、streaming、server functions、server routes、middleware 和 full-stack builds 这些能力。
如果你读 Start 的时候没先理解 Router，很多设计会觉得“为什么要这样”；但如果你先接受它是一套 Router-first 的框架，逻辑就顺了。
一张更实用的选型表
| 你现在最痛的点 | 优先看什么 |
|---|---|
| 页面请求越来越多，缓存和失效开始混乱 | TanStack Query |
| URL 状态、筛选、嵌套路由开始复杂 | TanStack Router |
| 想把 SSR、接口、路由和服务端逻辑收回一个 React 工程 | TanStack Start |
| 表单联动和校验很重 | TanStack Form |
| 表格逻辑复杂，UI 组件已经不够用 | TanStack Table |
| 大列表、大表格渲染扛不住 | TanStack Virtual |
我会怎么建议
如果你是第一次认真看 TanStack，我建议按这个顺序来：
- 先把
Query和Router的价值看明白 - 再判断
Start是不是和你的运行方式匹配 - 最后按业务复杂度决定要不要把
Form / Table / Virtual也纳进来
这样看，脑子里会有层次，不会一上来就把所有新名词挤成一团。