STAGE
基础建立
开篇：用正确的方式学习 React
React 很容易给人一种两极分化的学习体验。刚入门时，好像它只是“函数返回 JSX”；可一旦真正进入项目，就会发现状态流、组件复用、渲染调度、服务端状态、框架协作会一起冒出来。也正因为这样，React 特别容易被学成两种不完整状态：要么只会写一些组件 demo，要么会用很多库，
工欲善其事：Node、包管理器、Vite、调试工具与开发环境准备
很多人学 React 时，会把精力都放在组件和 Hook 上，觉得环境准备只是“装个 Node、拉个脚手架”。可一旦进入真实项目，就会很快发现：版本不统一、包管理器混用、构建链理解不到位、调试工具没接好，都会持续放大后续问题。React 工程真正的第一步，从来不只是把项目跑起来，
React 的核心心智：组件树、单向数据流与声明式渲染
React 真正值得先学会的，不是某个 Hook，而是它背后的三层心智：
JSX、props 与 state：从基础组件到页面交互
很多人第一次接触 React，会把 JSX、props 和 state 看成三块独立知识点：JSX 是语法、props 是传值、state 是状态。可一旦进入真实页面，你会发现这三者其实是一套完整的交互表达链路：JSX 负责把结构写出来，props 负责表达输入边界，state
事件、列表与表单：受控组件、key 与用户输入管理
React 页面一旦开始接用户输入和动态列表，复杂度就会马上上来。很多人会把事件、列表、表单看成三个小主题分别学，但在真实项目里，它们经常同时出现，而且彼此影响：
useEffect、useRef 与副作用管理：避免把 Hook 用成黑盒
React 学习里最容易走偏的一个点，就是把 `useEffect` 和 `useRef` 当成“遇到问题就能兜底的工具”。一旦组件逻辑复杂，很多人会本能地：
useMemo、useCallback 与性能判断：什么时候优化才有意义
React 里最容易被用成“护身符”的两个 API，大概就是 `useMemo` 和 `useCallback`。很多人一看到组件可能重渲，就本能地到处包一层 memo 化，好像这样项目就会更专业、更快。现实往往相反。没有判断基础的优化，通常只会增加阅读成本，未必带来真实收益。
Context 与组件复用：状态提升、组合模式、自定义 Hook
React 项目越往后做，越容易发现真正难的不是单个组件，而是“逻辑怎样复用、状态怎样协作、边界怎样保持稳定”。Context、状态提升、组合模式、自定义 Hook 这些主题经常一起出现，不是巧合，而是因为它们都在回答同一个问题：当组件越来越多时，React 代码怎样继续保持可读
STAGE
渲染与状态协作
渲染与更新机制：Fiber、批处理、调度与 React 为什么这样工作
很多人会写 React，但一旦组件重渲行为开始异常、列表性能变差、某些更新时机让人困惑，就会发现：如果不了解 React 的渲染与调度机制，很多问题只能靠猜。也正因为这样，这一篇特别重要。它不是为了让你炫原理，而是为了让你真正知道 React 为什么这样工作。
路由与页面组织：React Router、布局路由与导航状态
React 项目一旦从局部组件走向真正可导航的应用，路由就不再只是“地址切页面”的技术点，而会成为页面组织、URL 状态、权限控制和布局结构的重要基础设施。很多项目后期变得难维护，并不是因为页面太多，而是因为路由和页面结构从一开始就没有被当成系统骨架来设计。
状态管理选择：Context、Redux、Zustand 与服务端状态的边界
React 讨论状态管理时，最容易一上来就进入“选库模式”，好像答案永远是 Redux、Zustand、Context 三选一。可真正成熟的判断，应该先回到状态本身：它到底属于哪一层、生命周期多长、共享范围多大、是不是来自服务端。只要这个问题没先想清楚，再好的状态库都会被用成杂物
数据获取与缓存：请求、重试、乐观更新与加载错误空状态
React 页面真正开始复杂，往往就是从数据获取开始的。因为一旦页面依赖接口，它就不再只是“渲染一段静态组件树”，而是会同时面对：
样式系统与设计组件：CSS Modules、CSS-in-JS、Tailwind 与组件库
React 项目里样式选择特别容易演变成“技术偏好之争”：有人喜欢 CSS Modules，有人坚持 CSS-in-JS，有人推 Tailwind，有人全站直接上组件库。可真正成熟的判断，从来不是先问哪种方案更潮，而是先看项目要解决什么问题：
TypeScript 与 React 协作：组件类型、事件类型与泛型坑位
React 和 TypeScript 的结合之所以重要，不是因为“写起来更规范”，而是因为一旦项目进入组件复用、复杂 props、事件协作、自定义 Hook 和高频状态流，类型边界会直接影响可维护性。很多 React 项目真正开始稳起来，往往就是从类型边界开始的。
测试与错误处理：RTL、Mock、错误边界与交互回归
很多 React 项目一开始功能推进很快，但一旦页面变多、状态协作变复杂、交互链路变长，没有质量护栏的问题就会迅速放大。测试与错误处理之所以值得放在一起讲，是因为它们本质上都在回答一件事：当代码出问题时，我们能不能及时发现、稳定兜住、快速回归。
React 18 之后的新能力：并发渲染、Suspense、startTransition 与 SSR
React 18 之后，很多人都会接触到几个高频名词：并发渲染、`Suspense`、`startTransition`、更现代的 SSR。可真正难的地方，从来不是 API 本身，而是这些能力背后反映的是 React 对“更新优先级”“等待边界”和“服务端协作”的重新表达。
STAGE
全栈协作与业务场景
Next.js 与全栈协作：路由、数据边界、Server Components 与部署心智
很多 React 项目一旦进入 SSR、SEO、内容站点或更强的全栈协作需求，Next.js 就会自然进入主线。它真正改变的，并不只是“换一个脚手架”，而是让路由、数据获取、服务端边界、部署模型这些原本分散的问题被放进了同一个框架里。
后台系统与复杂业务：表格、表单、权限、图表与上传能力整合
React 在真实业务里非常常见的一类落地场景，就是中后台和复杂业务系统。这里真正难的地方，不在于单个组件会不会写，而在于表格、表单、权限、图表、上传这些高频能力一旦放进同一页面，结构和状态会迅速变复杂。
基于 React + TypeScript 的中后台项目：模块拆分、状态协作与性能治理
讲到这一篇，React 专题已经把基础表达、Hook、副作用、状态、数据获取、样式、类型、测试、并发能力和 Next.js 主线都串了一遍。真正要让这些知识变成项目能力，最好的方式就是把它们放回一个完整的中后台项目里看。因为只有进入真实系统，你才会发现“会写 React 页面”和
漫谈与收束：面试中的 React，以及下一阶段如何继续深入
走到这一篇，真正值得回头看的已经不是某个 Hook 的写法细节，而是你有没有把 React 学成一条完整主线。也就是：
STAGE
进阶与工程实践
React 状态分层：本地状态、Context、URL 状态与服务端状态
React 状态管理最容易被简化成“选哪个库”，但真正应该先回答的，是“状态本身有几类”。按钮 loading、表单输入、主题、登录态、列表缓存、分页参数，这些状态的生命周期、共享范围和协作方式完全不同。如果不先分层，后面无论用 Context、Redux 还是 Zustand，
Redux 与 Zustand：状态建模、异步流与团队协作取舍
如果说上一篇重点在于“哪些状态值得进入共享层”，那么这一篇要回答的就是：一旦确定需要共享状态，Redux 和 Zustand 在真实项目里到底该怎样理解，状态建模应怎么做，异步流怎样组织，团队协作又该怎样权衡。
React 数据获取进阶：缓存失效、乐观更新、分页与错误恢复
数据获取基础篇已经讲了请求、加载、错误和空态，这一篇再往前一步，重点进入那些真正决定系统体验和稳定性的进阶主题：缓存失效、乐观更新、分页协作和错误恢复。它们之所以值得单独讲，是因为这些问题一旦没处理好，项目往往不会立刻完全崩，而是会长期处在一种“不稳定但勉强能用”的状态里。
Suspense 与 Transition 实战：等待边界、并发更新与交互体验设计
React 18 之后，很多人知道 `Suspense` 和 `startTransition` 这些名词，但真正难点不是 API 本身，而是你是否知道“等待”应该出现在哪些边界上、哪些更新必须立刻响应、哪些更新可以稍后完成。它们真正改变的是交互体验设计，而不是单个函数调用。
React 样式与设计系统：主题、组件库与样式方案协作
样式基础篇已经讲过方案选择，这一篇继续往设计系统和项目协作层面深拆。因为 React 项目真正难的，通常不是“这一页怎么写样式”，而是：
React 测试与稳定性：组件测试、错误边界与回归策略
前面的测试篇已经把 React Testing Library、Mock 和错误边界带了一遍，这一篇再往前一步，重点进入稳定性治理视角。因为很多项目不是完全没有测试，而是测试、错误兜底和回归策略没有形成一套真正守风险的体系。结果就是：代码看起来有护栏，真正高风险链路却依然反复回归