1. 为什么要把React Hooks拆成两个阶段来学1.1 过了第一部分你的React能力其实还缺一块第一部分讲完useState和useEffect之后绝大多数人写页面的能力其实已经上来了请求数据、维护列表、切换loading状态几个基础函数就能搞定。但只要你把项目规模再扩大一点比如从单页组件进入一个真实业务系统就会很快撞上三道墙共享状态传不进去、状态逻辑写得乱、渲染性能开始说不清。这三道墙中间缺的那块能力就是第二部分要补的。第一道墙是“状态传不进去”两个位置相距很远的组件需要读写同一份数据你只能把这个状态提升到某个公共父组件然后一层层往下传props。中间那些根本不关心这份数据的组件也不得不跟着接收和透传改一个变量名整条链路上的props都要跟着动。时间一长组件层级就是一团理不清的乱麻删一个中间组件可能连带报出一串属性缺失错误。第二道墙是“状态逻辑写得乱”一个页面经常会同时维护五六个useState而且这些状态之间还有关联——比如一个报错既要展示在表单顶部又要让提交按钮置灰还要把日志状态标记为失败。用useState散落管理时这几处更新分布在不同回调里每次你要保证“同时”改对好几个字段改了一个功能另一个功能莫名其妙就出问题了。第三道墙是“性能说不清”父组件一刷新所有子孙组件都跟着更新用户在输入框里每敲一个字一大批计算量很高的函数就重新执行一遍。而且难办的是这类问题没法靠“少写代码”解决你压根说不清瓶颈从哪来只能逐个组件去试。React DevTools的Profiler面板虽然能看到重渲染但很多初学者甚至不知道要从这里开始排查。第二部分就是专门拆这三道墙的。useRef负责在反复渲染之间保存可变数据同时不触发重渲染useContext让共享状态不再靠props人肉搬运useReducer把散落的状态逻辑收拢进一个纯函数里useMemo和useCallback给渲染链路做减法把不必要的重复计算和重复更新拦下来。这5个hooks你逐一掌握之后再回头看那些“传参传得头疼”的项目会发现自己手里已经多了一整套工具箱。这篇内容不要求你有高级工程师的底子只要你已经能在项目里正常使用useState和useEffect文里的每个示例拿过去就能落地。这也是我对这个系列第27课的一个定位理解前一段讲的是“会用”这一段开始讲“怎么用得更好”。1.2 先建立一张全景图这5个hooks分别解决什么在展开细节之前我建议先把这5个hooks的记忆锚点建立起来useRef、useContext、useReducer、useMemo、useCallback。我把它们放在一张对照表里每一行后面都会逐一展开讲先让你对“什么时候用谁”有个整体印象Hook解决什么问题最容易踩的坑useRef在多次渲染之间保存可变值不触发重渲染把ref当state用改完页面没反应useContext跨层级共享数据避免props逐层透传塞入太多无关状态逐渐变成全局变量useReducer状态逻辑集中化复杂业务状态变更可预测简单逻辑也硬塞reducer代码反而更绕useMemo缓存计算结果依赖不变就跳过计算依赖数组写错缓存失效还排查半天useCallback缓存函数引用让子组件不因父组件渲染而重渲染为了性能而性能反而比不用还慢这张表的每一行背后都是血泪史。就比如“把ref当state用”这个坑很多初学Hooks的人遇到页面不更新时第一反应是“是不是我setState没写对”折腾半小时后才明白ref根本不触发渲染。建议你把“最容易踩的坑”这一列单独记到笔记里踩过一次就知道有多疼。2. 五个核心hooks拆解为什么这样设计2.1 useRef状态之外的“稳定存储区”先讲useRef。这是被误解最多的一个hooks。很多人听说“useRef可以保存值”就把它当成useState的平替来用结果改了一堆ref.current之后页面纹丝不动然后开始怀疑人生。其实它的真正定位是在多次渲染之间保存一个可变引用但这个变化不会触发组件重渲染。这是它和useState在底层机制上最本质的区别。我举一个最典型的场景倒计时计时器。假设你要写一个番茄钟界面上有一个倒计时用户点“开始”之后每秒减1。如果定时器ID用useState来存每次setInterval返回值被写进state后组件就会立刻重渲染然后又触发新的赋值循环往复定时器数量最终失控。如果用普通局部变量存组件一旦因为别的原因重渲染这个局部变量立刻就归零了。只有useRef能同时解决两件事它的current属性在重渲染之后依然保留而且修改current不会再次触发渲染。function FocusTimer() { const [seconds, setSeconds] useState(25 * 60); const timerRef useRef(null); const start () { if (timerRef.current) return; // 防止重复启动 timerRef.current setInterval(() { setSeconds((s) s - 1); }, 1000); }; const stop () { clearInterval(timerRef.current); timerRef.current null; }; }这段代码里的timerRef.current保存的是定时器ID它每秒被访问一次但组件不会因此重渲染倒计时数字的更新只由setSeconds控制。等到用户点“停止”先clearInterval再把current置回null这样再次点“开始”时start函数里的防重复启动判断才会放行。这个模式在真实项目里出现频率极高音频暂停播放、Canvas动画循环ID、滚动监听器的解绑全是同一个套路。useRef还有一个非常高频的用途拿DOM节点。比如某个弹窗打开后需要默认聚焦到第一个输入框。你不需要给input额外设置id更不需要用document.getElementById在整个文档里全局查找直接在JSX上绑定ref就行const inputRef useRef(null); const focusInput () { inputRef.current?.focus(); }; return input ref{inputRef} typetext /;这里的ref跟着当前组件实例走组件卸载之后引用也会被回收不会污染全局。这一点在列表渲染里尤其好用每个列表项都能拥有自己独立的ref。需要特别提醒的是不要在render函数的返回逻辑里读写ref.current。读有可能拿到上一次提交的旧值写则可能造成“数据和UI错位”这类非常隐蔽的问题。如果你确实需要在渲染阶段之前读取最新值把它放到useLayoutEffect或useEffect里做。2.2 useContext解决props逐层透传但别把它玩成全局变量第二个是useContext。它的心智模型非常朴素在组件树的某个位置放一个Provider包裹层下面所有层级的组件都能通过useContext直接拿到Provider上的value不需要一根根props往深处传递。对于“当前登录用户的头像”“多语言文案”“全局主题色”这类高频跨层数据它能省掉大量透传代码。举个例子。某后台页面顶部导航要显示用户名右上角购物车要显示用户优惠券底部设置页要拿用户权限这些组件在组件树里相隔很远。如果全部用props传中间每一层即使完全不关心用户数据也得接收并转发长链路里改一个字段名前后十来个文件都要跟着调整。用Context之后组件树中间那些“中转站”彻底解放了只有真正要消费数据的组件才需要useContextconst UserContext createContext(null); function App() { const [user, setUser] useState(null); return ( UserContext.Provider value{{ user, setUser }} Header / Main / Footer / /UserContext.Provider ); } function UserAvatar() { const { user } useContext(UserContext); return img src{user?.avatar} altavatar /; }useContext用起来门槛不高但我在实际项目里见过更普遍的坑不是不会用而是过度使用。有人会把所有“可能别处用得上”的状态全塞进一个巨大的Context里最终一个Context里堆了几十项数据任何一个小的state变动都会导致所有消费组件跟着重渲染。这时打开DevTools满屏都是重渲染标记你根本分不清是哪个数据变化引起的。我的经验原则是一个Context只承载一个业务边界。用户信息一个主题配置一个购物车一个不要为了图省事把不同语义的数据拼在一起。另外要特别注意Provider的value引用稳定性。value如果是每次渲染重新创建的对象字面量即使数据本身没变消费组件也会在父组件渲染时跟着重渲染。这一点在2.4节讲useMemo时我会特意回来说。2.3 useReducer把一堆setState收编成一个状态机useReducer刚接触时听起来很“重”很多人会以为它是什么状态管理框架的前置概念。其实它的核心很简单把一组相关状态的变化集中到一个纯函数里每次更新通过一个action来描述“发生了什么”然后reducer根据这个action计算出一个新的state。以购物车为例。如果用useState去管理你得同时维护items、isCheckingOut、error这三个相互关联的状态。问题是用户提交订单时要把isCheckingOut置为true还要把error清空订单失败时又要同时把isCheckingOut置回false并写入error。这些“同时”在useState版本里是散落在不同回调里的每个回调都要小心翼翼把其他字段配合改一遍漏一处就出现状态不一致。用useReducer之后这些变化被收编进一个switch-casefunction cartReducer(state, action) { switch (action.type) { case ADD_ITEM: return { ...state, items: [...state.items, action.payload] }; case START_CHECKOUT: return { ...state, isCheckingOut: true, error: null }; case CHECKOUT_FAILED: return { ...state, isCheckingOut: false, error: action.error }; case RESET: return initialState; default: return state; } } const [cartState, dispatch] useReducer(cartReducer, initialState);你会发现这是一种把状态流动路径可视化的手段。只要打开这个reducer函数就能看到该业务中的所有状态变化而不是在十几个回调里东翻西找“谁动了error”。对于涉及多状态联动、操作步骤完整的业务场景比如订单流程、多步表单、上传任务reducer的收益非常明显。但我也要讲清楚边界它不适合所有场景。如果只是处理一个“是否在加载中”的布尔值硬写成reducer就会多出一堆无谓的action和type常量。我在带人时见过一个团队把简单的计数器也写成reducer结果是代码行数翻倍可读性反而下降。一个比较稳妥的判断标准是状态之间有关联、更新路径有分支时用reducer单个独立变量的简单开关useState就够了。2.4 useMemo和useCallback优化渲染先算清楚这笔账useMemo和useCallback常被当成一对兄弟因为底层机制完全一样依赖不变时直接返回上一次创建的结果。区别只在useMemo缓存的是某个计算值useCallback缓存的是函数本身的引用。先看useMemo。它最适合的场景是一个计算很重、且依赖变化频率低的值。比如列表中要根据关键词过滤几百条数据过滤逻辑本身不算太重但如果在每次渲染时都重新计算还是会造成不必要的开销。useMemo之后只要items和search两个依赖没变过滤结果就直接从缓存里取const visibleItems useMemo(() { return items.filter((item) item.name.includes(search)); }, [items, search]);useCallback解决的是“函数引用稳定性”问题。函数组件每次渲染都会创建一个新的函数对象如果这个新函数被当props传给子组件子组件即使被优化过也会因为props引用变化而被迫重新渲染。useCallback固定依赖后只有依赖变化时函数引用才会变const handleAdd useCallback((title) { dispatch({ type: ADD, title }); }, []);这里有个特别重要的预算意识使用这两个API本身是有成本的。useMemo要记住上一次的结果useCallback要维护依赖数组和上一次的函数引用两者都占用内存和额外比较的开销。如果被缓存的计算本身只花不到1毫秒或者被缓存的函数只在当前组件内部使用、根本不会传给子组件包一层反而更慢。我在实际项目里见过最典型的反面案例是把所有函数和计算全部包上useMemo和useCallback理由是“反正加上不会出错”。结果代码里布满了依赖数组任何一个依赖漏掉都会导致缓存失效排查一轮花的时间比省下的时间还多。正确的做法是先在DevTools里确认某个计算或子组件的重渲染确实是瓶颈再去考虑用这两个API。3. 一个完整案例把这些hooks全部串起来3.1 案例需求与模块划分光拆开讲每个hooks理解是不够的它们组合起来才是工作日常。我这边准备了一个演示项目名字就叫“模拟项目X”好了需求很清晰一个带筛选和主题切换的待办管理Demo。为什么不直接写传统to-do因为它能很自然地把useReducer、useContext、useRef、useMemo、useCallback全部放在同一个项目里你一眼就能看出它们各自的分工。需求一共四条。第一支持新增、删除待办支持点击单条待办切换完成状态。第二列表有三种筛选视图全部、未完成、已完成。第三右上角可以切换明暗主题主题要作用到整个页面。第四新增待办时输入框自动聚焦。模块划分上把数据层和展示层分开。待办数据用useReducer管理主题状态用useContext全局共享输入框聚焦用useRef筛选后的列表用useMemo子组件回调统一用useCallback稳定下来。这样每个hooks都找到了一个“非它不可”的位置。3.2 数据层useReducer与useContext的经典组合先建立ThemeContext单独一个文件管理避免把长代码全堆在App组件里const ThemeContext createContext({ theme: light, toggleTheme: () {} }); export function ThemeProvider({ children }) { const [theme, setTheme] useState(light); const toggleTheme useCallback(() { setTheme((t) (t light ? dark : light)); }, []); const value useMemo(() ({ theme, toggleTheme }), [theme, toggleTheme]); return ( ThemeContext.Provider value{value} {children} /ThemeContext.Provider ); } export function useTheme() { return useContext(ThemeContext); }这里最需要注意的是value那行useMemo。假如没有这行ThemeProvider每次重渲染都会构造一个新的value对象任何调用useTheme的子组件都会跟着重渲染。加上useMemo后只有theme和toggleTheme这两个依赖变化时value才更新子组件就能安静地只在主题真正切换时才重渲染。这个细节如果不写出来90%的人第一次都会忽略。待办数据则用useReducer管理。reducer只负责纯逻辑不碰任何外部状态这也是它和“直接在回调里修改state”最大的不同function todoReducer(state, action) { switch (action.type) { case ADD: return [ ...state, { id: Date.now(), title: action.title, done: false }, ]; case TOGGLE: return state.map((item) item.id action.id ? { ...item, done: !item.done } : item ); case REMOVE: return state.filter((item) item.id ! action.id); default: return state; } }reducer是纯函数这一点一定要养成肌肉记忆不要在case里直接修改state数组比如state.push(newItem)。这种原地修改不仅破坏了纯函数原则还会让React的批处理机制出现状态错乱而且问题极其隐蔽难复现。每次都要返回一个全新的数组或对象这是useReducer的底线。3.3 展示层useRef与useMemo的协作待办输入框需要“初始化聚焦”。这个需求用useRef加useEffect两行就解决function TodoInput({ onAdd }) { const inputRef useRef(null); useEffect(() { inputRef.current?.focus(); }, []); const handleSubmit (e) { e.preventDefault(); const title inputRef.current?.value.trim(); if (!title) return; onAdd(title); inputRef.current.value ; }; }筛选列表的部分把useMemo亮出来。如果没有useMemo每次父组件状态刷新这个过滤函数都要重新执行一遍待办数据一旦累积到几百条肉眼就能感受到卡顿。加上useMemo之后只要todos和filter这两个依赖没变结果就直接复用缓存const visibleTodos useMemo(() { if (filter active) return todos.filter((t) !t.done); if (filter done) return todos.filter((t) t.done); return todos; }, [todos, filter]);3.4 组合之后的整体结构把整个App的组件树组织成这样function App() { const [filter, setFilter] useState(all); const [todos, dispatch] useReducer(todoReducer, initialTodos); const handleAdd useCallback((title) dispatch({ type: ADD, title }), []); const handleToggle useCallback((id) dispatch({ type: TOGGLE, id }), []); return ( ThemeProvider div classNameapp TodoInput onAdd{handleAdd} / FilterBar filter{filter} onChange{setFilter} / TodoList todos{visibleTodos} onToggle{handleToggle} / /div /ThemeProvider ); }整体看下来你会发现在真实项目里hooks单个看起来都很简单难点全在组合。reducer给数据管理一个清晰的入口context让主题数据隐蔽地流到任意层级ref控制了一个不参与渲染的焦点memo和callback保证了渲染性能和回调稳定。这就是第二部分强调的“工程思维”不是背API而是在恰当的层级做恰当的事。4. 日常开发里最容易踩的坑问题与排查技巧4.1 一张问题速查表症状真正原因解决思路ref.current更新了但页面完全没反应ref的变化不触发渲染需要展示的内容交给stateref只保存“无须参与渲染”的实例数据组件明明在Provider内部useContext还是返回undefinedProvider和Consumer不在同一棵组件树或useContext没写在组件顶层检查Provider包裹层级用自定义Hook提前抛错定位StrictMode下useEffect执行了两次开发模式下React故意反复挂载在useEffect里写cleanup函数清理定时器、取消请求useMemo缓存的值始终不变化依赖数组漏写或写错用lint插件检查依赖必要时把多字段依赖写成对象展开useCallback包了子组件依然重渲染子组件没被优化或依赖引用不稳定给子组件包React.memo再检查依赖引用是否稳定reducer执行后UI没按预期更新reducer里原地修改了state对象永远返回新对象/数组用展开运算符配合map/filter4.2 排查疑难杂症时的三个抓手遇到这类问题我一般靠三个抓手React DevTools的Profiler面板、reducer日志回放、以及给useEffect加console.log验证依赖。Profiler面板能按时间轴直接告诉你哪位组件在何时重渲染比肉眼猜测快得多。前面提到的“Context value没稳定导致大量消费者重渲染”在Profiler里一眼就能看到同一时间段内大量组件同时闪黄顺着链路找到Provider再查value引用就定位了。reducer日志回放适合状态流的问题。我习惯在reducer函数第一行先打印action.type每次dispatch都会留下一条日志。状态出错时顺着日志回放看是哪个action触发了异常状态比对着代码盲查快很多。排查完记得把这些调试输出清掉不然控制台会被刷屏。给useEffect加console.log验证依赖是排查“effect为什么总是执行”的土办法虽然土但极其有效。在effect里打印相关数据源观察它们每次渲染是否变化就能很快定位是哪一项依赖不稳定导致的重复执行。用完之后把console.log删掉就行。4.3 几个值得养成的习惯第一个习惯自定义Hook里带防御性判断。我写useTheme的时候一定会判断“如果没有Provider上下文就抛错”。多人合作时总有新同学漏包Provider这种错误的出现频率远超想象。在自定义Hook里加一个throw报错信息会直接点明“useTheme必须在ThemeProvider内使用”定位成本从半小时降到五分钟。第二个习惯reducer的action不要在代码里散落字符串。用一个ActionTypes常量文件集中维护后面加功能时不会出现“拼错单词静默失败”的尴尬。真报错还好最怕的就是action的type拼错了switch语句走default分支页面一点反馈都没有但要排查很久。第三个习惯把“要不要用useMemo/useCallback”当成性能决策而不是习惯动作。先跑一次Profiler确认确实是瓶颈再动手优化。没有分析就直接包一层通常是把代码复杂度和阅读成本同时加了上去性能却没什么变化。我个人在实际项目里试过很多次最管用的学习方法就是把一个线上模块从useState迁移到useReducer或者把一个组件树里的props逐层传递改成Context。改完再对比两次代码的差异很多东西一下子就通了。用这个项目X的Demo练手也是一样先把完整代码抄一遍再手动替换其中某个hooks观察行为变化比看十遍教程都有用。后面如果想继续往更深走useLayoutEffect、useImperativeHandle、自定义Hooks生态还有很大空间但把这一课里面的五个hooks扎实用好已经足够撑起绝大多数业务场景了。
1. 为什么要把React Hooks拆成两个阶段来学1.1 过了第一部分你的React能力其实还缺一块第一部分讲完useState和useEffect之后绝大多数人写页面的能力其实已经上来了请求数据、维护列表、切换loading状态几个基础函数就能搞定。但只要你把项目规模再扩大一点比如从单页组件进入一个真实业务系统就会很快撞上三道墙共享状态传不进去、状态逻辑写得乱、渲染性能开始说不清。这三道墙中间缺的那块能力就是第二部分要补的。第一道墙是“状态传不进去”两个位置相距很远的组件需要读写同一份数据你只能把这个状态提升到某个公共父组件然后一层层往下传props。中间那些根本不关心这份数据的组件也不得不跟着接收和透传改一个变量名整条链路上的props都要跟着动。时间一长组件层级就是一团理不清的乱麻删一个中间组件可能连带报出一串属性缺失错误。第二道墙是“状态逻辑写得乱”一个页面经常会同时维护五六个useState而且这些状态之间还有关联——比如一个报错既要展示在表单顶部又要让提交按钮置灰还要把日志状态标记为失败。用useState散落管理时这几处更新分布在不同回调里每次你要保证“同时”改对好几个字段改了一个功能另一个功能莫名其妙就出问题了。第三道墙是“性能说不清”父组件一刷新所有子孙组件都跟着更新用户在输入框里每敲一个字一大批计算量很高的函数就重新执行一遍。而且难办的是这类问题没法靠“少写代码”解决你压根说不清瓶颈从哪来只能逐个组件去试。React DevTools的Profiler面板虽然能看到重渲染但很多初学者甚至不知道要从这里开始排查。第二部分就是专门拆这三道墙的。useRef负责在反复渲染之间保存可变数据同时不触发重渲染useContext让共享状态不再靠props人肉搬运useReducer把散落的状态逻辑收拢进一个纯函数里useMemo和useCallback给渲染链路做减法把不必要的重复计算和重复更新拦下来。这5个hooks你逐一掌握之后再回头看那些“传参传得头疼”的项目会发现自己手里已经多了一整套工具箱。这篇内容不要求你有高级工程师的底子只要你已经能在项目里正常使用useState和useEffect文里的每个示例拿过去就能落地。这也是我对这个系列第27课的一个定位理解前一段讲的是“会用”这一段开始讲“怎么用得更好”。1.2 先建立一张全景图这5个hooks分别解决什么在展开细节之前我建议先把这5个hooks的记忆锚点建立起来useRef、useContext、useReducer、useMemo、useCallback。我把它们放在一张对照表里每一行后面都会逐一展开讲先让你对“什么时候用谁”有个整体印象Hook解决什么问题最容易踩的坑useRef在多次渲染之间保存可变值不触发重渲染把ref当state用改完页面没反应useContext跨层级共享数据避免props逐层透传塞入太多无关状态逐渐变成全局变量useReducer状态逻辑集中化复杂业务状态变更可预测简单逻辑也硬塞reducer代码反而更绕useMemo缓存计算结果依赖不变就跳过计算依赖数组写错缓存失效还排查半天useCallback缓存函数引用让子组件不因父组件渲染而重渲染为了性能而性能反而比不用还慢这张表的每一行背后都是血泪史。就比如“把ref当state用”这个坑很多初学Hooks的人遇到页面不更新时第一反应是“是不是我setState没写对”折腾半小时后才明白ref根本不触发渲染。建议你把“最容易踩的坑”这一列单独记到笔记里踩过一次就知道有多疼。2. 五个核心hooks拆解为什么这样设计2.1 useRef状态之外的“稳定存储区”先讲useRef。这是被误解最多的一个hooks。很多人听说“useRef可以保存值”就把它当成useState的平替来用结果改了一堆ref.current之后页面纹丝不动然后开始怀疑人生。其实它的真正定位是在多次渲染之间保存一个可变引用但这个变化不会触发组件重渲染。这是它和useState在底层机制上最本质的区别。我举一个最典型的场景倒计时计时器。假设你要写一个番茄钟界面上有一个倒计时用户点“开始”之后每秒减1。如果定时器ID用useState来存每次setInterval返回值被写进state后组件就会立刻重渲染然后又触发新的赋值循环往复定时器数量最终失控。如果用普通局部变量存组件一旦因为别的原因重渲染这个局部变量立刻就归零了。只有useRef能同时解决两件事它的current属性在重渲染之后依然保留而且修改current不会再次触发渲染。function FocusTimer() { const [seconds, setSeconds] useState(25 * 60); const timerRef useRef(null); const start () { if (timerRef.current) return; // 防止重复启动 timerRef.current setInterval(() { setSeconds((s) s - 1); }, 1000); }; const stop () { clearInterval(timerRef.current); timerRef.current null; }; }这段代码里的timerRef.current保存的是定时器ID它每秒被访问一次但组件不会因此重渲染倒计时数字的更新只由setSeconds控制。等到用户点“停止”先clearInterval再把current置回null这样再次点“开始”时start函数里的防重复启动判断才会放行。这个模式在真实项目里出现频率极高音频暂停播放、Canvas动画循环ID、滚动监听器的解绑全是同一个套路。useRef还有一个非常高频的用途拿DOM节点。比如某个弹窗打开后需要默认聚焦到第一个输入框。你不需要给input额外设置id更不需要用document.getElementById在整个文档里全局查找直接在JSX上绑定ref就行const inputRef useRef(null); const focusInput () { inputRef.current?.focus(); }; return input ref{inputRef} typetext /;这里的ref跟着当前组件实例走组件卸载之后引用也会被回收不会污染全局。这一点在列表渲染里尤其好用每个列表项都能拥有自己独立的ref。需要特别提醒的是不要在render函数的返回逻辑里读写ref.current。读有可能拿到上一次提交的旧值写则可能造成“数据和UI错位”这类非常隐蔽的问题。如果你确实需要在渲染阶段之前读取最新值把它放到useLayoutEffect或useEffect里做。2.2 useContext解决props逐层透传但别把它玩成全局变量第二个是useContext。它的心智模型非常朴素在组件树的某个位置放一个Provider包裹层下面所有层级的组件都能通过useContext直接拿到Provider上的value不需要一根根props往深处传递。对于“当前登录用户的头像”“多语言文案”“全局主题色”这类高频跨层数据它能省掉大量透传代码。举个例子。某后台页面顶部导航要显示用户名右上角购物车要显示用户优惠券底部设置页要拿用户权限这些组件在组件树里相隔很远。如果全部用props传中间每一层即使完全不关心用户数据也得接收并转发长链路里改一个字段名前后十来个文件都要跟着调整。用Context之后组件树中间那些“中转站”彻底解放了只有真正要消费数据的组件才需要useContextconst UserContext createContext(null); function App() { const [user, setUser] useState(null); return ( UserContext.Provider value{{ user, setUser }} Header / Main / Footer / /UserContext.Provider ); } function UserAvatar() { const { user } useContext(UserContext); return img src{user?.avatar} altavatar /; }useContext用起来门槛不高但我在实际项目里见过更普遍的坑不是不会用而是过度使用。有人会把所有“可能别处用得上”的状态全塞进一个巨大的Context里最终一个Context里堆了几十项数据任何一个小的state变动都会导致所有消费组件跟着重渲染。这时打开DevTools满屏都是重渲染标记你根本分不清是哪个数据变化引起的。我的经验原则是一个Context只承载一个业务边界。用户信息一个主题配置一个购物车一个不要为了图省事把不同语义的数据拼在一起。另外要特别注意Provider的value引用稳定性。value如果是每次渲染重新创建的对象字面量即使数据本身没变消费组件也会在父组件渲染时跟着重渲染。这一点在2.4节讲useMemo时我会特意回来说。2.3 useReducer把一堆setState收编成一个状态机useReducer刚接触时听起来很“重”很多人会以为它是什么状态管理框架的前置概念。其实它的核心很简单把一组相关状态的变化集中到一个纯函数里每次更新通过一个action来描述“发生了什么”然后reducer根据这个action计算出一个新的state。以购物车为例。如果用useState去管理你得同时维护items、isCheckingOut、error这三个相互关联的状态。问题是用户提交订单时要把isCheckingOut置为true还要把error清空订单失败时又要同时把isCheckingOut置回false并写入error。这些“同时”在useState版本里是散落在不同回调里的每个回调都要小心翼翼把其他字段配合改一遍漏一处就出现状态不一致。用useReducer之后这些变化被收编进一个switch-casefunction cartReducer(state, action) { switch (action.type) { case ADD_ITEM: return { ...state, items: [...state.items, action.payload] }; case START_CHECKOUT: return { ...state, isCheckingOut: true, error: null }; case CHECKOUT_FAILED: return { ...state, isCheckingOut: false, error: action.error }; case RESET: return initialState; default: return state; } } const [cartState, dispatch] useReducer(cartReducer, initialState);你会发现这是一种把状态流动路径可视化的手段。只要打开这个reducer函数就能看到该业务中的所有状态变化而不是在十几个回调里东翻西找“谁动了error”。对于涉及多状态联动、操作步骤完整的业务场景比如订单流程、多步表单、上传任务reducer的收益非常明显。但我也要讲清楚边界它不适合所有场景。如果只是处理一个“是否在加载中”的布尔值硬写成reducer就会多出一堆无谓的action和type常量。我在带人时见过一个团队把简单的计数器也写成reducer结果是代码行数翻倍可读性反而下降。一个比较稳妥的判断标准是状态之间有关联、更新路径有分支时用reducer单个独立变量的简单开关useState就够了。2.4 useMemo和useCallback优化渲染先算清楚这笔账useMemo和useCallback常被当成一对兄弟因为底层机制完全一样依赖不变时直接返回上一次创建的结果。区别只在useMemo缓存的是某个计算值useCallback缓存的是函数本身的引用。先看useMemo。它最适合的场景是一个计算很重、且依赖变化频率低的值。比如列表中要根据关键词过滤几百条数据过滤逻辑本身不算太重但如果在每次渲染时都重新计算还是会造成不必要的开销。useMemo之后只要items和search两个依赖没变过滤结果就直接从缓存里取const visibleItems useMemo(() { return items.filter((item) item.name.includes(search)); }, [items, search]);useCallback解决的是“函数引用稳定性”问题。函数组件每次渲染都会创建一个新的函数对象如果这个新函数被当props传给子组件子组件即使被优化过也会因为props引用变化而被迫重新渲染。useCallback固定依赖后只有依赖变化时函数引用才会变const handleAdd useCallback((title) { dispatch({ type: ADD, title }); }, []);这里有个特别重要的预算意识使用这两个API本身是有成本的。useMemo要记住上一次的结果useCallback要维护依赖数组和上一次的函数引用两者都占用内存和额外比较的开销。如果被缓存的计算本身只花不到1毫秒或者被缓存的函数只在当前组件内部使用、根本不会传给子组件包一层反而更慢。我在实际项目里见过最典型的反面案例是把所有函数和计算全部包上useMemo和useCallback理由是“反正加上不会出错”。结果代码里布满了依赖数组任何一个依赖漏掉都会导致缓存失效排查一轮花的时间比省下的时间还多。正确的做法是先在DevTools里确认某个计算或子组件的重渲染确实是瓶颈再去考虑用这两个API。3. 一个完整案例把这些hooks全部串起来3.1 案例需求与模块划分光拆开讲每个hooks理解是不够的它们组合起来才是工作日常。我这边准备了一个演示项目名字就叫“模拟项目X”好了需求很清晰一个带筛选和主题切换的待办管理Demo。为什么不直接写传统to-do因为它能很自然地把useReducer、useContext、useRef、useMemo、useCallback全部放在同一个项目里你一眼就能看出它们各自的分工。需求一共四条。第一支持新增、删除待办支持点击单条待办切换完成状态。第二列表有三种筛选视图全部、未完成、已完成。第三右上角可以切换明暗主题主题要作用到整个页面。第四新增待办时输入框自动聚焦。模块划分上把数据层和展示层分开。待办数据用useReducer管理主题状态用useContext全局共享输入框聚焦用useRef筛选后的列表用useMemo子组件回调统一用useCallback稳定下来。这样每个hooks都找到了一个“非它不可”的位置。3.2 数据层useReducer与useContext的经典组合先建立ThemeContext单独一个文件管理避免把长代码全堆在App组件里const ThemeContext createContext({ theme: light, toggleTheme: () {} }); export function ThemeProvider({ children }) { const [theme, setTheme] useState(light); const toggleTheme useCallback(() { setTheme((t) (t light ? dark : light)); }, []); const value useMemo(() ({ theme, toggleTheme }), [theme, toggleTheme]); return ( ThemeContext.Provider value{value} {children} /ThemeContext.Provider ); } export function useTheme() { return useContext(ThemeContext); }这里最需要注意的是value那行useMemo。假如没有这行ThemeProvider每次重渲染都会构造一个新的value对象任何调用useTheme的子组件都会跟着重渲染。加上useMemo后只有theme和toggleTheme这两个依赖变化时value才更新子组件就能安静地只在主题真正切换时才重渲染。这个细节如果不写出来90%的人第一次都会忽略。待办数据则用useReducer管理。reducer只负责纯逻辑不碰任何外部状态这也是它和“直接在回调里修改state”最大的不同function todoReducer(state, action) { switch (action.type) { case ADD: return [ ...state, { id: Date.now(), title: action.title, done: false }, ]; case TOGGLE: return state.map((item) item.id action.id ? { ...item, done: !item.done } : item ); case REMOVE: return state.filter((item) item.id ! action.id); default: return state; } }reducer是纯函数这一点一定要养成肌肉记忆不要在case里直接修改state数组比如state.push(newItem)。这种原地修改不仅破坏了纯函数原则还会让React的批处理机制出现状态错乱而且问题极其隐蔽难复现。每次都要返回一个全新的数组或对象这是useReducer的底线。3.3 展示层useRef与useMemo的协作待办输入框需要“初始化聚焦”。这个需求用useRef加useEffect两行就解决function TodoInput({ onAdd }) { const inputRef useRef(null); useEffect(() { inputRef.current?.focus(); }, []); const handleSubmit (e) { e.preventDefault(); const title inputRef.current?.value.trim(); if (!title) return; onAdd(title); inputRef.current.value ; }; }筛选列表的部分把useMemo亮出来。如果没有useMemo每次父组件状态刷新这个过滤函数都要重新执行一遍待办数据一旦累积到几百条肉眼就能感受到卡顿。加上useMemo之后只要todos和filter这两个依赖没变结果就直接复用缓存const visibleTodos useMemo(() { if (filter active) return todos.filter((t) !t.done); if (filter done) return todos.filter((t) t.done); return todos; }, [todos, filter]);3.4 组合之后的整体结构把整个App的组件树组织成这样function App() { const [filter, setFilter] useState(all); const [todos, dispatch] useReducer(todoReducer, initialTodos); const handleAdd useCallback((title) dispatch({ type: ADD, title }), []); const handleToggle useCallback((id) dispatch({ type: TOGGLE, id }), []); return ( ThemeProvider div classNameapp TodoInput onAdd{handleAdd} / FilterBar filter{filter} onChange{setFilter} / TodoList todos{visibleTodos} onToggle{handleToggle} / /div /ThemeProvider ); }整体看下来你会发现在真实项目里hooks单个看起来都很简单难点全在组合。reducer给数据管理一个清晰的入口context让主题数据隐蔽地流到任意层级ref控制了一个不参与渲染的焦点memo和callback保证了渲染性能和回调稳定。这就是第二部分强调的“工程思维”不是背API而是在恰当的层级做恰当的事。4. 日常开发里最容易踩的坑问题与排查技巧4.1 一张问题速查表症状真正原因解决思路ref.current更新了但页面完全没反应ref的变化不触发渲染需要展示的内容交给stateref只保存“无须参与渲染”的实例数据组件明明在Provider内部useContext还是返回undefinedProvider和Consumer不在同一棵组件树或useContext没写在组件顶层检查Provider包裹层级用自定义Hook提前抛错定位StrictMode下useEffect执行了两次开发模式下React故意反复挂载在useEffect里写cleanup函数清理定时器、取消请求useMemo缓存的值始终不变化依赖数组漏写或写错用lint插件检查依赖必要时把多字段依赖写成对象展开useCallback包了子组件依然重渲染子组件没被优化或依赖引用不稳定给子组件包React.memo再检查依赖引用是否稳定reducer执行后UI没按预期更新reducer里原地修改了state对象永远返回新对象/数组用展开运算符配合map/filter4.2 排查疑难杂症时的三个抓手遇到这类问题我一般靠三个抓手React DevTools的Profiler面板、reducer日志回放、以及给useEffect加console.log验证依赖。Profiler面板能按时间轴直接告诉你哪位组件在何时重渲染比肉眼猜测快得多。前面提到的“Context value没稳定导致大量消费者重渲染”在Profiler里一眼就能看到同一时间段内大量组件同时闪黄顺着链路找到Provider再查value引用就定位了。reducer日志回放适合状态流的问题。我习惯在reducer函数第一行先打印action.type每次dispatch都会留下一条日志。状态出错时顺着日志回放看是哪个action触发了异常状态比对着代码盲查快很多。排查完记得把这些调试输出清掉不然控制台会被刷屏。给useEffect加console.log验证依赖是排查“effect为什么总是执行”的土办法虽然土但极其有效。在effect里打印相关数据源观察它们每次渲染是否变化就能很快定位是哪一项依赖不稳定导致的重复执行。用完之后把console.log删掉就行。4.3 几个值得养成的习惯第一个习惯自定义Hook里带防御性判断。我写useTheme的时候一定会判断“如果没有Provider上下文就抛错”。多人合作时总有新同学漏包Provider这种错误的出现频率远超想象。在自定义Hook里加一个throw报错信息会直接点明“useTheme必须在ThemeProvider内使用”定位成本从半小时降到五分钟。第二个习惯reducer的action不要在代码里散落字符串。用一个ActionTypes常量文件集中维护后面加功能时不会出现“拼错单词静默失败”的尴尬。真报错还好最怕的就是action的type拼错了switch语句走default分支页面一点反馈都没有但要排查很久。第三个习惯把“要不要用useMemo/useCallback”当成性能决策而不是习惯动作。先跑一次Profiler确认确实是瓶颈再动手优化。没有分析就直接包一层通常是把代码复杂度和阅读成本同时加了上去性能却没什么变化。我个人在实际项目里试过很多次最管用的学习方法就是把一个线上模块从useState迁移到useReducer或者把一个组件树里的props逐层传递改成Context。改完再对比两次代码的差异很多东西一下子就通了。用这个项目X的Demo练手也是一样先把完整代码抄一遍再手动替换其中某个hooks观察行为变化比看十遍教程都有用。后面如果想继续往更深走useLayoutEffect、useImperativeHandle、自定义Hooks生态还有很大空间但把这一课里面的五个hooks扎实用好已经足够撑起绝大多数业务场景了。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
