2025 年 10 月 7 日，React Compiler 1.0 正式发布。它自动 memo 组件，
useMemo和useCallback大面积退役。很多人的第一反应是：状态管理库是不是也要被编译器"吃掉"了？但 2026 年发生的事恰好相反。React Compiler 解决的是"通知之后"的渲染效率，而状态管理库真正的问题在"通知本身"------一个巨大的 Store 里任何字段变化，所有订阅它的组件都会被唤醒。编译器可以让每个组件的渲染变便宜，但没法阻止它被不必要地唤醒。
2026 年 8 月，TanStack Table V9 的 beta 把这个矛盾摆上了台面：状态从
getState()拆成了 per-slice atoms，行选择变化只重渲染显示计数的组件。状态管理正在从"一个全局 Store"分裂成"一组细粒度的 Atom"。 React Compiler 没有杀死状态库，它把状态库逼到了更底层。
一、先承认 React Compiler 改变了什么
React Compiler 的承诺很清晰：你不再需要手写 memoization 。它在编译阶段分析组件，在它能证明安全的地方自动插入 useMemo、useCallback 和 React.memo 的等价物。
这对状态管理库的影响是直接的。过去 Zustand 用户需要写 useShallow 来避免"解构整个 store 导致每次变化都重渲染"。Jotai 用户选择原子订阅，很大程度上是因为 React 的手动 memo 太容易写错。React Compiler 把"组件内部"的渲染优化自动化了。
但它自动化的边界，恰好停在 Store 的门口。
编译器能保证"这个组件在 props 和 state 没变时不重渲染"。它不能保证"这个组件不会被 Store 的无关字段变化唤醒"。如果一个 Zustand store 同时持有用户信息、主题设置和表格的排序状态，任何字段变化都会通知所有订阅者------编译器只能让被唤醒的组件渲染得更便宜，没法让唤醒不发生。
这就是 2026 年状态管理库正在解决的问题。
二、TanStack Store：把"通知范围"本身变成可组合的
TanStack Store 是这场变化里最值得看的样本。
它是一个框架无关的响应式 store，约 3KB，适配 React、Vue、Solid、Svelte。但它真正的差异化不在体积，而在底层：TanStack Store 使用了 alien-signals 的实现，支持高性能的派生状态（derived state）。
alien-signals 是 Vue 3.6 响应式系统重构背后的那个 1KB 信号库。TanStack Store 把它拿过来，做了一件 Zustand 和 Redux 没有原生提供的事：派生值是 first-class 原语，不需要 selector 或中间件。
javascript
import { Store, Derived } from '@tanstack/store'
const count = new Store(0)
const doubled = new Derived(() => count.state * 2)
// doubled 只在 count 真正变化时重新计算
doubled.mount()Derived 是惰性计算的，只有依赖变化时才重算，而且依赖追踪是自动的------你不需要写依赖数组，也不需要手动声明 selector。
这在状态管理层面意味着什么？"哪些状态变化应该触发哪些派生值"变成了一张显式的依赖图，而不是散落在组件里的 useSelector。 Store 不再是一个巨大的通知广播站，而是一组可以独立订阅、独立计算的节点。
三、TanStack Table V9：把 per-slice atoms 做进了一个真实的大型库
TanStack Store 的设计哲学，在 TanStack Table V9 里得到了最直接的验证。
2026 年 6 月 8 日，TanStack Table V9 beta 发布，8 月 InfoQ 做了详细报道。它最显著的变化有两个。
第一，特性按需注册。 V8 把所有特性打包发布，V9 只注册表格实际使用的部分。一个小表格可以只有约 5KB，完整的企业级网格再按需引入排序、过滤、分页。
第二，状态从 getState() 拆成了 atoms 和 store。 useReactTable 变成了 useTable，状态通过 table.state、table.store 和每个切片的 atoms 流动。
最关键的是 table.Subscribe：
新的
table.Subscribe允许行选择变化只重新渲染显示计数的组件，而不会触及表实例的所有控制项。
这就是"细粒度"在真实场景里的样子。 一个带行选择、排序、过滤、分页的企业表格，勾选一行不应该让整个表格的控制栏、列头、分页器全部重渲染。table.Subscribe 让"行选择"这个切片的变化，只通知真正关心它的那个计数组件。
TanStack Table 的主维护者 Kevin Van Cott 说了一句很关键的话：这个设计直接借鉴自 TanStack Form 与 Store，而且 React Compiler 的稳定迫使他们进行重写------因为在 V8 的模式下已经"开始出现问题"。
React Compiler 没有让状态库变得多余。它让状态库的"粒度不够细"变得不可接受。
四、这对 Zustand、Jotai、Redux 意味着什么？
不是"谁要死了"，而是选型标准变了。
Zustand 仍然是最简单的全局 store。 它的单工厂风格、极低的心智负担，在中小型应用里依然是首选。但 React Compiler 稳定后，Zustand 用户需要重新理解 useShallow 和编译器之间的关系：useShallow 减少的是"通知"，编译器优化的是"通知之后"的渲染。两者不是替代关系，但用错了地方会互相抵消。
Jotai 的原子模型在"细粒度"这个维度上是对的。 2026 年的讨论里，一个反复出现的建议是：选择 Jotai 当且仅当你真正需要它的细粒度原子订阅。React Compiler 让"组件内部"的渲染不再需要手动优化，反而让 Jotai 的原子边界变得更清晰------你用它，是因为你需要在 Store 层面控制通知范围，而不是因为它能帮你省 useMemo。
Redux 的定位正在进一步收窄。 对于独立开发者和小型团队，Redux 在 2026 年的对比中被形容为"过于笨重"。它仍然适合需要严格可预测性、时间旅行调试和超大团队协作的场景，但"默认选 Redux"的时代已经结束了。
五、真正的变化：状态管理正在从"选库"变成"划边界"
把这些放在一起看，2026 年状态管理领域发生的事，不是某个库赢了或输了。
是"状态应该以什么粒度存在"这个问题，第一次有了足够好的工具去回答。
React Compiler 解决了组件内部的渲染浪费。TanStack Store 的 Derived 和 alien-signals 内核，让 Store 层面的依赖追踪变得可组合。TanStack Table V9 的 table.Subscribe 证明了 per-slice atoms 在大型组件里是可行的。
状态管理的核心问题，正在从"用哪个库"变成"这个状态应该属于哪个切片" 。一个全局 store 不是错，错的是把用户信息、主题、表格排序、弹窗开关全部塞进同一个通知广播站。编译器可以让广播的接收者渲染得更便宜，但广播本身的范围，只能由你来划。
六、对前端开发者意味着什么？
第一，不要再把"状态管理"等同于"装一个库"。 状态管理首先是一个边界设计问题：哪些状态是全局的，哪些是局部的，哪些是派生出来的。React Compiler 和 TanStack Store 这类工具，让"边界划得细"变得成本更低，但边界本身仍然需要你来判断。
第二，如果你在用大型表格或表单，关注 per-slice 订阅。 TanStack Table V9 的 table.Subscribe 和 TanStack Form 的字段级订阅，展示的是一种模式：一个复杂组件的状态不应该是一个不可分割的黑盒。行选择、排序、过滤各自独立变化，各自只通知关心它的部分。
第三，React Compiler 不是"不用学状态管理"的理由。 它优化的是"通知之后"的渲染，不是"通知本身"。一个粒度粗的 Store，编译器能让每次唤醒的代价变小，但唤醒的次数不会变。编译器是乘法器，不是减法器------它放大你已有的状态边界设计，好的更好，坏的更坏。
写在最后
2025 年 10 月 7 日，React Compiler 1.0 发布。很多人以为状态管理库要被编译器取代了。
2026 年 8 月，TanStack Table V9 beta 把状态拆成了 per-slice atoms，table.Subscribe 让行选择变化只重渲染计数组件。TanStack Store 用 alien-signals 把派生值变成了 first-class 原语。
React Compiler 没有杀死状态管理库。它把状态管理库逼到了更底层：从"帮组件少渲染"变成了"帮 Store 少广播"。
编译器管的是"收到通知之后"，状态库管的是"谁应该收到通知"。 这两件事，一件正在被自动化，另一件正在变得比以往更重要。
参考链接：
评论区聊聊：你的项目里，状态管理的"通知粒度"够细吗？React Compiler 稳定后，你重新评估过 Zustand 或 Jotai 的用法吗？