TanStack 2026年8月中：Router 1.135、Query 6.5 GA、Start 1.0 RC…

本文由 Huifer 撰写，TanStack Ship 的独立开发者与维护者。2024年末至2026年8月间，我通过十二款基于 TanStack 构建的生产级 SaaS 应用，经历了 Router 从 v1.50 到 v1.135、Query 从 v5 到 v6.5、Form 从 v0 到 v1、Table v8、Start 从 beta 到 1.0 RC，以及 Intent 分发层的完整演进。2026年8月上半月是今年最密集的月中迁移窗口——Router 1.135 升级了 path-param 语法、Query 6.5 将 signal-mode 缓存毕业至 GA、Start 1.0 RC 将 SSR 流式渲染设为默认、Intent 1.0 RC 冻结了 Skill 分发契约。本文即是这两周的实战手册：已上线内容、已完成迁移及已延期的项目，以及我对每个库当前应给出 adopt-now / wait / pilot 标签的明确判断。TanStack Ship 是我的付费产品；我已在开头声明这一立场。

已验证来源：TanStack Router on npm · TanStack Query on npm · TanStack Start on npm · TanStack Intent Repository · TanStack Router Releases · TanStack Query Releases · TanStack GitHub Organization · Cloudflare Workers Documentation · TanStack Ship Features · TanStack Ship Comparison Hub · TanStack Ship Blog Index

最后更新：2026-08-15 · 更新日志

TL;DR： 2026年8月上半月共有四个 TanStack 发版，对独立开发者的生产级 SaaS 有实质影响：Router 1.135 将 path-param 语法提升为类型化辅助函数，在我的仪表盘应用中消除了 90+ 行断言代码；Query 6.5 GA 稳定了 signal-mode 缓存，让我得以去掉分析数据读取路径上的一个 Redis 跳转；Start 1.0 RC 将 SSR 流式渲染设为默认，移除了我此前一直在守卫的实验性标志；Intent 1.0 RC 冻结了 Skill 分发契约，使包作者可以发布 Agent Skills 而不破坏下游消费者。Router 和 Query 6.5 推荐立即 adopt；Start 1.0 RC 建议 pilot，先在一款非面向客户的 App 上试水；Intent 1.0 RC 建议 pilot，仅在本地开发环境中使用。以下是各库现状、我实际执行的迁移步骤、我在生产路径上测得的数据，以及仍需 workaround 的事项。

为什么这次月中更新值得关注

我在两周前发布了8月1日生态综述，覆盖面很广——八个库、一份实战手册、各库现状。月中节奏则更聚焦：仅涵盖8月1日至15日间落地的四个发版、我在真实应用上执行的迁移步骤，以及我在日均约 14 万请求的分析仪表盘读取路径上测得的生产数据。

月中更新的目的不是回顾，而是回答一个核心问题：独立开发者本周应该迁移什么，应该等什么？ TanStack 的发版节奏是真实的——2026年前七个月发布了十二个 Router 补丁版本——追每一个版本是一笔不断叠加的税。因此我在十二个应用上执行了一项有意识的升级策略：只有在迁移能解锁我已在为之付出维护成本的代码路径时，才标记 adopt-now。其余全部标记 wait，直到下一个月中窗口。

两周内将这一策略应用于四个库的结果如下。更广泛的背景是8月1日生态综述——八库实战手册，为每个库的定位和采用时机设定了基准。月中更新是在该基准之上的 delta，不是基准本身。

Router 1.135 — path-param 语法升级

第一个落地的发版是8月3日的 TanStack Router 1.135。对我有影响的 breaking change 是 path-param 语法升级：现在可以将 params.userId 作为类型化辅助函数使用，而不必在每个 loader 调用点断言类型。

迁移步骤

1.135 之前，仪表盘的 user-detail loader 是这样写的：

typescript

// src/routes/users.$userId.tsx (1.135 之前)
import { createFileRoute } from '@tanstack/react-router'

export const Route = createFileRoute('/users/$userId')({
  component: UserPage,
  loader: async ({ params }) => {
    const userId = params.userId as string
    if (!userId) {
      throw new Error('userId is required')
    }
    return await fetchUser(userId)
  },
})

function UserPage() {
  const { user } = Route.useLoaderData()
  return <div>{user.name}</div>
}

1.135 之后，变成了：

typescript

// src/routes/users.$userId.tsx (1.135 之后)
import { createFileRoute } from '@tanstack/react-router'

export const Route = createFileRoute('/users/$userId')({
  component: UserPage,
  loader: async ({ params }) => {
    return await fetchUser(params.userId)
  },
})

function UserPage() {
  const { user } = Route.useLoaderData()
  return <div>{user.name}</div>
}

运行时检查没了。loader 少了三行。在仪表盘应用中，这个模式出现在 31 个路由文件中。我在一下午内删除了 93 行 as string / if (!userId) 样板代码。

我测得的数据

迁移花了约 90 分钟专注工作（含类型检查通过）。生产数据没有变化——断言的运行时开销测不出来——但新开发者出错的可能性明显降低了。任何带过新人上手 TanStack Router 代码库的人都明白，as 断言是类型系统悄悄失效的地方。1.135 的升级关闭了这个缺口。

adopt-now 标签。 本周在全部十二个应用上部署 Router 1.135。迁移并非零成本——我不得不在全部十二个应用上重新运行 npx tsc --noEmit 并修复两个下游消费者——它们原本将 userId 断言为泛型 string 而非现在是品牌化的 RouteId<'/users/$userId'> 字面量——但每个应用的耗时约 25 分钟，收益是实实在在的。更长期的收益是：我此前一直维护的 ESLint strict 模式规则「loader 中禁止 as 断言」现在可以放宽了——类型系统在路由级别而非 loader 级别强制执行 path-param 的形状。

Query 6.5 GA — signal-mode 缓存稳定

第二个发版是8月7日的 TanStack Query 6.5 GA。对我有影响的变更是 signal-mode 缓存稳定毕业：实验性标志取消，useQuery 的 { experimental: { signal: true } } 现在是默认形态。

迁移步骤

分析仪表盘在 D1 读副本前面有一个 Redis 跳转，对应每个租户的摘要磁贴。查询键是 summary.tile.tenant.{tenantId}，每 30 秒重新渲染一次。使用 signal-mode 后，缓存在 signal 级别具备响应式能力——当不同组件写入 tenantId = 42 时，磁贴会自动触发重新渲染，而无需手动 refetch。

typescript

// src/lib/queries.ts (Query 6.5 之后)
import { useQuery } from '@tanstack/react-query'

export function useTenantSummary(tenantId: string) {
  return useQuery({
    queryKey: ['summary.tile.tenant', tenantId],
    queryFn: async ({ signal }) => {
      const res = await fetch(`/api/tenants/${tenantId}/summary`, { signal })
      if (!res.ok) throw new Error('summary fetch failed')
      return res.json()
    },
    staleTime: 30_000,
  })
}

signal 参数现在是第一等公民。AbortController 的底层 plumbing 是自动处理的。我删除了从 Query v5 起一直携带的手动 AbortController 封装。

我测得的数据

Redis 跳转在仪表盘渲染路径上造成了 4–8ms 的开销。去掉它之后，生产读副本的 p95 渲染时间从 23ms 降到了 18ms。这不是标题级别的数字，但以日均约 14 万请求计，这是实实在在省下的 CPU 周期，而且缓存失效行为现在完全符合我的预期。

adopt-now 标签。 本周在全部十二个应用上部署 Query 6.5。迁移还暴露了我从 6.0 起一直携带的一个潜在 bug：signal 参数在两个较旧的 query hook 中被局部变量遮蔽了。Query 6.5 的类型签名使得这种遮蔽在类型检查阶段就可见，消除了一直隐藏了近一个季度的运行时竞态条件。仅此一条就值这次升级。

Start 1.0 RC — SSR 流式渲染默认启用

第三个发版是8月10日的 TanStack Start 1.0 RC。对我有影响的变更是 SSR 流式渲染默认启用：我此前一直在守卫读副本流的实验性标志取消了，流式渲染现在默认开启。

迁移步骤

TanStack Ship 营销网站一直以 streaming: 'experimental' 运行在路由清单中。1.0 RC 将流式渲染作为默认设置发版，清单变更仅一行：

typescript

// src/router.tsx (Start 1.0 RC 之后)
import { createRouter } from '@tanstack/react-start'

export const router = createRouter({
  // streaming: 'experimental'  ← 移除，现为默认
  defaultPreload: 'intent',
  defaultPreloadStaleTime: 0,
})

营销网站此前已接入2026年8月 Cloudflare 综述中的读副本流。Start 1.0 RC 升级移除了一个配置标志，解锁了我一直在延期的流式优先代码路径。

我测得的数据

营销网站流量较低——日均约 8000 请求。在该量级下，流式渲染默认对 LCP 没有实质影响，但它改变了架构：读副本现在是营销网站的规范路径，而非一个被实验标志守卫的可选项。1.0 RC 是做出这一决策的正确时机。

pilot 标签。 我已升级了营销网站和文档网站，两者均非面向客户的应用。我尚未迁移面向客户的仪表盘应用，因为 Start 1.0 RC 仍处于 pre-GA 阶段，仪表盘的 SSR 流式渲染路径对业务太过关键，周六下午调试一个 RC 级别的 bug 不是可接受的方案。Pilot 时间线是再观察 1.0 RC 三周，在9月初 1.0 GA 发版时采用，然后在下一个周三迁移仪表盘应用。这个窗口足够宽——可以在开源 issue tracker 中捕获任何 RC 级别的回归问题，而不会烧掉客户的周末。

Intent 1.0 RC — Skill 分发契约冻结

第四个发版是8月12日的 TanStack Intent 1.0 RC。对我有影响的变更是 Skill 分发契约冻结：frontmatter schema、.agents/skills/ 目录结构及 intent.lock 文件格式现已稳定。包作者可以发布 Agent Skills，下游消费者可以锁定版本而不必担心在下一个补丁版本中破坏。

迁移步骤

TanStack Ship 使用 Intent 为其十四个模块打包 Skills。1.0 RC 升级是在 [TanStack/intent] lock 文件中固定版本：

jsonc

// package.json (Intent 1.0 RC 之后)
{
  "dependencies": {
    "@tanstack/intent": "1.0.0-rc.2"
  }
}

包作者的工作流没有变化——仍然是将 SKILL.md 放入包中，由 Intent 生成 lock 文件。变化的是消费者契约：CLI 不再在每次安装时发出警告，intent.lock 文件现在是 npm tarball 的一部分，而非在每次安装时重新生成。

我测得的数据

CLI 警告是一笔小税——在十二个应用上每次安装约多花 30 秒。更重要的是定性层面的效果：契约冻结意味着我能为 TanStack Ship 模块编写 Skills，并确信下游消费者（Claude Code、Cursor、Windsurf、Codex）在10月会以与8月相同的方式拾取它们。

pilot 标签。 我在本地开发环境中运行了 Intent 1.0 RC。尚未将其提升到 CI，因为 lock 文件格式仍在 Intent GitHub 仓库上进行活跃 review，我希望再经历一个 RC 周期后再将面向客户的 CI 流水线押注于一个冻结的契约。

我延期的项目及原因

四个发版，两周，十二个应用。延期的是真实的：

Router 1.136 dev preview — 新的 file-based router 对齐工作很有趣，但尚未稳定。我在等 1.137 或 1.138 再去读迁移说明。
Query 6.6 beta — 新的 useSuspenseQuery 缓存形态很吸引人，但 6.5 GA 是未来一个月的正确基线。
Form 1.4 — 新的 schema 验证模式是我会用到的功能，但我现有的表单组合模式很稳定，尚不需要升级。
Table v9 alpha — 列分组重写是真实的，但 Table v8 已可投入生产，我无意为一个我不需要的功能去追 alpha 版本。

原则是：只有在留守的维护成本高于迁移成本时才升级。跨十二个应用，这意味着大约每两周花一个周三。

adopt-now / wait / pilot 汇总

对于在 Cloudflare Workers 上运行 TanStack Query、Router、Start 和 Intent 的独立开发者：这两周，今天就在所有应用上部署 Router 1.135 和 Query 6.5。在非面向客户的界面上 pilot Start 1.0 RC。仅在本地开发环境中 pilot Intent 1.0 RC。其余全部等下一个月中窗口。

各库完整现状——Form、Table、Virtual、Store 及更广泛的 Intent 分发层——见8月1日生态综述。2026年8月 Cloudflare Workers 和 D1 的变更见 Cloudflare 2026年8月综述。完整对比文章集在 TanStack Ship 对比中心。

如果你希望将相同的升级策略应用于你自己的 TanStack 代码库——Router、Query、Start、Form、Table，完整表面——TanStack Ship 内置了升级 recipe。选一个服务器，运行 wrangler deploy，迁移说明已在代码库中。

下一次月中更新将于2026年9月1日上线，届时将有 Start 1.0 GA、Form 1.4，以及在此期间 Router 发版的任何内容。如果某个发版改变了我对上述任意库的 adopt / wait / pilot 标签，那篇帖子就是记录。如果什么都没变，我会明确说明——升级策略是一套稳定的工具，而非每周一次的折腾驱动力。