我整理 React 知识点笔记这件事其实源于一次团队内部的技术分享。当时为了让新来的同事能快速上手项目我把日常开发中踩过的坑、用过的套路、琢磨过的原理零零散散记了好几个月最后沉淀成了一份比较系统的笔记。这份笔记不是什么官方文档的翻译更不是面面俱到的教程它更像是一个在一线写了多年 React 的开发者把真正用得上的东西挑出来讲清楚。今天把它整理成文章分享出来适合刚学完 React 基础、准备写实战项目的人也适合写了几年 React 但总觉得自己会而不懂的同行。我会把组件化思维、Hooks 运行机制、状态管理方案选型、性能优化手段这些核心知识点串起来讲每个环节都配上实际项目里验证过的代码片段和选型理由。1. 组件化思维与 JSX 背后的运行逻辑1.1 组件到底在抽象什么很多初学者写 React第一反应是把页面切成一块块的组件这个理解没错但太浅了。我在实际项目里摸索出来的心得是组件抽象的核心不是视觉区块而是**可变区域的边界**。换句话说你要找的是页面上哪些地方会因数据变化而重新渲染这些地方才值得拆成组件。举个例子一个电商商品列表页有搜索框、筛选栏、商品卡片、分页器。如果整个页面是一个巨型组件那么搜索框每次输入一个字符全页所有商品卡片、筛选栏全部重新渲染。拆成组件之后搜索框的状态变化只影响它自己商品列表只在筛选条件真正变化时才重新计算。这里的判断标准不是看起来是不是一块而是它是不是一个独立的数据变化单元。组件拆分的粒度也有讲究我见过有人把一个按钮都拆成独立组件结果 props 传递链比业务逻辑还长。我的经验是同一层级、同一数据源、一起变化的内容优先放在同一个组件里跨层级、不同数据源、独立变化的内容才拆出去。比如商品卡片里的价格和库存它们都来自同一个商品对象大概率一起变化拆成两个组件反而制造不必要的通信成本。1.2 JSX 不是模板引擎是语法糖JSX 长得像 HTML这是它易上手的原因但也是很多人误解它的根源。它本质上是一个 JavaScript 表达式编译之后就是React.createElement的嵌套调用。这意味着你可以在 JSX 里写完整的 JavaScript 表达式比如三元运算、数组 map、逻辑与短路但不能写 if 语句和 for 循环因为那些是语句不是表达式。// JSX 写法 const list ( ul {items.map((item) ( li key{item.id}{item.name}/li ))} /ul ); // 编译后等价于 const list React.createElement( ul, null, items.map((item) React.createElement(li, { key: item.id }, item.name)) );理解这一点对排查 bug 特别重要。比如你写{condition Component /}当condition为 0 或空字符串时页面上会渲染出一个0或空白字符而不是什么都不渲染。因为0 anything的结果是0JSX 会把这个数字原样渲染出来。正确的写法是{condition ? Component / : null}或者用!!condition Component /。另一个容易踩的坑是 JSX 的注释写法。在 JSX 内部不能直接用//或/* */必须写成{/* 注释内容 */}。这个语法很反直觉但记住JSX 里的{}是 JavaScript 的地盘这个原则就都能理解了。1.3 为什么需要虚拟 DOM虚拟 DOM 可能是 React 被讨论最多、也最常被误解的概念。很多人以为虚拟 DOM 比真实 DOM 快这个说法其实不准确。精确的说法是虚拟 DOM 让 React 能够在内存中计算出最小的 DOM 变更集合然后一次性批量更新从而减少昂贵的真实 DOM 操作次数。真实 DOM 操作慢在哪慢在它不仅仅是改一个值还可能触发样式重算、布局回流、绘制合成这一整套浏览器的渲染流水线。而 JavaScript 对象之间的比较成本要低得多。React 先在虚拟 DOM 上做 diff 算法找出哪些节点需要增删改再把这些变更一次性应用到真实 DOM。注意虚拟 DOM 的意义不是比直接操作 DOM 快而是在你不手动优化的情况下依然维持足够好的性能。如果你的团队对性能有极致要求直接写命令式 DOM 操作或者用别的方案可能更快但代码的可维护性会断崖式下降。React 的选择是用一点性能换开发效率。2. Hooks 运行机制与状态管理实践2.1 useState 的更新是异步且批处理的useState大概是所有人入门的第一个 Hook但它的更新机制暗藏玄机。setState之后状态并不会立刻改变而是在当前事件循环结束后统一批量处理。这就导致了一个经典问题连续调用两次setCount(count 1)最终count只加了 1 而不是 2。const [count, setCount] useState(0); // 错误示范两次调用只加 1 setCount(count 1); setCount(count 1); // 正确示范使用函数式更新 setCount((prev) prev 1); setCount((prev) prev 1);函数式更新的参数是上一次的状态值React 会把多次更新排队依次把前一次的结果传给后一次。在需要基于最新状态计算新状态时永远使用函数式更新。这个习惯能在很多隐蔽 bug 中救你一命尤其是涉及到定时器、异步回调、连续交互的场景。还有一点是关于批处理的范围。React 18 之前只有在 React 事件处理函数中状态更新才会被批处理在setTimeout、Promise回调、原生事件监听器里每次setState都会触发一次独立的渲染。React 18 之后自动批处理覆盖了这些场景几乎所有地方的更新都会被批处理。如果你在用老版本又遇到为什么这里没批量更新的困惑先检查一下更新发生的上下文。2.2 useEffect 的依赖数组是契约不是优化手段useEffect是所有 Hook 里最容易被滥用的。我见过大量代码把useEffect当作在某个时机做某件事的万能工具结果就是依赖数组乱写要么漏了依赖导致闭包陷阱要么多写了依赖导致无限循环。核心认知是effect 的依赖数组是你对 React 的承诺——只有这些值变化时我这份副作用才需要重新执行。如果你在 effect 内部使用了某个外部变量却没写进依赖数组那这个 effect 读取到的就是上一次渲染时的旧值也就是所谓的闭包陷阱。const [userId, setUserId] useState(); const [userInfo, setUserInfo] useState(null); useEffect(() { // 这里使用了 userId它必须出现在依赖数组里 fetchUser(userId).then(setUserInfo); }, [userId]);依赖数组的另一个坑是引用类型依赖。如果依赖项是一个对象或数组而每次渲染都会生成新的引用effect 就会每次都执行可能引发无限循环。这时候你要么把依赖拆成基本类型要么用useMemo缓存引用。我个人的习惯是每个useEffect只负责一件事宁可多写几个 effect也不要把不相关的内容堆在一起。这既是为了依赖数组清晰也是为了后面排查问题时能直接定位。还有一个小技巧如果一段副作用依赖的是某个由 props 计算而来的值应该把计算过程放在组件里而不是塞进 effect 内。这样 effect 的依赖数组会更短逻辑也更符合数据流。2.3 useRef 不只是避开依赖的逃生通道useRef最常见的用法是获取 DOM 节点但它的本质是一个跨渲染周期保持不变的容器。修改ref.current不会触发重新渲染这个特性让它成为了存储可变值的好工具。我在实际开发中经常需要读取最新的状态但不希望因为读取它而触发 effect。比如一个点击埋点逻辑需要在事件回调里读取当前用户状态但又不想因为这个状态变化而重新绑定事件。这时候ref就是正解const [user, setUser] useState(null); const userRef useRef(user); useEffect(() { userRef.current user; }, [user]); // 在某个不会被重新注册的回调里 const handleClick useCallback(() { trackEvent(button_click, { userId: userRef.current?.id }); }, []);有一类经典问题是在setInterval里读取最新状态。直接写会拿到初始值因为闭包捕获的是第一次渲染时的状态。解法就是把状态同步到 ref 里让定时器每次执行都读取ref.current。这个模式我叫它ref 镜像是处理异步回调里状态读取问题的基础手段。注意useRef不是useState的替代品。可不要因为ref 改值不触发渲染就把所有状态都放 ref 里。如果这个值影响到界面展示它必须是 state只有在需要读写但不关心渲染时才用 ref。2.4 useMemo 与 useCallback 的正确打开方式useMemo和useCallback是性能优化的双刃剑用好了显著减少无效渲染用滥了反而让代码更难读、更难调试。先说结论useCallback(fn, deps)返回一个 memoized 的函数引用用于保持回调函数身份的稳定方便子组件做浅比较。useMemo(() value, deps)返回一个 memoized 的值用于跳过昂贵的计算以及保持引用类型值的稳定。// 昂贵计算的缓存 const filteredList useMemo(() { return list.filter((item) item.price maxPrice); }, [list, maxPrice]); // 稳定回调引用 const handleSelect useCallback((item) { setSelected(item); }, []);但这里有个反直觉的点useMemo并不保证一定不重新计算。React 在内存紧张或为了释放内存时可能会丢弃 memoized 的结果下次渲染重新计算。所以useMemo只适合做性能优化不能依赖它保证语义上的必然跳过。如果你的业务逻辑依赖这段代码只执行一次应该用useRef加标志位或者把逻辑放到useState的初始化函数里。实际项目里我见过的最常见误用是给所有函数都套上useCallback给所有计算都套上useMemo理由是万一性能有问题呢。结果就是依赖数组满天飞每次该更新的不更新不该更新的被跳过bug 反而更多。我的建议是凡是没有明显性能问题的场景先不用 memo。等你通过 React DevTools 的 Profiler 确认了某处存在性能瓶颈再精准地加上useMemo或useCallback。性能优化应该基于测量而不是基于猜测。3. 组件通信与数据流的几种方案3.1 props 逐层传递什么时候该停药React 的数据流是单向的自上而下。子组件需要什么数据父组件就通过 props 传什么。组件层级浅的时候很清爽但项目一大就会出现中间组件只是路过数据的情况——它自己不用这个 props纯粹是为了传给更深层的子孙组件。这就是所谓的 props drilling 问题。我判断该不该引入其他通信方式的依据很简单如果数据需要穿过三层以上的中间组件而且中间组件完全不对数据做任何加工那就要考虑 Context 或状态管理库了。三层是我的经验值两层以内用 props 传递最清晰超过三层维护成本就显著升高。3.2 Context 的适用边界与常见误区Context 解决了跨层级传递的问题但它不是万能的。最关键的一点是Context 的 value 一旦变化所有消费这个 Context 的组件都会重新渲染不管它们实际使用的是 value 中的哪一部分。const ThemeContext createContext({ theme: light, user: null, config: {} }); // 这种写法很危险每次渲染都生成新对象 ThemeContext.Provider value{{ theme, user, config }} {children} /ThemeContext.Provider上面的写法里value是个对象字面量父组件每次渲染都会生成一个全新的对象引用导致所有useContext(ThemeContext)的组件全部重新渲染哪怕theme根本没变。解法是把 value 用useMemo缓存起来const contextValue useMemo(() ({ theme, user, config }), [theme, user, config]); ThemeContext.Provider value{contextValue}{children}/ThemeContext.ProviderContext 适合放低频变化、全局需要的数据比如主题、登录态、语言配置。不适合放高频变化、局部使用的数据比如表单输入值、列表筛选条件。后者高频更新会导致大范围的组件重渲染性能很差。如果你发现 Context 刷新太频繁说明选型错了。3.3 状态管理库的选型思考我在几个项目里分别用过不同的状态管理方案简单说说选型思路。中小型项目里Context 加useReducer基本够用。useReducer的好处是把状态的更新逻辑集中到一个 reducer 函数里便于测试和追踪适合那种多个操作会修改同一块状态的场景。function reducer(state, action) { switch (action.type) { case increment: return { count: state.count 1 }; case decrement: return { count: state.count - 1 }; default: return state; } } const [state, dispatch] useReducer(reducer, { count: 0 });再往上走当项目里有大量跨页面、跨模块的共享状态并且有服务端数据缓存、请求取消、状态持久化、时间旅行调试等需求时就有必要引入专门的状态管理库。我现在的默认选择是轻量级的方案不引入过度的概念和样板代码。我见过很多团队把服务端的数据请求结果也放进全局状态这是一个值得商榷的做法。服务端数据和客户端状态是两回事服务端数据有缓存、失效、重试的语义客户端状态有本地交互、临时 UI 状态的语义。混在一起会让状态管理变得臃肿而且很难理清数据的来源和更新时机。如果项目以服务端数据为主我会优先考虑数据请求缓存方案而不是把请求结果手动塞进全局 store。全局 store 只保留真正跨组件共享的客户端状态。4. 性能优化从测量到实践的完整路径4.1 先找出不值得渲染的组件React 组件每次父组件渲染默认都会跟着重新渲染。判断一个组件是否值得加memo要看它的渲染开销大不大、渲染频率高不高、props 引用是否稳定。三个条件都满足再加memo才有意义。const ExpensiveChart memo(function ExpensiveChart({ data, onSelect }) { // 这里做了昂贵的图表绘制计算 return Chart data{data} onSelect{onSelect} /; });memo的作用是让组件在 props 不变时跳过重新渲染。但它做的是浅比较如果父组件给ExpensiveChart传了一个内联函数或内联对象那么每次父组件渲染props 的引用都变了memo就形同虚设。这就是为什么useCallback通常和memo成对出现——一个负责稳定函数引用一个负责跳过渲染。4.2 key 的正确使用是diff算法的地基列表渲染的key可能是 React 中最容易被敷衍的属性。我看到很多代码用数组下标做 key一旦列表顺序变化、中间插入或删除元素React 的复用逻辑就会出错可能出现状态错位、输入框内容串行等问题。// 错误示范用下标做 key {items.map((item, index) Item key{index} data{item} /)} // 正确示范用稳定唯一的标识 {items.map((item) Item key{item.id} data{item} /)}key的本质是告诉 React这个组件实例对应的是哪个数据项。只有用稳定唯一的标识React 才能准确追踪每个组件的增删移动。如果数据没有天然的 id可以自己生成一个唯一标识。同时要注意key只需要在列表上下文中唯一不需要全局唯一。还有一个小细节不要用随机数或Date.now()做 key。那样会导致每次渲染 key 都不一样React 会认为所有列表项都是新的全部卸载重建不仅状态丢失性能也会崩。这在做拖拽排序或动画时特别容易踩到。4.3 渲染优化之外的大头减少不必要的工作很多人一谈性能优化就只盯着减少重新渲染但在实际项目中很多时候性能瓶颈根本不在渲染次数而在于每次渲染时做了太多不必要的计算。比如在组件函数体里直接执行复杂的过滤、排序、格式化逻辑这些逻辑在每次组件渲染时都会重算。而且因为闭包的原因即使相关数据没变只要组件重新渲染这些纯函数也会被重新执行。解法是useMemoconst visibleOrders useMemo(() { return orders .filter((o) o.status active) .sort((a, b) b.createTime - a.createTime); }, [orders]);另一个容易忽视的性能杀手是在渲染过程中创建新的对象和数组。如果这个对象被传给了一个memo包着的子组件父组件每次渲染都会让子组件的 memo 失效因为引用变了。这种问题用 React DevTools 的 Profiler 一眼就能看出来明明数据没变大量组件却红了一片。优化的顺序也很有讲究。我建议先优化数据结构和计算逻辑再优化渲染次数最后才是各种 memo。很多时候修改一个不合理的状态层级比给十几个组件加 memo 有效得多。比如一个列表的筛选条件如果被定义在列表组件的父组件里每次父组件状态变化都会导致列表重新过滤这时把筛选逻辑下沉到列表内部性能立刻改善。4.4 治理 useEffect 引起的重复请求项目上线后最常见的性能问题之一是 useEffect 的依赖数组导致重复请求。比如useEffect(() { fetchData(keyword).then(setData); }, [keyword]);如果keyword从某个对象属性中解构而来而那个对象每次渲染都是新引用那这个 effect 就会请求风暴。排查的思路是先在 effect 里打印依赖项的引用或值看它是否每次都在变。如果是引用类型变化用useMemo或把值提取成基本类型。另一个实用技巧是给请求加取消机制。React 18 之后StrictMode 会在开发模式下故意执行两次 effect 来暴露副作用问题如果请求没有做好防御就会出现重复请求。用 AbortController 或者简单的局部标志位可以在组件卸载或依赖变化时取消上一次请求useEffect(() { let ignore false; fetchData(keyword).then((data) { if (!ignore) setData(data); }); return () { ignore true; }; }, [keyword]);这段代码虽然简单但能避免大量的竞态问题。忽略它的话用户快速切换筛选条件时后返回的旧请求可能覆盖新数据出现数据错乱。这也是React 知识笔记里我标注过好几次的重点建议每个写请求的人都记下来。5. 常见问题与排查技巧实录5.1 状态更新了但页面不刷新这是新手阶段最常遇到的问题。我排查时最先怀疑的永远是状态到底是没更新还是更新了但没触发渲染。先区分两种情况。第一种是把可变对象直接改掉const [arr, setArr] useState([1, 2, 3]); arr.push(4); // 直接修改原数组 setArr(arr); // 引用的地址没变React 认为状态没变这里的问题在于 React 的useState是通过Object.is比较旧值和新值的。旧数组和新数组是同一个引用所以 React 判定状态没变跳过渲染。解法是永远返回一个新引用setArr([...arr, 4]);第二种是试图修改 props。props 是只读的子组件修改 props 不会影响父组件应当在子组件里触发父组件的更新事件由父组件改自己的状态。这条规则有时候要靠踩坑才记得住。5.2 闭包陷阱为什么我的回调里拿到的总是旧值闭包陷阱的经典场景是这样的你写了一个倒计时setInterval 每秒让 count 减 1。然后你在某个事件回调里读取 count发现一直是初始值。问题出在事件回调函数是在第一次渲染时创建的它捕获的是那一轮渲染的 count 值之后 count 变化这个回调里的 count 还是旧值。解决思路有两种如果回调需要最新值用ref镜像如果回调本身需要在依赖变化时重新创建把依赖写进useCallback的依赖数组里。const [count, setCount] useState(0); const countRef useRef(count); useEffect(() { countRef.current count; }, [count]); // 任何地方都能拿到最新值 const handleClick () { console.log(countRef.current); };动手排查时先在怀疑的回调里打断点或者console.log相关变量看它是哪次渲染的值。出现总是第一版的值基本就是闭包陷阱不要再去分析业务逻辑了方向错了会很浪费时间。5.3 依赖数组写不对导致的三个典型症状依赖数组是 useEffect 最容易写错的地方我整理几类高频问题症状原因解决方向effect 执行次数远超预期甚至无限循环依赖了每次渲染都会变化的对象、数组或函数用 useMemo/useCallback 稳定引用或拆解成基本类型依赖effect 不执行数据是旧值漏写了某个内部使用的变量凡是在 effect 里用到的 props、state都要列入依赖组件卸载后还在 setState清理函数没写或没写对在 effect 中返回清理函数取消订阅、清除定时器、标记忽略有一个比较实用的小技巧来检查漏写的依赖在项目里接入 lint 规则当依赖数组缺失时会给出警告。这个 lint 提示在绝大多数情况下都是对的值得养成不跳过它的习惯。当然 lint 会误报的场景也有比如你确实只想在挂载时执行一次又用到了某个只会变一次的值这时候可以显式地把依赖写进数组或者加注释说明原因而不是硬把警告关掉。5.4 列表数据更新后组件状态串位这个问题的根源就是前面说的 key 用错。列表项组件是带本地状态的当列表数据重新排序或过滤后React 需要知道哪个组件实例对应哪个数据项。如果没有合适的 keyReact 会复用旧的组件实例导致原来第一项的输入框内容跑到了第二项身上。解决方法是检查列表渲染的 key 是否为稳定唯一标识。如果数据里没有 id可以建立一个key映射关系或者在数据入库时就生成 id。另一个相关的坑是key 连带着组件的 DOM 结构一起决定 React 是复用还是重建。如果 key 相同但结构大变React 会尽量复用 DOM 节点可能导致样式错乱这时可能需要调整 key 的粒度。写在最后的一点个人体会这些知识点单独拎出来每一个都不复杂但它们之间是相互关联的。props 传递影响组件边界组件边界决定状态放哪状态放哪影响重渲染范围重渲染范围产生性能问题性能问题又逼着你回头调整数据结构。我最大的感触是React 的很多坑其实是它的设计特性理解了特性背后的原理坑自然就不是坑了。如果在这些笔记里只能留下一句话我会选所有 React 问题本质上都是数据流和组件生命周期的问题。排查的时候先画清楚数据从哪来、到哪去、在哪变化再去看具体代码往往能少走很多弯路。希望这份笔记能给你带来一些实际的帮助至少让你在写下一个组件时心里少一点不确定多一点底气。