核心与渲染层的解耦
执行 npm install react 之后,大多数人会紧跟一条 npm install react-dom,然后再也不会想起这件事。两个包装完,开始写组件,一切理所当然。
/**
* 我不知道的 React
* 共 16 篇文章
*/
export const series = {
name : "我不知道的 React" ,
count : 16 ,
guide : "我不知道的 React — 系列导读与阅读路径" ,
description : "《我不知道的 React》系列导读、阅读路径与文章索引。" ,
};
文章数量: 16 篇
根据不同背景选择入口:
如果想系统学习: 按编号 01 → 16 顺序阅读
如果只关心核心原理: 重点看 01、02、03、04、05
如果在排查性能问题: 重点看 02(Fiber)、03(Diff)、04(Render 触发)、14(React 19 Compiler)
如果想理解 Hooks: 重点看 05、06、07、08
如果关注服务端渲染: 重点看 14、15、16
| # | 文章 | 核心内容 |
|---|---|---|
| 01 | 核心与渲染层的解耦 — React vs ReactDOM | 虚拟 DOM 抽象层,ReactDOM/ReactNative 渲染器分离 |
| 02 | Fiber 架构 — 可中断渲染与优先级调度 | Fiber 节点结构,时间切片,Lane 优先级模型 |
| 03 | 从 JSX 到 DOM — 渲染流程与 Diff 算法 | JSX 编译,协调过程,三条 Diff 策略 |
| 04 | 生命周期演进与 Render 触发机制 | 类组件生命周期,函数组件执行模型,重渲染条件 |
| # | 文章 | 核心内容 |
|---|---|---|
| 05 | useState — 批量更新与 Hook 底层机制 | Hook 链表,批量更新,闭包陷阱 |
| 06 | useEffect 等核心 Hooks 详解 | useEffect 执行时机,useRef/useMemo/useCallback 原理 |
| 07 | 组件通信与自定义 Hooks 实战 | Context、状态提升、自定义 Hook 的设计模式 |
| 08 | 逻辑复用的三代进化 — HOC、Render Props 与 Hooks | 三种模式的原理、优劣与演进关系 |
| # | 文章 | 核心内容 |
|---|---|---|
| 09 | Portals 与事件冒泡的真相 | createPortal 原理,DOM 树 vs React 树的事件传播 |
| 10 | 受控与非受控组件的选择之道 | 数据流差异,性能影响,适用场景 |
| 11 | ErrorBoundary 的工作原理与局限性 | getDerivedStateFromError/componentDidCatch,捕获边界 |
| # | 文章 | 核心内容 |
|---|---|---|
| 12 | Redux 核心原理与中间件机制 | 单向数据流,Reducer 纯函数,中间件洋葱模型,Thunk vs Saga |
| 13 | React Router 原理、模式与实践 | History API,路由匹配,嵌套路由,代码分割 |
| # | 文章 | 核心内容 |
|---|---|---|
| 14 | React 19 核心特性 — Compiler、Actions 与新 Hooks | React Compiler 自动 memoization,Actions API,useOptimistic,use Hook |
| 15 | RSC vs SSR — 服务端渲染范式详解 | RSC Payload vs HTML,水合机制,选择性水合 |
| 16 | 同一应用运行多版本 React | 单例冲突,Module Federation,隔离方案 |
| 关联系列 | 推荐交叉阅读 |
|---|---|
| V8 | 执行流程全览 — 理解 JS 代码如何被 V8 编译和执行 |
| V8 | async/await 实现原理 — useEffect 异步调度的底层 |
| V8 | 垃圾回收 — React 组件卸载与内存泄漏的关联 |
| 浏览器 | 事件循环协调 JS 与渲染 — Fiber 时间切片依赖的底层机制 |
| 浏览器 | 渲染流水线八个步骤 — 虚拟 DOM 最终如何变成像素 |
| HTTP | 从输入 URL 到页面呈现 — SSR/RSC 页面的完整加载链路 |
执行 npm install react 之后,大多数人会紧跟一条 npm install react-dom,然后再也不会想起这件事。两个包装完,开始写组件,一切理所当然。
很多人以为 Fiber 只是 React 16 引入的一种新数据结构,但实际上,它是一整套调度系统——包含数据结构、遍历算法、时间分片机制和优先级模型。React 团队花了两年重写核心引擎,不是为了换个数据结构,而是为了让渲染这件事变得"可商量"。
很多人以为 JSX 就是在 JavaScript 里写 HTML,但实际上浏览器根本不认识 JSX。它既不是合法的 JavaScript,也不是真正的 HTML——它是一层语法糖,需要经过编译才能执行。
React 的类组件生命周期曾经是面试高频题,很多人能背出从 componentWillMount 到 componentWillUnmount 的完整流程。但从 React 16.3 开始,三个 Will* 系列方法被标记为 UNSAFE_,到 React 18 已经不建议使…
几乎每个 React 初学者都会撞上同一个困惑:调了 setCount,紧接着打印 count,发现值没变。于是搜索引擎告诉你——"useState 是异步的"。
上一篇讲了 useState 的批量更新和 Hook 链表机制。但 React 的 Hook 体系远不止状态管理——副作用处理、跨层级通信、性能优化,每一个场景都有对应的 Hook。这些 Hook 单独看都不难,但很多人以为掌握了用法就等于理解了原理,结果在实际项目中踩了各种坑。
React 组件之间要共享数据,方式不止一种。从最常见的 Props 到 Context,再到 Ref 暴露子组件方法,每一种都有各自的适用场景和陷阱。但组件通信只是前半段——当多个组件反复写着相同的状态逻辑时,如何把这些逻辑抽离成可复用的单元,才是 Hooks 体系真正的威力…
React 组件是构建 UI 的基本单元,但组件之间如何共享逻辑,一直是一个棘手的问题。不同于工具函数的纯计算复用,React 要复用的往往是"带状态的逻辑"——比如追踪鼠标位置、监听窗口大小、管理表单校验。这类逻辑和组件的生命周期、状态管理深度绑定,没法简单地抽成一个函数。
React 组件渲染到 DOM 的位置,通常由它在组件树中的位置决定——父组件在哪个 DOM 节点下,子组件就渲染在那个节点内部。这在绝大多数场景下没有问题,但有一类 UI 元素天然需要"跳出"父组件的 DOM 结构:模态框、Toast 提示、Tooltip 浮层。
React 处理表单的方式和原生 HTML 有一个根本性的分歧:表单数据的"真相源"(Source of Truth)在哪里?
React 应用中,一个子组件的渲染错误如果没有被捕获,会导致整棵组件树卸载——也就是白屏。从 React 16 开始,这个行为是刻意设计的:React 团队认为,显示一个损坏的 UI 比完全不显示更危险,因为损坏的 UI 可能导致用户做出错误操作(比如支付页面上金额显示错误)。
很多人对 Redux 的理解停留在"一个全局状态管理工具"的层面——Store 存数据、Action 描述变更、Reducer 算新值。用起来没问题,但要问 dispatch 之后到底经历了什么、中间件为什么是三层柯里化函数、Immutability 为什么不是"建议"而是"硬…
很多人以为 React Router 就是一个"URL 到组件的映射表"——配置好 path 和 component,剩下的它帮你搞定。能用是能用,但要问 为什么不会刷新页面、BrowserRouter 和 HashRouter 到底在监听什么事件、嵌套路由的 是怎么知…
React 19 于 2024 年底正式发布。这个版本带来的变化不是"多了几个新 API"那么简单——它在编译层面、数据交互层面和异步处理层面同时发力,试图从根本上减少 React 开发中最常见的两类样板代码:手动性能优化和手动异步状态管理。
很多人以为 React Server Components(RSC)就是 SSR 的升级版——"以前在服务端渲染 HTML,现在换了个更好的方式"。但实际上,RSC 和 SSR 解决的是完全不同的问题,产出的东西也不一样,它们更像是两个可以叠加使用的独立技术层。
一个前端项目里同时跑两个版本的 React?听起来像是在自找麻烦。但在微前端架构和大型遗留项目中,这种需求真实存在——而且不是"能不能"的问题,是"怎么安全地做到"的问题。