React 大型应用架构：状态边界比组件数量更重要

React 大型应用架构：状态边界比组件数量更重要

一、复杂度首先来自状态归属不清

React 大型应用的复杂度，往往不是组件数量造成的，而是状态边界不清造成的。一个页面可以有上百个组件，只要数据流清晰，仍然可维护；反过来，十几个组件如果互相读写全局状态，也会很快失控。架构设计应先回答：哪些状态属于服务器，哪些属于页面，哪些属于组件本地。

常见状态可以分为四类：服务器状态、URL 状态、全局 UI 状态和局部交互状态。服务器状态适合交给 React Query、SWR 等工具管理；URL 状态适合表达筛选、分页和路由；全局 UI 状态应尽量少，例如主题、登录态；局部状态留在组件内部即可。不要把所有状态都放进一个全局 store。

二、状态地图：不同状态使用不同工具

flowchart TD
    A[应用状态] --> B[服务器状态]
    A --> C[URL 状态]
    A --> D[全局 UI 状态]
    A --> E[组件局部状态]
    B --> F[缓存与同步]
    C --> G[可分享与回退]
    D --> H[跨页面共享]
    E --> I[内部交互]

组件分层也要服务状态边界。页面组件负责组合数据和布局，业务组件表达业务语义，基础组件只处理通用交互和样式。基础组件不应知道业务接口，业务组件也不应随意操作路由和全局缓存。边界越清楚，测试越容易写。

三、判断函数：先统一团队语言

下面是一个简单的状态归属判断函数，用于团队讨论时统一语言。

function classifyState(state: {
  fromServer?: boolean;
  shareableInUrl?: boolean;
  usedAcrossPages?: boolean;
}) {
  if (state.fromServer) return "server-state";
  if (state.shareableInUrl) return "url-state";
  if (state.usedAcrossPages) return "global-ui-state";
  return "local-state";
}

性能优化也要围绕状态变化。React 重渲染并不一定是问题，问题是无关组件被频繁更新。通过拆分 Context、稳定 props、合理 memo 和把状态下沉到最近共同父级，可以减少无效渲染。但不要过早到处 memo，否则代码会更难读。

四、模块治理：状态边界最终要落到目录和测试

大型应用还需要模块化。按业务域组织目录，而不是按文件类型堆积所有 components、hooks、utils。一个业务模块应包含自己的组件、请求、类型和测试，公共能力再沉淀到共享层。这样团队协作时边界更清楚。

架构评审时可以要求每个模块说明自己的数据入口、缓存策略和对外事件。若一个模块既直接改全局 store，又改 URL，又操作服务端缓存，说明边界已经混乱。把这些规则写进文档和代码评审清单，比后期靠重构救火更稳。

状态边界也影响测试策略。服务器状态可以通过 mock service worker 或测试查询缓存验证，URL 状态要覆盖刷新和分享链接，局部状态重点测交互分支。把所有状态混在一起，测试就会变成又长又脆弱的端到端脚本。清晰边界能让测试更小，也让失败原因更容易定位。

迁移旧项目时，不要一次性重写全局 store。可以先从一个页面拆出服务器状态和 URL 状态，验证收益后再推广。渐进治理比大规模推翻更安全。

生产落地补充：从能跑到可维护

从生产落地角度看，这类方案不能只停留在主流程。更关键的是把输入校验、失败分支、资源上限和回滚路径提前写清楚。主流程通常容易在演示环境里跑通，真正暴露问题的是异常输入、依赖抖动、并发放大和权限边界。一篇技术方案如果没有解释这些约束，读者很难判断它能否放进真实系统。

评估时建议先定义三类指标：正确性指标、稳定性指标和成本指标。正确性指标回答结果是否可信，稳定性指标回答失败时是否可控，成本指标回答持续运行是否划算。三类指标要同时进入验收清单，不能只用平均耗时或单次成功率证明方案有效。

实现层面还需要把观测数据留出来。日志至少包含请求标识、关键参数摘要、耗时、状态和错误类型；指标至少覆盖成功率、超时率、重试次数和队列长度；必要时再补 Trace 关联上下游调用。这样排查问题时不用靠猜，也能区分是代码逻辑、外部依赖还是容量配置导致的故障。

异常路径补充：把失败当成接口契约

下面的补充片段强调一个原则：调用方必须得到稳定、可解释的错误，而不是在超时、空输入或依赖失败时收到模糊结果。代码不追求覆盖所有业务细节，而是展示输入校验、超时控制和错误封装这三个生产系统最容易遗漏的环节。

type GuardedResult<T> = { ok: true; data: T } | { ok: false; error: string };

async function runWithGuard<T>(task: () => Promise<T>, timeoutMs = 3000): Promise<GuardedResult<T>> {
  const controller = new AbortController();
  const timer = setTimeout(() => controller.abort(), timeoutMs);
  try {
    const data = await task();
    return { ok: true, data };
  } catch (error) {
    const message = error instanceof Error ? error.message : "unknown error";
    return { ok: false, error: message };
  } finally {
    clearTimeout(timer);
  }
}

五、总结

React 大型应用架构的关键是状态边界、组件分层和业务模块化。组件多不可怕，真正可怕的是状态归属混乱、数据流不透明和全局依赖失控。