Appearance
React
React 这一部分不再继续写成一篇“大单页”,而是拆成几块更容易消化的内容:
- JSX、元素、组件和单向数据流
- state、props、组件通信与状态提升
- 渲染、调和、diff、Fiber 与更新过程
- Hooks 基础与副作用管理
- Hooks 进阶与性能优化
react-dom、react-dom/client、react-dom/server- Redux 为什么出现、适合什么场景
- React Router 为什么是应用结构的一部分
可以记成:React 不是一组零散 Hook,而是一套围绕 组件 -> 状态 -> 渲染 -> 调度 -> 生态 组织前端应用的框架体系。
1. 这一部分会怎么拆
当前 React 目录先按下面 14 部分展开:
- 当前这篇目录页,负责建立 React 知识地图和阅读顺序
- JSX、组件与单向数据流
- state、props、组件通信与状态管理边界
- React 渲染、diff、Fiber 与更新过程
- Hooks 基础:state、effect、ref、context
- Hooks 进阶:memo、callback、reducer 与并发能力
- react-dom、react-dom/client 与 react-dom/server
- Redux:状态管理模型、数据流与工程实践
- React Router:前端路由、嵌套路由与导航守卫思路
- React 源码总览:包结构、运行链路与阅读顺序
- ReactElement、JSX 与 createElement 源码主线
- Fiber 数据结构与 render/commit 源码主线
- Hooks 源码:useState、useEffect 与 Hook 链表
- react-dom、scheduler 与更新调度源码主线
2. 一条更适合理解 React 的主线
如果想系统一点地学 React,更适合按下面顺序理解:
- 先理解 React 为什么要用组件和声明式 UI 组织页面
- 再理解 JSX 为什么能写在 JavaScript 里
- 再分清
props、state、单向数据流和组件通信 - 然后理解 React 的渲染、调和、diff 和 Fiber
- 再理解 Hooks 为什么出现,以及副作用为什么经常出问题
- 最后理解
react-dom、Redux、React Router 这些生态能力如何接进真实项目
React 这条线真正想回答的,不是“某个 Hook 怎么背”,而是:
- 页面为什么要拆成组件
- 状态变化为什么会驱动视图更新
- 渲染为什么不是“直接改 DOM”
key、diff、Fiber 到底各自解决什么问题- Hooks 为什么能让函数组件承担原本类组件的一大部分职责
- 路由、状态管理、客户端渲染和服务端渲染为什么会成为独立主线
- Element、Fiber、Hooks、scheduler 在源码层各自落在哪
3. 一张总图先建立认知
mermaid
flowchart TD
A[React 应用] --> B[组件模型]
A --> C[状态与数据流]
A --> D[渲染与调和]
A --> E[Hooks]
A --> F[生态]
B --> B1[JSX]
B --> B2[函数组件]
B --> B3[组合优于继承]
C --> C1[props]
C --> C2[state]
C --> C3[Context]
D --> D1[React Element]
D --> D2[Virtual DOM]
D --> D3[Diff]
D --> D4[Fiber]
E --> E1[基础 Hooks]
E --> E2[副作用管理]
E --> E3[性能优化 Hooks]
F --> F1[react-dom]
F --> F2[Redux]
F --> F3[React Router]这张图最重要的作用,是把几件容易混在一起的事情拆开:
- React 本体在做什么
props / state / Context解决的是哪一层问题- 渲染、diff、Fiber 为什么是原理主线
- Hooks 为什么不是“额外 API”,而是现代 React 的组织方式
react-dom、Redux、React Router 为什么值得单独理解
4. 当前阶段最该先掌握什么
如果是第一轮建立 React 知识地图,最值得先掌握的是:
- JSX 最终会变成什么
props、state和单向数据流的边界- 为什么不能直接改 state
- React 的
render -> reconcile -> commit主线 key为什么影响状态保留和 diff 效率useState、useEffect、useRef、useContext的职责区别useMemo、useCallback、React.memo为什么不能滥用react-dom/client、react-dom/server在 CSR、SSR、水合里分别做什么- 什么时候该用 Context,什么时候该上 Redux
- React Router 为什么不是“页面跳转工具”,而是应用页面结构的一部分
5. 一张阅读顺序表
| 阅读目标 | 看哪篇 |
|---|---|
| 先建立 React 基本认知 | JSX、组件与单向数据流 |
| 想理清状态和组件通信 | state、props、组件通信与状态管理边界 |
| 想系统理解 React 原理 | React 渲染、diff、Fiber 与更新过程 |
| 想掌握最常见 Hooks | Hooks 基础 |
| 想看性能优化和进阶 Hooks | Hooks 进阶 |
| 想理解 CSR、SSR、水合和 DOM 接管 | react-dom、react-dom/client 与 react-dom/server |
| 想弄清 Redux 适用边界 | Redux |
| 想理清页面切换和路由组织 | React Router |
| 想先建立 React 源码地图 | React 源码总览 |
| 想从 JSX 进入源码 | ReactElement、JSX 与 createElement 源码主线 |
| 想系统看 Fiber 内核 | Fiber 数据结构与 render/commit 源码主线 |
| 想看 Hook 在源码里怎么工作 | Hooks 源码 |
| 想看 root 调度、lane 和 react-dom 落地 | react-dom、scheduler 与更新调度源码主线 |
6. 这部分最容易讲偏的地方
最常见的问题通常不是“完全不会”,而是:
- 只会背
useEffect、useMemo、useCallback - 把 JSX 当模板语法,不知道它和 React Element 的关系
- 只会说“虚拟 DOM 更快”,说不清 React 的 diff 和更新边界
- 把 Redux、React Router 当成附属工具,不知道它们为什么会出现
- 只知道
react-dom,但分不清react-dom/client和react-dom/server - 知道 Hook 名字,却说不清什么时候该用、什么时候不该用
- 说自己会 React 源码,但分不清
react、react-reconciler、react-dom、scheduler
更值得建立的是这套认识:React 负责组件和更新模型,react-dom 负责把 React 树接到浏览器或服务端输出,Redux 负责复杂共享状态治理,而 React Router 负责页面结构与导航。
7. 后续还会继续往哪里扩
这一轮先补的是核心 14 篇。 后续如果继续扩,比较自然的方向包括:
- React 性能优化与渲染排查
- 组件设计模式与复用策略
- React Server Components
- Next.js / Remix 这类框架层实践
- Zustand、Jotai、TanStack Query 等生态对比
8. 小结
当前 React 目录最想建立的核心认识是:
- React 不只是 JSX,而是组件、状态、渲染和调度模型的组合体系
- Hooks 是现代 React 的主线,但 Hooks 仍然建立在渲染模型之上
diff、key、Fiber 不是面试零散点,而是一条连续的更新主线react-dom、Redux、React Router 不是边角料,而是真实项目里的核心生态- React 学到后面,真正重要的是知道能力边界,而不是 API 堆砌
- 如果继续深入源码,最值得先抓的是 Element、Fiber、Hooks、root 调度这四条主线
如果继续往下读,比较自然的顺序是:
- 看 JSX、组件与单向数据流
- 再看 state、props、组件通信与状态管理边界
- 然后进入 React 渲染、diff、Fiber 与更新过程
- 再补 Hooks 基础 和 Hooks 进阶
- 然后看 react-dom、react-dom/client 与 react-dom/server
- 再补 Redux 和 React Router
- 如果要继续看源码,看 React 源码总览
- 然后进入 ReactElement、JSX 与 createElement 源码主线
- 再看 Fiber 数据结构与 render/commit 源码主线
- 再补 Hooks 源码
- 最后看 react-dom、scheduler 与更新调度源码主线