过去几年里只要聊到 React话题很快会滑向同一个方向生态太杂了。路由有 React Router、TanStack Router状态管理有 Redux、Zustand、MobX、Jotai、Recoil数据请求有 React Query、SWR表单有 Formik、React Hook Form就连定时器、防抖、滚轮监听这种小功能都能找到对应的 hook 库。一个新人走进去大概率不是被 React 本身难倒而是被“到底该学哪个库”这件事劝退。我见过很多前端学习者花了一周时间把 React 官方文档看完然后打开招聘 JD 一看要求 Redux、React Router、React Query、Next.js马上又陷入新一輪选择焦虑。这其实不是学习能力的问题而是缺少一张“地图”。热搜词里长期躺着 react 面试题、react 面经、react和vue生命周期差异、react router实战这类词也说明大家真正关心的不是某一个 API 叫什么而是整个生态是怎么串起来的。这篇文章想做的就是把 React 主流库按照“它们到底在解决什么问题”来重新梳理一遍。不追求 12 分钟讲完所有库因为这不现实也没有必要。我更想帮你建立一个判断框架什么场景该用什么库单次使用和长期维护要分别考虑什么面试里聊到这些库时真正该讲清楚的点是什么。1. 先想清楚一件事React 生态到底在解决什么问题1.1 表面的问题是工具太多实际的问题是“状态该放哪里”很多人看 React 生态第一反应是库太多、选型难。这个感受是真的但观察还不够深。把所有主流库拉平来看你会发现它们服务的其实是一条主线组件如何描述、数据如何流动、副作用如何处理、跨端如何复用。组件描述JSX、React Component、Hooks 负责这件事。路由React Router 告诉应用“当前 URL 对应哪个界面”。状态管理Redux、Zustand、MobX、Jotai 负责处理“多个组件共享一份数据”。数据请求React Query、SWR 负责处理“服务端数据在客户端的缓存、加载、更新”。表单React Hook Form、Formik 负责处理“用户输入的状态和校验”。跨端React Native 负责把 React 组件跑在 iOS 和 Android 上。看起来功能各不相同但如果追问一层它们都在回答同一个问题一份数据在什么时候应该放到哪个范围里是放在组件内部用useState就够了还是要提升到父组件通过 props 往下传还是要放到组件树之外做成全局状态还是要和服务端保持同步用一个数据请求层来管理这个问题的答案决定了你选什么库、把库放哪一层、什么时候可以不用库。1.2 一个容易误判的点不是所有共享数据都要上状态管理库新手最常见的误解是把“状态管理库”当成“共享数据的唯一方案”。实际上React 本身已经有足够简单的手段useState组件内部状态。useReducer组件内部复杂状态。ContextuseContext跨组件共享不太频繁变化的数据。props父传子的单向数据流。在常见实践里如果共享数据只在少数几个组件之间传递而且变化频率不高用 Context 就够了。很多项目一上来就引入 Redux结果 redux-devtools 里永远只有一两个 action大部分状态还是放在组件内部。判断该不该上状态管理库可以看三个信号状态是否被很多无关组件共享。状态更新逻辑是否复杂到值得单独维护。团队是否需要时间旅行调试或持久化中间件。三个信号都不是强需求时先不引入全局状态管理库通常是一个更稳的选择。先别急着把库里能用的都装上。React 生态的复杂度不是功能不够而是“什么时候不该用某个库”这个判断比用库本身难。1.3 React 真正改变的是思维方式学 React 和学 Vue 有一个非常直观的差异Vue 把很多能力内置在框架里你跟着模板语法走就行React 则更像一块乐高底板它只负责最小内核数据、路由、请求都需要你自己挑零件。这个设计哲学决定了 React 生态的丰富也决定了它的学习曲线不是“学会一个框架”而是“学会一套组合工作流”。所以理解 React 主流库其实是在理解一套组件化设计思路的多种实现方式。一旦想通这条主线再去看 React Router、Zustand、React Query就不会觉得它们是一堆零散工具而是同一套问题的不同切面。2. 路由与状态管理为什么 React Router 是事实标准什么时候不需要全局状态2.1 React Router 不只是一个“页面跳转工具”React Router 是 React 生态里生命力最稳定的库之一。从 React Router 5 到 6API 变化不小但核心思想没有变让 URL 成为应用状态的一部分。React Router 6 以后推荐写法已经和 5 有了明显差异。常见做法是// 声明路由配置 const router createBrowserRouter([ { path: /, element: Home /, }, { path: /user/:id, element: UserDetail /, }, ]); RouterProvider router{router} /这个写法的好处是路由表变成一份可静态分析的数据结构不再只是散落在组件里的Route标签。React Router 真正需要理解的概念是这几个createBrowserRouter创建路由实例。RouterProvider把路由实例注入组件树。loader进入路由前先并行加载数据。action处理表单提交等写操作。useParams、useNavigate、useLocation在组件里读取当前路由信息。如果你在 React Router 实战中用过 v5 的Switch再切到 v6 会觉得清爽很多。v6 不再需要手动排序路由路由匹配规则更接近静态路由表的直觉。2.2 状态管理Redux、Zustand、Jotai 到底怎么选状态管理是 React 生态里讨论最多、也最容易写成长篇对比文档的话题。这里不做纯功能列表只给一个判断框架。Redux 适合的场景团队规模大需要严格约定数据更新方式。状态更新流程复杂需要 middleware、持久化、时间旅行调试。项目已经有成熟的 Redux 工具链。Redux 的问题不是它不好而是它的心智负担和样板代码偏重。在真实项目里如果只用一个全局 store 存几个异步请求结果Redux 的收益其实发挥不出来。Zustand 适合的场景想要全局状态又不想写太多样板代码。希望用 hooks 直接读取 store。项目不大但需要跨组件共享状态。Zustand 的写法直观很多import { create } from zustand; const useCountStore create((set) ({ count: 0, increase: () set((state) ({ count: state.count 1 })), }));Jotai 适合的场景喜欢原子化状态。状态之间有依赖关系希望按需组合。不太想有一个大而全的全局 store。三个库不是对立关系。它们代表的是“状态管理”这个要求的三种粒度Redux 是中央集权Zustand 是省去繁文缛节的状态中心Jotai 是原子粒度。库核心模型适合场景不适合场景Redux单一 storereducer 集中更新大型团队、复杂更新链路小项目、快速原型Zustand轻量 storehooks 读取中大型项目的通用状态需要严格架构约束的团队Jotai原子状态按需派生状态依赖关系强的场景团队习惯集中式状态管理时2.3 最容易被忽略的选择不引入状态管理库一个很容易被忽略的事实是很多“需要状态管理”的场景是组件层级设计得太深导致的。如果一个状态要从最底层子组件传到最顶层再下传给另一边三层以上的 props 钻透会让代码变得很难受。这时候与其立刻引入 Redux不如先检查一下组件树的层级是否合理、是否可以把共享状态抽到一个中间层组件里、是否真的需要全局可访问。从工程经验看正确的顺序通常是先简化组件结构再考虑 Context最后才考虑状态管理库。顺序反了就会用技术手段掩盖设计问题。3. 生命周期到 HooksReact 和 Vue 差异背后的设计逻辑3.1 React 类组件生命周期容易记混本质是没抓住两条线React 面试题里“生命周期”是高频考点React 和 Vue 生命周期的差异更是常客。类组件的生命周期之所以难记是因为 API 看起来很多componentDidMount、componentDidUpdate、componentWillUnmount再加一个getDerivedStateFromProps、shouldComponentUpdate。看一遍能看懂过两天又忘了。我建议用一种更朴素的方式记组件有三个阶段挂载、更新、卸载。每个阶段 React 都会给你几个可选的“插手时机”。Hooks 出现后很多生命周期函数被合并进useEffect的统一模型里。这是 React 设计上的重要转变它不再要求你把“在什么时候做什么”拆成多个方法而是要求你用“这个数据变化后需要发生什么”的视角去想。// 挂载后执行一次 useEffect(() { console.log(mounted); return () { console.log(unmounted); }; }, []);// count 变化后执行 useEffect(() { console.log(count changed:, count); }, [count]);这个模型更符合人的直觉。你不需要去背componentDidMount和componentDidUpdate的区别只需要想清楚一个副作用依赖哪些数据。3.2 React 和 Vue 生命周期差异到底差在哪React 和 Vue 的差异表面上体现在框架 API 上实际差异在两个方面。第一数据流模型不同。React 要求数据不可变状态更新后重新渲染Vue 基于依赖追踪数据变化时精准更新视图。这导致 React 更新粒度通常更大Vue 更细但细也意味着对响应式系统的依赖更复杂。第二生命周期切入的痛点不同。Vue 把created、mounted、beforeUnmount等分成清晰的节点写起来很明确React 则更偏向函数式、声明式把“副作用”统一交给 hooks。面试里如果被问到差异比较好的回答思路是先讲数据流模型再讲生命周期粒度最后落到代码组织方式上。不要只背生命周期对照表那样显得没有真正理解框架。3.3 Hooks 不是新生命周期而是一种新的组织单元很多刚学 Hooks 的人有一个困惑useEffect到底对应哪个生命周期这个问题的答案取决于你怎么写依赖数组。它有弹性可以模拟挂载、更新、卸载也可以完全覆盖不了某个生命周期场景。这不是 bug它是刻意设计。真正熟练使用 React 的标志不是把所有类组件生命周期转译成 hooks而是开始用useEffect的视角组织副作用先声明数据依赖再描述副作用最后考虑清理。这才是 React 想引导你养成的习惯。4. React Native一套代码走多端边界在哪里4.1 React Native 的定位它是 React 生态里的“跨端”分支热搜词里有一组很现实的词react native 启动白屏、react native 运行在 android studio、react native 统计图。这说明 React Native 的讨论早就过了“它能不能用”的阶段大家关心的是“落地时怎么处理实际问题”。React Native 的核心价值不是“写一次到处运行”而是“用 React 的组件模型以接近原生的方式构建移动应用”。它复用了 React 的心智模型但底层渲染不经过 DOM而是通过 JavaScript 引擎和原生端通信把组件映射成原生视图。4.2 启动白屏最常见的问题之一怎么排查React Native 启动白屏在老版本和新版本里都可能遇到原因往往不一样。在常见实践里排查时可以先按下面的链路走看原生端日志。白屏最常见原因是 JS bundle 没有加载成功原生日志会直接告诉你。看 Metro 是否正常运行。开发模式下如果 Metro 断掉或端口被占用页面就无法加载 JS bundle。看 JS 层是否有未捕获异常。React Native 中 JS 报错有两种表现一是红屏开发模式一是白屏release 模式。看入口 render 是否执行。在根组件里加一个临时日志确认 JS 是否真的跑起来。看原生依赖是否匹配版本。RN 版本和原生模块版本不匹配会导致原生层初始化失败。现象优先排查常见原因白屏原生日志JS bundle 加载失败白屏但原生日志正常JS 层异常渲染入口报错白屏只在 release 出现bundle 构建资源路径或 bundle 配置错误白屏只在模拟器出现网络访问Metro 连接问题React Native 出现白屏时不要急着改代码。先确认 JS bundle 有没有加载成功再确认原生层是否已经渲染出容器最后才去查组件问题。排查顺序反了通常只是在瞎试。4.3 React Native 统计图怎么选如果要在 React Native 里做统计图选择维度和 Web 端不一样。Web 端可以选 ECharts、Chart.js、AntV但 RN 环境没有 DOM这些库不能直接用。常见方向有react-native-svg 自己画图适合图表需求固定、不想引入重依赖。react-native-svg-charts基于 SVG简单图表够用。victory-native图表功能完整但包体积偏大。使用 WebView 方案把图表逻辑放在 Web 里适合团队 Web 端已经有一套图表组件的情况。选择建议是如果项目只缺一两个简单图表先试react-native-svg-charts如果图表交互复杂、类型多可以评估 WebView 方案或 Native 图表库。不要一上来就追求“大而全”RN 的包体积和原生依赖成本比 Web 端高很多。4.4 React Native 适合谁、不适合谁适合的场景团队已经熟练使用 React希望复用一部分知识。产品需要同时覆盖 iOS 和 Android但人力有限。业务中 UI 交互复杂但原生能力依赖不深。不适合的场景需要重度使用原生特性比如复杂视频处理、底层传感器、高性能游戏。急需极致原生体验且团队能同时维护两套原生代码。业务单纯是展示型可以考虑普通 Web 套壳不一定非要 RN。React Native 的边界不是“能不能做”而是“团队愿不愿意处理原生层的问题”。长期使用它一定绕不开原生配置、版本兼容、构建工具链这些事。5. 那些 React 面试题本质在考什么5.1 热搜里的面试题逃不出五类问题react 面试题、react 面经、react和vue生命周期差异、react 省市查询组件完整代码这类词长期排在前列。看起来每道题都不一样但归纳起来React 面试其实就在考五类问题。第一类组件基础。如何拆分组件、如何传参、受控组件和非受控组件。第二类生命周期。类组件生命周期、hooks 替代方案、useEffect 依赖数组行为。第三类状态管理。Context、Redux、Zustand组件间通信方案。第四类渲染优化。React.memo、useMemo、useCallback、shouldComponentUpdate为什么有些优化没用。第五类生态应用。React Router 使用、Next.js SSR、React Native 跨端。一旦你把这五个方向拉成一个知识树再看那些散落的面经就不会觉得手忙脚乱。因为你知道每一道题挂在哪棵树上。5.2 面经是路标不是标准答案有些准备面试的人喜欢把面经题背下来。我不是很推荐。原因很简单面试官会追问“为什么”只会背答案撑不过三轮。更好的方式是每看到一道小题就把它放到更大的框架里。比如被问到“React 和 Vue 生命周期差异”不止要记住对应关系还要能说明背后的数据流模型差异被问到“为什么 useEffect 里不能写 async 函数”要从 cleanup 和竞态处理的角度解释而不是背结论。5.3 2026 年面试会盯住什么如果按技术演进趋势推React 相关面试接下来会越来越关注几个方向React 19 的并发渲染和过渡 API。Server Components 对数据请求层的影响。编译优化比如 React Compiler。从 Web 到 React Native、到全栈框架的能力延伸。这类题目不需要你背发布说明而是看你有没有真实项目体感。平时多留意框架更新日志别只看教程标题。6. 沉淀一套 React 库选型判断框架6.1 先跑通再优化最后工程化无论选什么库我建议都按“三步走”的顺序来。第一步最小可用流程。用最少的库、最少的封装把功能跑通。不要一开始就引入一堆抽象层。第二步小样本验证。在真实项目里抽取一个模块用候选库实现。观察的不只是代码能不能运行还包括代码量、团队理解成本、调试难度。第三步工程化接入。确认方案可行后再考虑中间件、持久化、日志、类型、测试、代码规范、团队约定。这个顺序可以避免两个问题一是过早抽象代码还没跑通就开始封装架构二是过度依赖库遇到一个小问题就再引一个新库。6.2 一个小而实用的 React 选型清单把前面讨论的内容收束成一个清单供你在新项目里快速判断。问题判断方向路由需求是否复杂单页应用直接用 React Router需要静态路由、嵌套路由、loader 可以考虑 TanStack Router全局状态是否必要先检查组件分层和 props确认需要再选 Zustand、Redux 或 Jotai服务端数据请求多不多若有大量异步状态直接用 React Query 或 SWR表单是否复杂表单状态多、校验复杂用 React Hook Form需要跨端吗需要原生交互才考虑 React Native不需要的话用 Web 技术栈更轻团队维护能力如何团队小选轻量方案团队大、需要强约束选 Redux 工具链这个清单不是标准答案而是一组提问。真正做决定的人还是要结合团队情况。6.3 长期使用比第一眼惊艳更重要最后想多说一句。React 生态里每个主流库能成为主流基本都有它存在的理由。很多初学者喜欢凭第一眼感受做选择看到 Zustand 短小精悍就决定抛弃 Redux看到 React Query 太方便就决定不再自己封装请求。但真实项目里的体验和第一次 demo 的体验差别很大。一个库能不能长期用取决于几点团队里每个人读代码都能理解。出了问题能在社区找到记录。长时间不更新也依然稳定。它解决的问题在你的业务里确实常见。这才是选型真正的判断标准。不是“这个库看起来高级”而是“这个库在一年后能不能减少我们团队的维护负担”。回到开头那句话React 主流库的复杂性不是要你把每一样都摸透而是要学会判断“当前项目需要什么、不需要什么”。能想清楚这一层你就不需要靠背诵面经或跟热门工具清单来支撑自己的技术判断了。