React的“遗忘”与“回归”：重新审视Hooks之外的架构思维
一个被忽略的问题：React的核心竞争力到底是什么？
在过去的十年里，React从一个简单的视图库演变为一个庞大的前端生态系统。
从Flux到Redux，从MobX到Zustand，从useEffect到SWR，每一代工具都在试图解决同一个问题：数据如何与界面协同变化。
然而，我们如此聚焦于“怎么使用工具”，却常常忘记“为什么要出现这些工具”。
当Hooks被引入时，我们以为它是一次革命，但事实上它只是把React真正落到了数据流的本质上。
本文的观点是：React的进化史，实际上是一次对“数据边界”的重新发现。
所谓数据边界，是指应用中的数据从哪里来、到哪里去、在哪里被缓存、在哪里被突变。
Hooks让我们有了更细粒度的数据访问能力，但同时也让数据流变得碎片化。
这种碎片化并不意味着不好，而是要求我们在更高维度上重新设计架构，而不仅仅是选择哪个状态管理库。
状态管理的三重境界：对比Redux、Context与Zustand
让我们做一个思想实验：假设你正在构建一个中等复杂度的电商应用。
采用Redux，你会获得可预测的时间旅行调试，但代价是大量的模板代码和集中的全局状态。
采用Context+useReducer，你可以模拟类似Redux的模式，但性能优化成为你的新敌人——每一次对Context的值修改，都会引发所有消费组件的重新渲染。
采用Zustand，你获得了极简的API和灵活的选择器，却不得不自己维护状态之间的因果关系。
这三者并不是一条线性的替代关系，而是三种完全不同的“数据边界”划分方式。
Redux把边界划分在“Action”与“Reducer”之间，Context把边界划分在“Provider”与“Consumer”之间，Zustand把边界划分在“状态切片”与“组件订阅”之间。
真正的高手不会执着于哪一种库更“正确”，而是会问你当前应用的“变更频率”和“共享范围”到底在哪里。
在我看来，Hooks时代的终极答案不是抛弃全局状态，而是重新理解“局部性”。
如果一个状态只影响一个子树，那么使用Context是天然的选择；如果一个状态会被多个无关组件修改，那么Redux仍然是银弹；如果你追求无与伦比的开发体验，Zustand的创造力不可小觑。
但更重要的，是你是否意识到每一种选择都在悄悄改变你的数据边界，进而影响整个应用的韧性。
数据获取的范式之争：useEffect、SWR与Server Components
当人们还在讨论状态管理时，异步数据获取已经悄悄成为前端架构的重心。
传统的useEffect+fetch写法，让“请求生命周期”完全由组件的挂载和卸载支配。
这种方式的问题在于，它把数据获取视为一种副作用，要求开发者手动处理竞态、缓存、重试和取消。
而SWR与React Query的崛起，则把数据获取从一种副作用提升为一种“声明式资源”。
它们将数据当作一种可缓存的远程状态，并通过key和staleTime来定义数据的边界。
这一转变看似优雅，实则埋下了另一个隐患：客户端缓存让数据与服务器的真实状态变得更加分离。
于是，React 19引入的Server Components成为了真正的范式重生。
它允许我们在服务器上直接获取数据，并将无状态的UI片段流式发送给客户端，彻底绕开了那个“先加载再请求”的死胡同。
这不是简单的性能优化，而是对数据边界的一次重新划定——把“属于服务器的数据”留在服务器，把“属于交互的状态”留在客户端。
我的独立观点是：Server Components并不应该被视为“替代SWR”，而是将数据的“所有权”重新交还给拥有数据的地方。
在传统的SPA里，我们假装所有数据都是客户端的私有财产；现在，我们终于承认，有些数据天生就属于服务器。
这种“承认”才是React架构演进中最值得学习的地方。
而SWR这样的库，更适合那些必须依赖客户端实时更新的数据场景，比如聊天消息、协作编辑或临时表单状态。
从SSR到流式渲染：交还控制权与拥抱异步
React的渲染架构同样经历了一次漫长的回归。
初代React采用纯客户端渲染，整个页面由JavaScript在浏览器中组装。
后来我们为了SEO和首屏速度，引入了服务端渲染（SSR）。
但传统SSR有一个致命缺陷：必须等到服务器上所有组件数据都准备好，才能输出一整个HTML字符串。
这个“全有或全无”的模型，让用户体验在慢网络下几乎不可用。
Next.js的Suspense和流式SSR改变了这一点。
它们允许你为一个页面设置多个“数据边界”，每个边界独立等待自己的数据，然后以流式的方式将已经完成的部分发送给浏览器。
这就像是把一个大水管拆成多个小水管，每根都可以独立供水。
React的新架构（包括Concurrent Features）进一步强化了这个理念：渲染不再是同步的、原子的，而是可中断、可优先级的。
这种变化背后的本质，是对“时间”的重新掌控。
在旧的渲染模型里，我们用一个巨大的同步块来对抗网络延迟；而在新的模型里，React学会了让最小粒度的组件按照自己的节奏“苏醒”。
这要求开发者放弃“页面整体加载完成”的思维，转而接受“多个边界并行涌现”的体验。
这种信念的转变，比任何框架API的升级都更加困难，也更有价值。
结语：跳出工具，寻找不变的东西
我们花费了太多精力在争论“React Query vs SWR”或“Redux vs Zustand”，却很少退一步问：为什么这些模式会涌现？
因为数据边界、渲染边界、异步边界正从隐式变为显式。
而React的发展方向始终在揭示一个真理：前端架构的真正挑战不在于工具的复杂度，而在于如何划分边界。
所以，让我给你一个看似反直觉的结论：不要在React版本升级里寻找真理，而是在你所面临的业务场景里，识别出哪些数据属于服务器、哪些属于客户端、哪些属于本地状态。
当你把这三类数据边界画清楚，你自然知道该选什么工具。
这种“不依赖框架”的架构能力，才是React教会我们最深刻的一课。
未来的前端会越来越异步，越来越分散。
但只要我们掌握边界思维，就依然可以在混沌中建立秩序。