1. 先聊聊 stateReact 应用的灵魂与命脉1.1 为什么写 state 而不是写组件做了几年 React 开发我越来越觉得真正决定项目质量下限的不是组件写得有多漂亮而是state 管得怎么样。状态设计得合理业务逻辑自然清晰bug 数量直线下降状态设计得混乱哪怕组件层用了再花哨的设计模式后期维护依然是一场灾难。state 这个词本身就是一个状态容器的概念。React 的核心理念是 UI f(state)界面只是状态的一层投影。你改状态React 帮你把界面更新掉你不改状态组件写得再复杂也不会自己动一下。所以与其天天研究 JSX 怎么组织、样式怎么封装不如先把 state 怎么建模、怎么流转、怎么更新这件事想透。这篇文章不是官方文档的复述更像是我这几年在实际项目里踩过的坑、总结出的套路。我会从最常用的 useState 讲到 useReducer、useEffect再聊到跨组件状态管理和服务端状态缓存最后整理一份高频问题排查清单。适合有一定 React 基础、想系统梳理状态管理思路的开发者新手也能从中找到可直接抄作业的写法。1.2 先想清楚一份状态该放在哪里我见过很多新人在刚接触 React 时习惯把所有数据都塞进一个全局 store理由是反正都要用。结果项目跑起来后任何一个小改动都会触发大范围重渲染根本分不清是哪个状态导致了性能问题。一个朴素的判断原则能用本地状态解决的就不要提升到全局。状态放的位置越低影响范围越小组件就越容易理解和复用。反过来说如果两个兄弟组件需要共享同一份数据那才考虑把状态提升到它们的公共父组件再往上只有真正跨页面、跨路由、需要长期保留的数据才值得放到全局状态管理库里。状态位置决定渲染范围渲染范围决定性能成本。这是所有状态管理策略的第一条底层逻辑。2. 从 useState 到 useReducer本地状态的两板斧2.1 useState 的正确打开方式useState 是最常用的状态 Hook很多人觉得它简单到没什么可讲的。但正是这个太简单的 Hook藏着不少容易忽略的细节。先看初始值。useState 的参数只在组件首次渲染时使用一次之后完全失效。如果初始值需要计算比如从 localStorage 读取、解析 JSON、做复杂换算直接写useState(expensiveFunction())会在每次渲染时都执行一次这个函数虽然结果不会被使用但计算成本白白浪费了。正确写法是传入一个函数const [user, setUser] useState(() { const raw localStorage.getItem(user); return raw ? JSON.parse(raw) : null; });React 会记住这个函数只调用一次真正的惰性初始化。我实测过一个场景读取一个几百 KB 的配置并解析用函数式初始化首屏渲染时间能明显降下来。再看更新方式。当新状态依赖旧状态时永远优先使用函数式更新setCount((prev) prev 1);直接写setCount(count 1)在大多数情况下没问题但遇到连续更新、批量更新、被 useEffect 闭包捕获时很容易拿到过期值。函数式更新的本质是把计算逻辑交给 React 在最新状态下执行从根本上避免闭包陷阱。还有个易忽略的点useState 的更新是浅合并吗不是。useState 完全替换旧值不像类组件里 setState 那样自动合并对象。所以更新对象状态时要手动展开const [form, setForm] useState({ name: , age: 0 }); setForm((prev) ({ ...prev, name: 张三 }));如果对象层级深、字段多每次都手写展开很容易漏也容易造成嵌套结构混乱。这时就该考虑用 useReducer 或把状态拆成多个单一字段。2.2 什么时候该换 useReduceruseReducer 不是一个更高级的 useState它们是两套不同粒度的状态工具。useState 适合独立、简单、更新频率低的原子状态而 useReducer 适合多个字段相互关联、更新逻辑复杂、状态流转有规则的场景。我举个很典型的例子一个购物车。里面有商品列表、选中项、总价、优惠券、库存锁定等字段用户每次操作加购、删减、选优惠券、清空都涉及多个字段的联动更新。如果全用 useState 管理每个操作都要写好几行 setXxx逻辑分散在事件处理函数里看半天才知道一个动作到底改了哪些状态。换成 useReducer 后所有更新逻辑集中到 reducer 函数里组件只负责派发 actionconst initialState { items: [], selectedIds: [], totalPrice: 0, coupon: null, }; function cartReducer(state, action) { switch (action.type) { case add: return { ...state, items: [...state.items, action.payload], totalPrice: state.totalPrice action.payload.price, }; case remove: return { ...state, items: state.items.filter((item) item.id ! action.payload.id), totalPrice: state.totalPrice - action.payload.price, }; default: return state; } }组件里只写dispatch({ type: add, payload: product })不用关心具体怎么改。reducer 是纯函数参数确定、结果就确定特别适合单元测试。把 reducer 单独抽出来用一个文件把状态变迁的全部规则列清楚这就是一张可维护的状态流转图。团队协作时新成员读 reducer 比追着一个个 setState 看要高效得多。选择 useReducer 的另一个理由是性能。多个关联字段集中在一个对象里通过 dispatch 一次性更新能让 React 在批量处理更新时更高效减少中间态的额外渲染。当然这个差别在小型应用里几乎感知不到但到了复杂业务模块收益是实打实的。3. useEffect 与派生状态副作用管理的核心细节3.1 依赖数组是一门玄学useEffect 是 React 函数组件里处理副作用的主入口加载数据、订阅事件、手动操作 DOM、记录日志全都靠它。但依赖数组的写法我见过太多人踩坑。依赖数组为空[]表示只在挂载后执行一次。新手最常犯的错是在这个 effect 里读取了某个状态但没把它写进依赖。比如页面加载时要根据 userId 拉取用户信息useEffect(() { fetch(/api/user/${userId}).then(...); }, []);userId 变了请求不会重新发。这就是著名的依赖缺失问题。 React 官方 lint 规则 eslint-plugin-react-hooks 的 exhaustive-deps 会直接报警我强烈建议项目开启这条规则不然很容易在不知情的情况下引入过期值 bug。依赖数组也不是写进去就万事大吉。如果依赖里放了对象或数组而它们又在每次渲染中被重建会导致 effect 反复执行甚至出现死循环。一个经典场景const [config, setConfig] useState({ page: 1, size: 10 }); useEffect(() { fetchList(config); }, [config]);每次请求回来后 setState 更新了列表但 config 对象本身如果被重新创建比如从 props 计算而来effect 会再次触发。解决方案是拆分依赖把原始值作为依赖useEffect(() { fetchList(config.page, config.size); }, [config.page, config.size]);或者用 useMemo 保证对象引用稳定这个后面细说。3.2 竞态问题必须有处理机制前端开发里竞态问题非常隐蔽尤其在异步数据请求场景。页面发起请求 A用户很快操作又触发了请求 BA 的返回比 B 晚到达结果 A 的数据覆盖了 B 的数据界面显示错乱。这在快速切换 Tab、搜索防抖、列表筛选时极其常见。处理竞态的两种主流方案一种是标志位另一种是 AbortController。标志位写法很直观useEffect(() { let canceled false; fetchData().then((data) { if (!canceled) { setData(data); } }); return () { canceled true; }; }, [fetchData]);组件卸载或依赖变更时取消标志被置为 true旧请求的回调自然失效。这种写法兼容性好任何环境下都能用。AbortController 是浏览器原生能力能真正中断网络请求useEffect(() { const controller new AbortController(); fetch(/api/items?${query}, { signal: controller.signal }) .then((res) res.json()) .then(setData) .catch((err) { if (err.name ! AbortError) { setError(err); } }); return () controller.abort(); }, [query]);注意 AbortError 会被捕获进 catch 里要主动忽略否则每次切换查询都会报一个错误。我建议能用 AbortController 的地方尽量用它既取消了无效响应又释放了网络连接对性能和用户体验都有帮助。3.3 派生状态不要硬塞进 useState有一种状态不需要使用 Hook 管理它就是可由已有状态计算出的值。比如列表数据和过滤条件已知筛选结果就是派生状态const [list, setList] useState(allItems); const [keyword, setKeyword] useState(); const filteredList useMemo(() { return list.filter((item) item.name.includes(keyword)); }, [list, keyword]);很多新手会把 filteredList 用 useState 存起来在 effect 里监听 list 和 keyword 变化再 setFilteredList。这就引入了多份事实来源一旦某次 set 漏了页面数据就对不上。React 官方也建议能计算出来的状态就不要额外存储。用 useMemo 做派生状态React 会在依赖变化时重新计算只在真正需要时才执行计算逻辑比直接在渲染函数里写内联计算更可控。记住一个判断口诀能算的别存。4. 全局状态与服务端状态两个容易混为一谈的场景4.1 Context 和第三方状态库的取舍跨组件共享状态很多人的第一反应是 React Context。Context 确实适合传递低频、稳定的数据比如主题、用户信息、语言包。但由于 Context 的更新机制当 Provider 的 value 变化时所有消费该 Context 的组件都会重渲染无论它们是否真的关心变化的那部分数据。我之前维护过一个后台项目把用户操作权限表放进了全局 Context结果每次登录信息刷新整个页面所有子组件都跟着重渲染。状态量小的时候看不出问题一旦业务组件数量上来了卡顿感就很明显。这时候有两种选择一是把 Context 的 value 用 useMemo 包裹尽量缩小变化范围二是引入专业的状态管理库比如 Zustand、Redux Toolkit 或者 Jotai。以 Zustand 为例它通过 selector 精确订阅只让真正使用某段状态的组件重渲染性能表现比裸用 Context 好很多import { create } from zustand; const useStore create((set) ({ user: null, permissions: [], setUser: (user) set({ user }), setPermissions: (permissions) set({ permissions }), })); function UserName() { const name useStore((state) state.user?.name); return span{name}/span; }只有当 user.name 变化时UserName 才会重渲染其他组件不受影响。选型时要同时考虑团队熟悉度、包体积、调试工具不要盲目追新。如果只是三五个组件共享状态Context 完全够用一旦状态变多、更新频繁、消费组件分布广就该引入专业库了。4.2 服务端状态和客户端状态要分开管项目中另一类常见错误是把接口返回的数据一股脑放进全局 store然后在组件里手动管理 loading、error、重新请求、缓存。这套逻辑重复写几遍后你会发现每一处都长得差不多还特别容易出 bug。服务端状态server state的本质和客户端状态client state不同服务端数据有自己的生命周期可能被其他人修改需要重新校验、失效重取、缓存复用。这些逻辑不该每次手动实现应该交给专门的数据请求库比如 TanStack Queryreact-query或 SWR。以 TanStack Query 为例它把请求数据的完整状态机收编为一个 Hookconst { data, isLoading, error, refetch } useQuery({ queryKey: [user, userId], queryFn: () fetchUser(userId), });底层自动做了缓存、去重、失败重试、窗口聚焦重新请求。最实用的地方是key 驱动的缓存同一个 queryKey 被多个组件使用时只会发一次请求。用户改了资料后调invalidateQueries([user])所有用到该 key 的组件自动重新拉取。用了请求库之后全局 store 就只需要管客户端状态比如筛选条件、弹窗开关、临时表单。这个分层在大型项目里真的能救大命我接手过一个老项目全局 store 里混了一堆接口返回的榜单数据页面一刷新全失效排查起来非常痛苦。4.3 状态持久化与记忆恢复有些状态需要跨会话保留比如用户偏好、上次浏览位置、草稿箱内容。一个常见的做法是手动监听状态变化再写 localStorageconst [draft, setDraft] useState(loadDraft); useEffect(() { localStorage.setItem(draft, JSON.stringify(draft)); }, [draft]);这套逻辑本身没问题但要注意两点第一draft 初始值一定要从 localStorage 同步读取并做好容错JSON.parse 遇到非法字符串会直接抛错必须包 try/catch第二写 localStorage 是同步操作频繁写入大数据会对主线程造成阻塞最好加个防抖或节流或者用专门的存储 Hook比如 useLocalStorageState封装。我个人的做法是封装一个通用工具function usePersistedState(key, defaultValue) { const [state, setState] useState(() { try { const raw localStorage.getItem(key); return raw ! null ? JSON.parse(raw) : defaultValue; } catch { return defaultValue; } }); const setAndPersist (value) { setState(value); localStorage.setItem(key, JSON.stringify(value)); }; return [state, setAndPersist]; }使用时传入 key 和默认值再也不用担心序列化异常的问题。注意不要在服务端渲染场景直接访问 localStorage要加 typeof window 判断否则会直接报错。5. 性能优化与渲染机制搞懂 state 变更后发生了什么5.1 为什么组件更新比你预期的更频繁React 组件的更新不是哪里变了改哪里而是默认自上而下重渲染。父组件更新其所有子组件都会跟着重新执行 render 函数。此时子组件内部如果有繁重的计算、复杂的 DOM 结构就会明显卡顿。很多新手以为 setState 之后只有目标组件会渲染这是误解。我上个月优化一个表格页发现每次输入框打字整页上千个单元格都在重渲染就是因为输入框状态写在页面顶层而表格没有做隔离。常用的优化手段是 React.memo。它用浅比较来控制组件是否重渲染const ExpensiveTable memo(function ExpensiveTable({ data }) { // 只有当 data 引用变化时才重渲染 return table{/* ... */}/table; });但 memo 不是银弹。如果父组件每次渲染时传入的 props 都是新创建的对象或函数memo 的浅比较永远不通过优化直接失效。比如ExpensiveTable data{tableData} onRowClick{(row) handleClick(row)} /这里的 onRowClick 每次都是新函数memo 形同虚设。解决办法是配合 useCallback 固定函数引用const handleRowClick useCallback((row) { handleClick(row); }, [handleClick]);useCallback 返回的函数引用只有在依赖变化时才改变这样 memo 才能真正发挥拦截作用。同理传给子组件的对象用 useMemo 固定引用。核心思路是让不变的依赖使用不变的引用。5.2 追踪频繁渲染的两个实用小工具排查性能问题时光靠肉眼观察很不可靠。我习惯用 React DevTools 的 Profiler 面板录制一段交互它会用彩色条展示哪些组件发生了渲染、渲染耗时多长。颜色越黄越红说明该组件的渲染成本越高。再配合一个经典技巧在组件根部临时加一行代码useEffect(() { console.log(${componentName} rendered); });空依赖数组的 effect 只会在挂载后打印一次。如果运行后打印多次说明该组件在反复重渲染需要检查是哪一层触发的、props 是否稳定。另外注意 useState 的更新机制在异步事件和 useEffect 中多次 setState 会被批量合并为一次渲染。但在 Promise 链、原生事件、setTimeout 中React 18 之前是每次更新各自渲染React 18 开始自动批处理。升级到 React 18 后再遇到一次点击导致很多次渲染的问题通常不是批量机制的问题而是状态建模和引用稳定性没有做好。5.3 Hooks 状态更新的几个常见幻觉关于 state 更新流传着几个常见误区我在这里一一说破。第一setState 之后立刻读 state 能拿到新值。不行。state 的更新是异步的React 会在调和阶段批量处理。想要在更新后拿到最新值应该依赖 useEffect 或者在事件函数里计算好新值再使用。第二对象状态只改一个字段也要传整个对象。是的必须传整个对象。很多人漏写了展开符导致对象里的其他字段全部丢失。这是 React 新手最常见的 bug 之一。第三setState 传入相同值就不会触发渲染。React 会对基本类型做 Object.is 比较如果相同确实跳过渲染。但对象数组每次都是新引用哪怕内容一模一样也会触发渲染。所以如果列表数据来自服务端尽量做去重和引用稳定处理避免无意义渲染。第四useState 只能存简单数据。其实它可以存任意值包括函数和 DOM 元素引用只是存函数时要特殊处理初始化方式因为懒初始化会把函数当作工厂函数执行。如果你确实要存函数比如一个回调句柄可以这样const [fn] useState(() () console.log(hi));或者直接全部丢进 useRef它才是存可变且不触发渲染的数据的最佳容器。6. 自定义 Hooks把状态逻辑从组件里抽出来的最佳实践6.1 自定义 Hook 的封装原则很多人学了 Hooks 之后组件里的代码依然越写越长因为把所有逻辑都堆在组件函数体内。其实自定义 Hook 就是为了解决这个问题而存在的。它允许你把一套状态 相关操作整体提取出来在多个组件间复用。封装时我一般遵循三条原则。第一以 use 开头命名这样 React 的 lint 规则才能正确识别它是一个 Hook。第二只在顶层调用 Hooks不要包裹在 if 或循环中否则会产生调用顺序错乱。第三返回值尽量是稳定的引用用 useMemo 或 useCallback 固定方便下游组件做性能优化。我拿一个典型的搜索表单举例封装一个 useSearchfunction useSearch(initialKeyword ) { const [keyword, setKeyword] useState(initialKeyword); const [debouncedKeyword, setDebouncedKeyword] useState(initialKeyword); useEffect(() { const timer setTimeout(() { setDebouncedKeyword(keyword); }, 300); return () clearTimeout(timer); }, [keyword]); return { keyword, setKeyword, debouncedKeyword, }; }组件里只需要调用这个 Hook防抖、状态、清理逻辑全部内部解决。想换防抖时间、想改触发方式直接在 Hook 内部调不影响任何使用方。6.2 用自定义 Hook 处理页面级复杂状态自定义 Hook 不只是用来做小封装它在页面级复杂状态建模里更强大。我做过一个内容管理后台的列表页状态包括分页参数、排序字段、筛选关键词、选中行、批量操作模式。以前这些全写在页面组件里一百多行 setState 连在一起后来全部收进一个 useListPage Hook页面组件瞬间清爽。设计这类大 Hook 时注意把展示数据和操作命令分开。展示数据通过一个对象返回操作命令通过方法返回function useListPage({ fetchList }) { const [page, setPage] useState(1); const [size, setSize] useState(10); const [filters, setFilters] useState({}); const [selectedRows, setSelectedRows] useState([]); const [loading, setLoading] useState(false); const [list, setList] useState([]); const load useCallback(async () { setLoading(true); try { const data await fetchList({ page, size, ...filters }); setList(data.items); } finally { setLoading(false); } }, [page, size, filters, fetchList]); useEffect(() { load(); }, [load]); return { page, size, filters, selectedRows, loading, list, setPage, setSize, setFilters, toggleRow, clearSelection, reload: load, }; }注意这里把 load 用 useCallback 固定然后 effect 依赖 load这样只有依赖真正变化时才重新请求。如果 fetchList 本身是父组件传入的函数且不稳定这会引发连锁问题因此对传入 Hook 的函数也要要求调用方做 useCallback 或 useMemo 稳定性处理。6.3 别把 Hook 滥用成万能工具自定义 Hook 很好用但不要矫枉过正。有些逻辑并不适合抽进 Hook比如只在一个组件内使用、且只有三五行代码的状态更新。强行抽成 Hook 反而增加阅读链路让代码跳来跳去。还有一个容易踩的坑多个组件复用同一个自定义 Hook状态是各自独立的。很多人误以为调用了同一个 Hook两个组件就共享状态。实际上 Hooks 的每一次调用都会创建独立状态只有把状态提升到 Context 或 store 层才能真正共享。如果你想让两个组件共用一份状态应该让 Hook 内部使用全局 store或者在 Hook 参数里传入共享的状态和操作。我见过一个项目里团队把所有 setState 都包了一百多个自定义 Hook结果排查问题时要在十几个文件里来回跳。最佳实践是状态逻辑有明确复用时才抽 Hook否则直接在组件里写可能更清晰。7. 状态设计中的常见 bug 与排查技巧7.1 无限循环渲染九成是依赖数组的锅这是 React 使用中最让人头疼的问题之一浏览器卡死、控制台疯狂刷日志、页面白屏。出现的根本原因是某个 effect 修改了它的依赖导致 effect 再次执行再次修改依赖形成闭环。最典型的是这样const [count, setCount] useState(0); useEffect(() { setCount(count 1); }, [count]);setCount 让 count 变化count 变化又触发 effect 再次执行。这版代码一运行页面直接卡死。排查时先把 effect 里的 setState 注释掉确认是不是它引发的闭环再检查依赖数组里是否放入了由该 effect 自己创建并修改的状态最后考虑用函数式更新打破依赖比如setCount((prev) prev 1)让 effect 的依赖里不需要 count。还有一种隐蔽的循环来源effect 里调用了某个函数而这个函数内部又触发状态更新且这个函数引用不稳定被写进了依赖。可以用 useCallback 固定函数引用来解决。7.2 拿到过期状态Stale Closure 的完整攻略闭包陷阱在使用 Hooks 时几乎人人都会遇到。核心原因是每次渲染都有自己独立的 props 和 state而 useEffect 的回调会捕获它被创建那一次渲染的变量值。一个典型案例function Counter() { const [count, setCount] useState(0); useEffect(() { setInterval(() { console.log(count); setCount(count 1); }, 1000); }, []); }这里 setInterval 的回调捕获了 count 的初始值 0之后每秒执行的都是setCount(0 1)count 永远停在 1。即使使用函数式更新setCount(prev prev 1)能让数值正确累加但console.log(count)打出来的仍然一直是 0。正确解法是使用函数式更新并摆脱对被捕获变量的依赖useEffect(() { const timer setInterval(() { setCount((prev) { const next prev 1; console.log(next); return next; }); }, 1000); return () clearInterval(timer); }, []);如果回调里还需要读取某个 props 或 state就依赖数组里加上它让 effect 重新创建定时器或者用 useRef 保存最新值回调统一从 ref 读取这是处理事件监听里读最新状态的通用祖传秘籍。7.3 关于 Hooks 规范lint 规则是救命恩人React 官方推荐在 eslint 配置中开启 react-hooks/rules-of-hooks 和 react-hooks/exhaustive-deps 两个规则。前者检查 Hooks 调用顺序后者检查依赖完整性。我见过太多因为不遵守第二个规则导致的神秘 bug比如页面偶尔不更新、数字偶尔少加、请求偶尔不触发。拿 exhaustive-deps 规则来说它不仅能告诉你哪个依赖缺失还能在你补完依赖导致死循环时帮你发现问题。很多开发者被这条规则烦到想关掉但我建议不要关而是理解它背后的逻辑它逼你保证 effect 的输入输出是自洽的。如果你觉得依赖补全后会出问题往往说明逻辑本身设计得不合理比如 useEffect 里使用了一个频繁变化的函数应该用 useCallback 去稳定它而不是反过来关掉 lint 报警。7.4 快速定位状态问题的排查顺序当你发现界面显示不对时我推荐按这个顺序排查先看状态本身对不对再看渲染时机对不对最后看引用是否稳定。第一步在关键组件里加上 console.log 直接打印 state或者在 React DevTools 的 Components 面板里查看当前 state 值判断数据源是否正确。第二步确认该状态是否在正确的时机更新比如是否在 effect 里异步更新、是否被防抖延迟、是否在批量更新中被覆盖。第三步如果状态值正确但界面不刷新检查 props 引用是否稳定、是否被 React.memo 拦截、是否用了 shouldComponentUpdate。这套排查路径陪我解决过大量疑难杂症比一上来就怀疑性能优化要靠谱得多。状态管理问题的根源大多不是React 出 bug 了而是某个环节的状态没有按预期流转。8. 状态设计路上的几条经验总结状态管理的核心不是某个库或者某个 API 用得多熟练而是建模思想。我的个人体会是状态要尽量扁平、尽量局部、尽量单一。能拆开的别糅在一起能算出来的别存储能放本地的别提升到全局。还有一条关于团队协作的经验无论用 useState、useReducer 还是第三方库都要在项目里固定一套状态管理的写法。比如规定所有的异步请求必须走请求库跨页面共享状态必须放进指定的 store 目录一个页面级别的状态统一封装为自定义 Hook。没有规范的项目状态管理会迅速失控而规范的意义不是限制自由度是让每个开发者都少踩别人踩过的坑。最后分享一个实践技巧写复杂功能前先在纸上画出状态流转图标注哪些事件触发哪些状态更新哪些组件消费哪些状态。这个过程花十分钟却能帮你提前暴露一半以上的设计问题。真正到了写代码的阶段你会发现 state 的管理已经顺畅很多了。