看到标题“rea”很多做前端的朋友应该都不陌生这就是 React 在社区里、在代码仓库里最常用的简称。但正是因为太常见了反而容易让人忽略它背后那一整套完整的前端工程化思维。这篇内容我不打算讲官方文档上已有的 API 清单而是想换个角度从“拿到一个项目标题、需求只有一句话”时一个老手是怎么思考、怎么拆解、怎么一步步把页面搭起来、把状态管好、把性能抠出来、最后踩坑排雷的完整过程。这些经验大多来自实际开发中的复盘希望对正在用 React 做项目的你有一点参考价值。无论你是刚接触 React 的初学者还是已经用了两三年但总觉得在“照着文档写组件”的开发这篇文章都会有点用处。我会从设计思路、工程化选型、核心实现再到问题排查完整过一遍 React 项目的落地流程。每一条都不会是空泛的理论而是可以照着做、照着调的东西。1. 拿到需求别急着写代码先理清组件边界和状态模型很多初学者拿到项目需求第一反应是“这个页面长这样我来照着写”。框架本身确实允许你这么快开始但实际项目里这种做法的返工率极高。React 的核心理念是“以组件为单位构建 UI”但组件怎么拆、状态放哪儿、数据怎么流动这些决策比写 JSX 本身重要得多。1.1 组件拆分按职责而不是按视觉分区我见过不少项目组件目录是照着设计稿的视觉区块建的一个 Header 组件、一个 Sidebar 组件、一个 Content 组件。这种方式的直观问题在于视觉区块和业务职责往往并不一致。更好的做法是按业务职责和复用粒度来拆。比如一个电商后台的订单列表页按照视觉区块你会拆成顶部筛选区、表格区、分页器、弹窗详情。但按职责来拆应该是OrderFilter负责筛选条件状态、OrderTable负责列表数据和列配置、OrderDetailDialog负责详情展示和操作交互、Pagination通用组件。这样拆的好处是每个组件的 props 和 state 都相对清晰改动一个业务逻辑时不需要在多个“视觉区块”里来回找。判断一个组件职责是否合理有一个很朴素的标准如果你要给这个组件写一段“它负责什么”的描述这段描述是否超过两句话。超过两句话大概率这个组件管得太多了应该再拆。1.2 状态模型设计哪些放本地 state哪些放全局 store状态管理是 React 项目里的争议重灾区。我见过一个中型项目把所有的数据都放进全局 store结果组件刷新、内存占用、调试成本全线告急也见过相反的情况连登录用户信息都放在组件本地 state 里导致刷新页面就丢状态。我的经验是分三挡来决策第一挡组件本地 state只影响当前组件 UI 的临时状态比如弹窗开合、选项卡索引、表单某个字段的临时值。这类状态用useState就好根本不需要全局化。第二挡跨组件共享但不需要持久化的数据比如多个兄弟组件都要读某个筛选条件或者某个计算结果被多个地方复用。这时候用useContext配合useReducer或者直接提升 state 到最近的公共父组件已经足够。第三挡需要跨页面共享、涉及复杂数据交互、或者需要缓存的服务端数据这才需要真正的全局 store。一个很容易被忽略的原则是能放本地的就不要放全局能放近的不要放远的。全局状态越少项目的可维护性越高。这个原则没有变化任何时候做 React 项目都适用因为全局数据一多必然面临“这个状态是从哪来、要被谁改、当前是什么值”的三连拷问。1.3 从数据流反推组件层级确定状态模型之后再顺着数据流把组件层级排出来比先画视觉再想数据要顺得多。核心思路是找一个状态需要被哪些组件读取找到这些组件的最近公共父组件让状态待在父组件里通过 props 向下传递。举一个实际例子筛选条件区域和一个结果列表区域其实是联动的。筛选条件的某个值变更列表需要重新请求并展示。最合理的结构是把筛选条件和列表数据同时放在它们共同的父组件里父组件持有筛选条件的 state 和列表数据的 state传递一个onFilterChange给筛选组件传递data给列表组件。这个结构简单清晰两个子组件完全可以独立复用。2. 工程化选型有讲究脚手架、路由、请求层和样式方案一个 React 项目的工程化选型直接决定了项目的开发体验和长期可维护性。这部分我不会推荐“唯一正确答案”因为不同的团队风格、项目周期、部署环境正确答案不一样。我重点是讲明白每个选型背后的考量这样你拿到自己的项目时能做出适合自己的判断。2.1 初始化方式为什么你仍然需要一个构建工具现在初始化 React 项目最主流的命令已经不是手动配置 Webpack 了。社区推荐的方式是用官方脚手架或社区维护的起步模板它们把构建、转译、热更新、代码规范都集成好了。我在实际项目里更看重的是模板对 TypeScript 的支持是否开箱即用因为类型系统在项目规模上去之后带来的收益是实实在在的。如果一个模板还要你自己去配置 tsconfig、编辑器和构建插件之间的集成那我建议换一个模板省下的时间用来写业务逻辑更划算。2.2 路由设计不是加一个库那么简单React 应用大多是单页富应用路由库是很基础的一层。选路由方案时我特别关注三点是否支持嵌套路由对应的组件嵌套结构。因为实际业务里一个主布局下面往往有多级页面路由的嵌套结构如果能和组件树的结构一一对应理解成本会大幅降低。是否支持动态路由和按需加载。大型项目的首屏性能很大程度依赖路由级代码分割。路由参数的类型安全。路由设计上有一个容易被忽略的细节把路由配置收敛到一个独立文件里集中管理。哪怕刚开始只有两三个页面也建议这么做。因为后续增加页面、权限控制、面包屑导航、页面标题设置都可以依托这一份配置来实现。我自己习惯在每个页面配置里带上title、icon、permission等元信息字段后续做导航菜单和权限拦截时就能直接用不用额外维护一份重复的菜单配置文件。2.3 数据请求层fetch 封装、缓存与请求状态处理数据请求层是 React 项目里最容易写乱的部分。我见过那种在组件里到处写 fetch 然后 .then 回调最后全项目布满了 loading 状态的方式——不是说不能用但项目一复杂就很容易乱。更稳妥的方式是封装一个统一的请求客户端基于浏览器原生 fetch 或者基于 XMLHttpRequest 的库封一层统一处理请求头的注入比如认证 token。响应拦截比如统一处理后端返回的 codedatamessage 结构。错误处理网络错误、业务错误、登录过期跳转登录页。重复请求取消。请求状态的管理我建议用自定义 Hook 的方式收敛比如useFetchList、useMutation这类对外暴露data、loading、error、refresh等方法的封装。组件只用关心自己的数据从哪来请求被打到哪里、怎么重试、取消请求这些问题统一封装在前端。2.4 样式方案CSS Modules 还是 CSS-in-JS开发时这个选择的优先级很高跟前端项目的兼容和团队协作关系很大。我个人的经验是对大多数中小型项目CSS Modules 通常是最稳妥的方案因为它不引入额外的运行时样式的局部作用域可以避免写长选择器互相覆盖而且写起来就是普通 CSS团队成员上手成本很低。CSS-in-JS 方案的优点是样式和逻辑在同一个文件里动态样式处理很灵活。但运行时开销和调试成本还是现实问题。如果是组件库或需要大量动态样式的项目CSS-in-JS 更有优势具体只能看团队的项目情况定没有放之四海皆准的标准答案。3. 核心细节解析Hooks 落地的几个硬核技巧React 16.8 之后函数组件加 Hooks 已经是绝对的主流写法。但 Hooks 的粒度怎么控制、依赖数组怎么填、副作用怎么处理才是从“会用”到“用得好”的分水岭。3.1 useState 的惰性初始化和函数式更新useState有个容易被忽略的细节初始值如果是通过复杂计算得到的应该传一个函数进去让它只在组件首次渲染时执行一次而不是每次渲染都重复算。这个优化在初始值是数组、要经过 map/filter 等遍历计算时收益是肉眼可见的。另一个重要细节是依赖前一个状态更新时应该用函数式更新的形式。看这个场景const [count, setCount] useState(0); // 不推荐当多次连续调用 setCount 时会基于同一个旧值计算 setCount(count 1); setCount(count 1); // 推荐每次都是基于最新值计算 setCount(prev prev 1);虽然 React 的批处理机制能缓解不少问题但在复杂交互下比如快速点击、异步回调中更新函数式更新是更稳的写法。3.2 useEffect 的依赖数组不是随便填的useEffect的依赖数组是新手最容易踩的坑。不填依赖数组每次渲染都执行、填空数组只在挂载时执行一次、填部分依赖可能漏掉某个变量三种情况各自都有问题。最实用的原则依赖数组里应该列出 effect 中引用的每一个响应式值。如果你发现依赖数组里东西太多导致 effect 频繁触发正确的做法不是强行忽略依赖而是重新审视代码结构把多个职责拆开。一个 effect 只做一件事依赖就会更清晰。还有一个经常踩的坑是在 effect 里使用了某个 props 或 state但依赖数组里漏掉了它。结果就是 effect 执行时用的还是旧值这个问题排查起来很隐蔽因为不是每次都会复现。所以我现在写代码有个习惯写完之后会先看一眼 effect 里引用了哪些外部变量再对照依赖数组确认它们是否都列出来了。3.3 useMemo 和 useCallback为性能服务但别滥用很多开发者一听说性能优化就开始到处塞useMemo和useCallback。但这两个 API 是有代价的它们本身也是有一定开销的需要额外的内存保存依赖、需要比对依赖是否变化。如果一个计算本身很轻量或者一个函数本身很稳定就不值得用它们去包一层。性能优化第一步永远是分析真正的瓶颈而不是凭直觉盲优化。合理的场景是useMemo复杂数据转换、列表过滤排序、大对象深度对比等。useCallback需要传递给被React.memo包裹的子组件的函数或者作为 effect 依赖的函数。判断取舍的一个技巧是先把代码写清楚性能测试发现确实有问题了再针对性地加记忆化。盲目加 useMemo 会让代码可读性下降而且依赖数组本身也是一个心智负担。3.4 自定义 Hooks把逻辑抽到组件之外但不要把组件拆得太碎自定义 Hooks 是 React 工程化项目里提升复用度的最佳手段之一。比如一个有“输入内容并防抖请求”需求的搜索框通常的做法是直接写到组件里但更合理的做法是把它抽成useDebouncedSearch。这样搜索逻辑的细节被藏起来组件里只需要关心要不要显示 loading以及拿到的列表数据。不过自定义 Hooks 也有一个边界问题不要把所有东西都拆成 Hooks。如果一个 Hook 只被一个组件使用而且里面的逻辑很简单那抽出来反而增加跳转成本。先写在组件里发现有一大坨逻辑导致组件难以阅读时再抽出去这样的节奏最自然。4. 实操过程从零到一搭建一个 React 项目完整步骤演练这一部分我用一个模拟项目 X企业内部的数据分析看板前端为例带你完整走一遍从初始化到核心功能实现的流程。这个项目规模适中包含了列表页、详情页、表单提交、数据可视化图表展示非常适合用来演示 React 工程化的完整套路。4.1 项目初始化和目录结构规划第1步是用你选定的脚手架初始化项目然后在项目根目录下规划目录结构。我的习惯是按下图这样划分src/ ├── api/ # 接口请求函数 ├── assets/ # 静态资源 ├── components/ # 通用业务组件 ├── hooks/ # 自定义 Hooks ├── layouts/ # 布局组件 ├── pages/ # 页面级组件 ├── routes/ # 路由配置 ├── stores/ # 全局状态 ├── styles/ # 全局样式 ├── utils/ # 工具函数 └── types/ # 类型定义这个划分不一定适合所有项目但有一件事很重要目录结构在项目第一天就定好。后期再调整目录的成本非常高因为每个路径引用都要改动一遍。4.2 路由层配置和按需加载路由配置我倾向于把所有路由收敛到一个数组里集中管理然后用循环生成路由。这样页面组件维护在一个文件里新增页面时只需要加一段配置。// routes/index.js const routes [ { path: /dashboard, component: () import(/pages/Dashboard), meta: { title: 数据看板, requiresAuth: true } }, { path: /orders, component: () import(/pages/Orders), meta: { title: 订单列表, requiresAuth: true }, children: [ { path: detail/:id, component: () import(/pages/OrderDetail), meta: { title: 订单详情, requiresAuth: true } } ] } ];这里用到动态import()实现路由级按需加载首屏只加载当前路由需要的代码块而不是整个应用打包成一个文件。这个优化对中大型项目效果非常明显。4.3 封装请求客户端和接口管理请求客户端的封装我在第2.3节说过基本思路这里展示一个更具体的落地版本// utils/request.ts const request async (config) { try { const response await fetch(config.url, { method: config.method || GET, headers: { Content-Type: application/json, Authorization: Bearer ${getToken()}, ...config.headers }, body: config.data ? JSON.stringify(config.data) : undefined }); const result await response.json(); if (result.code ! 0) { // 统一处理业务错误 if (result.code 401) { redirectToLogin(); } throw new Error(result.message); } return result.data; } catch (error) { // 统一处理网络错误和异常 notification.error(error.message); throw error; } };接口函数的组织方式是每一个接口一个函数全部挂在/api目录下。这样做的好处是接口的入参、出参、错误信息都收敛在一个地方业务组件里去调用时非常轻量而且便于后续接口变更时集中修改。4.4 核心功能实现列表页 筛选 分页模拟项目 X 的核心页面是订单列表页。这个页面包含了 React 项目最常见的几个组合筛选表单、列表表格、分页、交互反馈。父组件结构大概是这样的function OrdersPage() { const [filter, setFilter] useState({ status: , dateRange: [] }); const { data, loading, total, refresh } useFetchList(/api/orders, filter); const handleFilterChange useCallback((values) { setFilter(values); // 筛选条件变化后一般需要重置到第一页 }, []); return ( div FilterPanel values{filter} onChange{handleFilterChange} / OrderTable data{data} loading{loading} / Pagination total{total} onChange{refresh} / /div ); }这里useFetchList是一个自定义 Hook负责封装列表请求的完整生命周期参数变化时自动请求、loading 状态、错误状态、手动刷新等。这样组件代码里不会到处散落 fetch 调用逻辑也更好测试。4.5 详情页交互和跨页面状态传递从列表页进入详情页常见的状态传递方式有两种一种是通过路由动态参数传id详情页自己拉数据另一种是把整个详情对象塞进全局 store但这样刷新页面就丢了。实际开发中我习惯用第一种因为更可靠刷新页面也能恢复而且数据源更清晰。详情页内部还会涉及一些复杂的交互比如操作日志折叠、状态流转按钮、负责人分配弹窗等。这也正是自定义 Hook 发挥作用的场景useOrderDetail(id)负责详情数据加载和基础操作useOperateOrder(id)负责提交操作类动作。组件保持轻量逻辑都在 Hook 层。5. 常见问题与排查技巧实录React 项目开发到一定规模后总会遇到一些反复出现的经典问题。下面这些是我在实战中高频踩过、也帮其他人排查过的问题整理成速查表方便对照处理。5.1 组件不更新的排查路径表现props 或 state 明明变了组件就是不重新渲染。排查思路按顺序走先确认是不是用了React.memo包裹了子组件而父组件传入的 props 是内联对象/匿名函数。这种情况下每次父组件渲染子组件接收到的 props 虽然内容一样但引用不同memo 失效或者反过来 memo 生效导致不更新。再确认是不是更新了 state 本身而不是修改了 state 对象的某个属性。React 的状态比较是浅比较直接修改state.obj.name而不更换state.obj的引用React 会认为状态没变。最后确认是否在正确的组件里修改了状态。很多“不更新”其实是状态放在子组件中父组件里的其它 UI 当然不会感知到。这个问题的根子大多出在“状态引用不变”或“状态位置不对”上面找到位置再改基本上就能解决。5.2 useEffect 重复执行表现一次操作effect 执行了两次或者请求发出两遍。最常见原因框架的严格模式会在开发环境下故意调用两次 effect用于帮助开发者发现自己代码里的隐患。生产环境不受影响所以要先区分是环境差异还是真的重复。如果确实是自己的代码导致重复常见原因是依赖数组里放了对象或数组每次渲染都是新的引用导致 effect 每次都执行。处理方法是依赖项只放基础类型的值或者用useMemo把对象缓存起来。还有一种情况是事件触发链路写重了比如点了按钮触发一次然后组件又在上层响应了这个变化又触发一次。这种排查起来要顺着事件流走一遍能看到比较直接的线索。5.3 状态更新后页面卡顿表现打字输入表单敲一个字卡一下列表很长时筛选明显迟滞。通常原因有几种最典型的是每次输入都触发了全链路的数据请求而请求很慢导致输入响应被阻塞。解决办法是把受控输入和请求分离用本地 state 保存输入值输入时只更新本地状态等停止输入一段时间后再触发请求防抖。另一个原因是列表组件没有做记忆化每次输入变化整个列表重新渲染。处理方式是对列表子组件使用React.memo包裹并且确保传给列表的 props 引用稳定。还有一个常见原因是渲染了超大列表且没有做虚拟化。几千行的表格全部渲染DOM 节点太多自然卡顿。这种情况建议引入虚拟滚动库处理长列表渲染性能会好很多。5.4 表单组件受控与非受控混用表现明明给了 defaultValue输入框输入后值却不更新或者编辑表单时初始值变了输入框内容没跟着变。这通常是因为把某个中途变化的 props 当作defaultValue传给了输入框。defaultValue只在组件首次挂载时生效后续 props 变化不会更新输入框的内容。正确做法是使用value加onChange完全受控或者直接使用key来强制重新挂载表单组件。实际项目中编辑页很容易踩这个坑打开弹窗、异步拿到详情、再把详情传给表单组件结果表单内容不刷新。解决方式就是在拿到详情数据后给表单组件设置一个关键的key比如key{detailId}让 React 在数据变化后重新创建表单组件实例。5.5 状态管理中的数据同步问题表现两个组件都用同一个全局状态A 修改了B 没变。绝大多数时候这个问题的原因是 B 组件读的不是同一个状态比如有的组件直接从 store 读有的组件把 store 的值复制到了自己的本地 state 里本地 state 只有挂载时同步一次之后 store 怎么变本地 state 都无感知。排查思路在 B 组件里打日志看刷新时拿到的值是不是最新再确认 B 是不是被某个 parent 挡住了比如 parent 没有正确订阅 store。另外一个隐蔽点是 selector 的写法如果 selector 返回的是新引用的对象配合某些库时会造成死循环或频繁重渲染用shallow相等比较能解决。6. 性能优化的几个实际手段性能优化这个话题很大我挑几个在 React 项目里最常用、最见效的手段按收益从高到低排一下。6.1 路由级代码分割上面提到过的动态import()是 React 项目性能优化里性价比最高的一步。初始打包的 bundle 会被分割成多个 chunk首屏只加载当前路由对应的 chunk。尤其是中后台项目登录之后不同部门、不同角色的页面差异很大首屏加载全部页面代码实在没意义。实际测量中一个包含 20 多个路由的页面做路由级分割后首屏 JS 体积通常能减掉一半以上加载时间可以快不少。这一步的实现成本很低但收益很明显。6.2 大数据列表的虚拟化当列表长度达到几千甚至上万条时DOM 节点的数量会直接拖垮渲染性能。虚拟化的核心思想是只渲染可视区域内的那几十个节点滚动时动态替换内容。这个方案对于表格、长列表、聊天记录这类场景非常有效。引入一个成熟的虚拟滚动组件把列表区域的高度固定数据走虚拟列表滚动流畅度会有质的提升。需要注意的地方是虚拟列表的每一项最好有稳定且唯一的 key否则滚动时会出现错乱测量行高的方式要统一否则滚动位置会抖动。6.3 减少不必要的重新渲染减少不必要的重新渲染靠的不是疯狂加React.memo而是提升组件设计本身的质量。比较实用的拆法有两种把“频繁变化的部分”和“稳定部分”拆开。比如列表页里筛选条件区域和表格区域拆成独立组件筛选条件输入变化时表格不应该刷新。让状态尽量靠近真正使用它的组件不要让无关组件因为某个状态变化而都刷新一遍。用 React DevTools 的 Profiler 面板记录交互操作的渲染耗时能直观看到哪些组件渲染了、耗时多少。对照着这种数据去优化远比盲猜要靠谱。6.4 图片资源和静态体积的控制中后台项目可能对图片体积不那么敏感但对前端整体性能而言静态资源的处理同样重要。图片尽量用现代格式、按需压缩图标尽量用字体图标或 SVG 而不是一张张图片公共的工具函数库要按需引入避免把整个库打包进主 bundle。一个比较容易忽略的点是引入的第三方库如果支持按需加载尽量按需引不然打包后的体积会很难控制。7. 一些在真实项目中总结的经验细节最后一部分分享几个比较零散、不容易在官方文档里看到的个人经验。这些细节影响面不算大但积累多了会让代码质量上一个台阶。7.1 给列表项加稳定 key 的重要性列表渲染时给每一项设置key是 React 的基础要求。很多人图省事用数组索引当 key这在列表项不增删、不排序的静态场景里能用但一旦涉及增删、排序、拖拽用索引作为 key 就会引发很多诡异 bug项状态错乱、输入框内容串位、动画错乱等。可靠的做法是使用业务 id 作为 key如果没有 id也要构造一个稳定的唯一标识比如复合字段拼接。关键点都在于 key 必须能唯一标识这一项在整个列表中的身份而不是标识它的位置。7.2 配置项尽量收敛不要散落各处项目里经常会遇到一些业务配置比如状态枚举的文案和颜色、路由的标题和权限、表单项的校验规则。这些配置如果散落在各个组件里后续改动起来非常痛苦。我习惯把这类业务配置收敛到单独的配置文件中统一维护。比如订单状态有几种、每种的状态值、展示文字、徽章颜色集中放在一个文件里组件中通过工具函数引用。这样做的额外好处是做权限控制、做筛选下拉选项、做导出数据映射都可以复用这同一份配置保证数据的一致。7.3 错误边界和兜底展示不是可有可无React 组件在渲染过程中如果发生未捕获的异常会导致整个应用白屏。这不是一个“加了更好”的优化项而是一个必须做的兜底措施。主流做法是配置错误边界组件在组件树中包住业务区域一旦子组件抛出错误就降级渲染为友好的错误提示页面而不是让整个应用崩溃。轻微一点的也可以给数据加载失败、为空的情况设计统一的空状态和重试按钮这是产品体验的一部分不能省略。7.4 组件命名和信息架构要提前对齐React 项目里组件文件命名、组件内部变量命名、props 的命名看似琐碎但在协作项目里影响很大。最好在项目开始几天内就形成一套约定而不是每个开发者各写各的。例如所有组件文件从语义角度命名变量一律不用缩写布尔型 props 统一以is、can、has开头。这些约定一旦成行后面读代码、修 bug 的体验会很不一样。如果团队风格还没有统一最简单的建议就是社区里通行的那套组件文件用大驼峰命名普通工具函数用小驼峰命名布尔变量用isXxx这种格式。先统一命名再谈维护性这个顺序不能反。写在最后的个人体会用了这么久 React我最大的体会是React 本身只是一层视图层能力你对工程化、状态拆分和数据流组织的理解和实践才真正决定这个项目能撑到多大。很多项目的代码复杂其实不是 React 用错了而是组件划分、状态归属、数据请求这些基础问题没想清楚日积月累变成了庞大难维护的代码体。每次重构后链路顺畅、组件拆得干净的那种感觉真的比多写几个组件更让人觉得踏实。最后分享一个维护老项目的小技巧如果拿到一个别人写的 React 项目不要先把所有代码都看完先整理出路由表、组件树、状态分布图用这三张图作为地图去读代码会省下很多时间。这个习惯我在接手任何一个新项目时都会用很管用。希望这篇经验对你有参考价值。
看到标题“rea”很多做前端的朋友应该都不陌生这就是 React 在社区里、在代码仓库里最常用的简称。但正是因为太常见了反而容易让人忽略它背后那一整套完整的前端工程化思维。这篇内容我不打算讲官方文档上已有的 API 清单而是想换个角度从“拿到一个项目标题、需求只有一句话”时一个老手是怎么思考、怎么拆解、怎么一步步把页面搭起来、把状态管好、把性能抠出来、最后踩坑排雷的完整过程。这些经验大多来自实际开发中的复盘希望对正在用 React 做项目的你有一点参考价值。无论你是刚接触 React 的初学者还是已经用了两三年但总觉得在“照着文档写组件”的开发这篇文章都会有点用处。我会从设计思路、工程化选型、核心实现再到问题排查完整过一遍 React 项目的落地流程。每一条都不会是空泛的理论而是可以照着做、照着调的东西。1. 拿到需求别急着写代码先理清组件边界和状态模型很多初学者拿到项目需求第一反应是“这个页面长这样我来照着写”。框架本身确实允许你这么快开始但实际项目里这种做法的返工率极高。React 的核心理念是“以组件为单位构建 UI”但组件怎么拆、状态放哪儿、数据怎么流动这些决策比写 JSX 本身重要得多。1.1 组件拆分按职责而不是按视觉分区我见过不少项目组件目录是照着设计稿的视觉区块建的一个 Header 组件、一个 Sidebar 组件、一个 Content 组件。这种方式的直观问题在于视觉区块和业务职责往往并不一致。更好的做法是按业务职责和复用粒度来拆。比如一个电商后台的订单列表页按照视觉区块你会拆成顶部筛选区、表格区、分页器、弹窗详情。但按职责来拆应该是OrderFilter负责筛选条件状态、OrderTable负责列表数据和列配置、OrderDetailDialog负责详情展示和操作交互、Pagination通用组件。这样拆的好处是每个组件的 props 和 state 都相对清晰改动一个业务逻辑时不需要在多个“视觉区块”里来回找。判断一个组件职责是否合理有一个很朴素的标准如果你要给这个组件写一段“它负责什么”的描述这段描述是否超过两句话。超过两句话大概率这个组件管得太多了应该再拆。1.2 状态模型设计哪些放本地 state哪些放全局 store状态管理是 React 项目里的争议重灾区。我见过一个中型项目把所有的数据都放进全局 store结果组件刷新、内存占用、调试成本全线告急也见过相反的情况连登录用户信息都放在组件本地 state 里导致刷新页面就丢状态。我的经验是分三挡来决策第一挡组件本地 state只影响当前组件 UI 的临时状态比如弹窗开合、选项卡索引、表单某个字段的临时值。这类状态用useState就好根本不需要全局化。第二挡跨组件共享但不需要持久化的数据比如多个兄弟组件都要读某个筛选条件或者某个计算结果被多个地方复用。这时候用useContext配合useReducer或者直接提升 state 到最近的公共父组件已经足够。第三挡需要跨页面共享、涉及复杂数据交互、或者需要缓存的服务端数据这才需要真正的全局 store。一个很容易被忽略的原则是能放本地的就不要放全局能放近的不要放远的。全局状态越少项目的可维护性越高。这个原则没有变化任何时候做 React 项目都适用因为全局数据一多必然面临“这个状态是从哪来、要被谁改、当前是什么值”的三连拷问。1.3 从数据流反推组件层级确定状态模型之后再顺着数据流把组件层级排出来比先画视觉再想数据要顺得多。核心思路是找一个状态需要被哪些组件读取找到这些组件的最近公共父组件让状态待在父组件里通过 props 向下传递。举一个实际例子筛选条件区域和一个结果列表区域其实是联动的。筛选条件的某个值变更列表需要重新请求并展示。最合理的结构是把筛选条件和列表数据同时放在它们共同的父组件里父组件持有筛选条件的 state 和列表数据的 state传递一个onFilterChange给筛选组件传递data给列表组件。这个结构简单清晰两个子组件完全可以独立复用。2. 工程化选型有讲究脚手架、路由、请求层和样式方案一个 React 项目的工程化选型直接决定了项目的开发体验和长期可维护性。这部分我不会推荐“唯一正确答案”因为不同的团队风格、项目周期、部署环境正确答案不一样。我重点是讲明白每个选型背后的考量这样你拿到自己的项目时能做出适合自己的判断。2.1 初始化方式为什么你仍然需要一个构建工具现在初始化 React 项目最主流的命令已经不是手动配置 Webpack 了。社区推荐的方式是用官方脚手架或社区维护的起步模板它们把构建、转译、热更新、代码规范都集成好了。我在实际项目里更看重的是模板对 TypeScript 的支持是否开箱即用因为类型系统在项目规模上去之后带来的收益是实实在在的。如果一个模板还要你自己去配置 tsconfig、编辑器和构建插件之间的集成那我建议换一个模板省下的时间用来写业务逻辑更划算。2.2 路由设计不是加一个库那么简单React 应用大多是单页富应用路由库是很基础的一层。选路由方案时我特别关注三点是否支持嵌套路由对应的组件嵌套结构。因为实际业务里一个主布局下面往往有多级页面路由的嵌套结构如果能和组件树的结构一一对应理解成本会大幅降低。是否支持动态路由和按需加载。大型项目的首屏性能很大程度依赖路由级代码分割。路由参数的类型安全。路由设计上有一个容易被忽略的细节把路由配置收敛到一个独立文件里集中管理。哪怕刚开始只有两三个页面也建议这么做。因为后续增加页面、权限控制、面包屑导航、页面标题设置都可以依托这一份配置来实现。我自己习惯在每个页面配置里带上title、icon、permission等元信息字段后续做导航菜单和权限拦截时就能直接用不用额外维护一份重复的菜单配置文件。2.3 数据请求层fetch 封装、缓存与请求状态处理数据请求层是 React 项目里最容易写乱的部分。我见过那种在组件里到处写 fetch 然后 .then 回调最后全项目布满了 loading 状态的方式——不是说不能用但项目一复杂就很容易乱。更稳妥的方式是封装一个统一的请求客户端基于浏览器原生 fetch 或者基于 XMLHttpRequest 的库封一层统一处理请求头的注入比如认证 token。响应拦截比如统一处理后端返回的 codedatamessage 结构。错误处理网络错误、业务错误、登录过期跳转登录页。重复请求取消。请求状态的管理我建议用自定义 Hook 的方式收敛比如useFetchList、useMutation这类对外暴露data、loading、error、refresh等方法的封装。组件只用关心自己的数据从哪来请求被打到哪里、怎么重试、取消请求这些问题统一封装在前端。2.4 样式方案CSS Modules 还是 CSS-in-JS开发时这个选择的优先级很高跟前端项目的兼容和团队协作关系很大。我个人的经验是对大多数中小型项目CSS Modules 通常是最稳妥的方案因为它不引入额外的运行时样式的局部作用域可以避免写长选择器互相覆盖而且写起来就是普通 CSS团队成员上手成本很低。CSS-in-JS 方案的优点是样式和逻辑在同一个文件里动态样式处理很灵活。但运行时开销和调试成本还是现实问题。如果是组件库或需要大量动态样式的项目CSS-in-JS 更有优势具体只能看团队的项目情况定没有放之四海皆准的标准答案。3. 核心细节解析Hooks 落地的几个硬核技巧React 16.8 之后函数组件加 Hooks 已经是绝对的主流写法。但 Hooks 的粒度怎么控制、依赖数组怎么填、副作用怎么处理才是从“会用”到“用得好”的分水岭。3.1 useState 的惰性初始化和函数式更新useState有个容易被忽略的细节初始值如果是通过复杂计算得到的应该传一个函数进去让它只在组件首次渲染时执行一次而不是每次渲染都重复算。这个优化在初始值是数组、要经过 map/filter 等遍历计算时收益是肉眼可见的。另一个重要细节是依赖前一个状态更新时应该用函数式更新的形式。看这个场景const [count, setCount] useState(0); // 不推荐当多次连续调用 setCount 时会基于同一个旧值计算 setCount(count 1); setCount(count 1); // 推荐每次都是基于最新值计算 setCount(prev prev 1);虽然 React 的批处理机制能缓解不少问题但在复杂交互下比如快速点击、异步回调中更新函数式更新是更稳的写法。3.2 useEffect 的依赖数组不是随便填的useEffect的依赖数组是新手最容易踩的坑。不填依赖数组每次渲染都执行、填空数组只在挂载时执行一次、填部分依赖可能漏掉某个变量三种情况各自都有问题。最实用的原则依赖数组里应该列出 effect 中引用的每一个响应式值。如果你发现依赖数组里东西太多导致 effect 频繁触发正确的做法不是强行忽略依赖而是重新审视代码结构把多个职责拆开。一个 effect 只做一件事依赖就会更清晰。还有一个经常踩的坑是在 effect 里使用了某个 props 或 state但依赖数组里漏掉了它。结果就是 effect 执行时用的还是旧值这个问题排查起来很隐蔽因为不是每次都会复现。所以我现在写代码有个习惯写完之后会先看一眼 effect 里引用了哪些外部变量再对照依赖数组确认它们是否都列出来了。3.3 useMemo 和 useCallback为性能服务但别滥用很多开发者一听说性能优化就开始到处塞useMemo和useCallback。但这两个 API 是有代价的它们本身也是有一定开销的需要额外的内存保存依赖、需要比对依赖是否变化。如果一个计算本身很轻量或者一个函数本身很稳定就不值得用它们去包一层。性能优化第一步永远是分析真正的瓶颈而不是凭直觉盲优化。合理的场景是useMemo复杂数据转换、列表过滤排序、大对象深度对比等。useCallback需要传递给被React.memo包裹的子组件的函数或者作为 effect 依赖的函数。判断取舍的一个技巧是先把代码写清楚性能测试发现确实有问题了再针对性地加记忆化。盲目加 useMemo 会让代码可读性下降而且依赖数组本身也是一个心智负担。3.4 自定义 Hooks把逻辑抽到组件之外但不要把组件拆得太碎自定义 Hooks 是 React 工程化项目里提升复用度的最佳手段之一。比如一个有“输入内容并防抖请求”需求的搜索框通常的做法是直接写到组件里但更合理的做法是把它抽成useDebouncedSearch。这样搜索逻辑的细节被藏起来组件里只需要关心要不要显示 loading以及拿到的列表数据。不过自定义 Hooks 也有一个边界问题不要把所有东西都拆成 Hooks。如果一个 Hook 只被一个组件使用而且里面的逻辑很简单那抽出来反而增加跳转成本。先写在组件里发现有一大坨逻辑导致组件难以阅读时再抽出去这样的节奏最自然。4. 实操过程从零到一搭建一个 React 项目完整步骤演练这一部分我用一个模拟项目 X企业内部的数据分析看板前端为例带你完整走一遍从初始化到核心功能实现的流程。这个项目规模适中包含了列表页、详情页、表单提交、数据可视化图表展示非常适合用来演示 React 工程化的完整套路。4.1 项目初始化和目录结构规划第1步是用你选定的脚手架初始化项目然后在项目根目录下规划目录结构。我的习惯是按下图这样划分src/ ├── api/ # 接口请求函数 ├── assets/ # 静态资源 ├── components/ # 通用业务组件 ├── hooks/ # 自定义 Hooks ├── layouts/ # 布局组件 ├── pages/ # 页面级组件 ├── routes/ # 路由配置 ├── stores/ # 全局状态 ├── styles/ # 全局样式 ├── utils/ # 工具函数 └── types/ # 类型定义这个划分不一定适合所有项目但有一件事很重要目录结构在项目第一天就定好。后期再调整目录的成本非常高因为每个路径引用都要改动一遍。4.2 路由层配置和按需加载路由配置我倾向于把所有路由收敛到一个数组里集中管理然后用循环生成路由。这样页面组件维护在一个文件里新增页面时只需要加一段配置。// routes/index.js const routes [ { path: /dashboard, component: () import(/pages/Dashboard), meta: { title: 数据看板, requiresAuth: true } }, { path: /orders, component: () import(/pages/Orders), meta: { title: 订单列表, requiresAuth: true }, children: [ { path: detail/:id, component: () import(/pages/OrderDetail), meta: { title: 订单详情, requiresAuth: true } } ] } ];这里用到动态import()实现路由级按需加载首屏只加载当前路由需要的代码块而不是整个应用打包成一个文件。这个优化对中大型项目效果非常明显。4.3 封装请求客户端和接口管理请求客户端的封装我在第2.3节说过基本思路这里展示一个更具体的落地版本// utils/request.ts const request async (config) { try { const response await fetch(config.url, { method: config.method || GET, headers: { Content-Type: application/json, Authorization: Bearer ${getToken()}, ...config.headers }, body: config.data ? JSON.stringify(config.data) : undefined }); const result await response.json(); if (result.code ! 0) { // 统一处理业务错误 if (result.code 401) { redirectToLogin(); } throw new Error(result.message); } return result.data; } catch (error) { // 统一处理网络错误和异常 notification.error(error.message); throw error; } };接口函数的组织方式是每一个接口一个函数全部挂在/api目录下。这样做的好处是接口的入参、出参、错误信息都收敛在一个地方业务组件里去调用时非常轻量而且便于后续接口变更时集中修改。4.4 核心功能实现列表页 筛选 分页模拟项目 X 的核心页面是订单列表页。这个页面包含了 React 项目最常见的几个组合筛选表单、列表表格、分页、交互反馈。父组件结构大概是这样的function OrdersPage() { const [filter, setFilter] useState({ status: , dateRange: [] }); const { data, loading, total, refresh } useFetchList(/api/orders, filter); const handleFilterChange useCallback((values) { setFilter(values); // 筛选条件变化后一般需要重置到第一页 }, []); return ( div FilterPanel values{filter} onChange{handleFilterChange} / OrderTable data{data} loading{loading} / Pagination total{total} onChange{refresh} / /div ); }这里useFetchList是一个自定义 Hook负责封装列表请求的完整生命周期参数变化时自动请求、loading 状态、错误状态、手动刷新等。这样组件代码里不会到处散落 fetch 调用逻辑也更好测试。4.5 详情页交互和跨页面状态传递从列表页进入详情页常见的状态传递方式有两种一种是通过路由动态参数传id详情页自己拉数据另一种是把整个详情对象塞进全局 store但这样刷新页面就丢了。实际开发中我习惯用第一种因为更可靠刷新页面也能恢复而且数据源更清晰。详情页内部还会涉及一些复杂的交互比如操作日志折叠、状态流转按钮、负责人分配弹窗等。这也正是自定义 Hook 发挥作用的场景useOrderDetail(id)负责详情数据加载和基础操作useOperateOrder(id)负责提交操作类动作。组件保持轻量逻辑都在 Hook 层。5. 常见问题与排查技巧实录React 项目开发到一定规模后总会遇到一些反复出现的经典问题。下面这些是我在实战中高频踩过、也帮其他人排查过的问题整理成速查表方便对照处理。5.1 组件不更新的排查路径表现props 或 state 明明变了组件就是不重新渲染。排查思路按顺序走先确认是不是用了React.memo包裹了子组件而父组件传入的 props 是内联对象/匿名函数。这种情况下每次父组件渲染子组件接收到的 props 虽然内容一样但引用不同memo 失效或者反过来 memo 生效导致不更新。再确认是不是更新了 state 本身而不是修改了 state 对象的某个属性。React 的状态比较是浅比较直接修改state.obj.name而不更换state.obj的引用React 会认为状态没变。最后确认是否在正确的组件里修改了状态。很多“不更新”其实是状态放在子组件中父组件里的其它 UI 当然不会感知到。这个问题的根子大多出在“状态引用不变”或“状态位置不对”上面找到位置再改基本上就能解决。5.2 useEffect 重复执行表现一次操作effect 执行了两次或者请求发出两遍。最常见原因框架的严格模式会在开发环境下故意调用两次 effect用于帮助开发者发现自己代码里的隐患。生产环境不受影响所以要先区分是环境差异还是真的重复。如果确实是自己的代码导致重复常见原因是依赖数组里放了对象或数组每次渲染都是新的引用导致 effect 每次都执行。处理方法是依赖项只放基础类型的值或者用useMemo把对象缓存起来。还有一种情况是事件触发链路写重了比如点了按钮触发一次然后组件又在上层响应了这个变化又触发一次。这种排查起来要顺着事件流走一遍能看到比较直接的线索。5.3 状态更新后页面卡顿表现打字输入表单敲一个字卡一下列表很长时筛选明显迟滞。通常原因有几种最典型的是每次输入都触发了全链路的数据请求而请求很慢导致输入响应被阻塞。解决办法是把受控输入和请求分离用本地 state 保存输入值输入时只更新本地状态等停止输入一段时间后再触发请求防抖。另一个原因是列表组件没有做记忆化每次输入变化整个列表重新渲染。处理方式是对列表子组件使用React.memo包裹并且确保传给列表的 props 引用稳定。还有一个常见原因是渲染了超大列表且没有做虚拟化。几千行的表格全部渲染DOM 节点太多自然卡顿。这种情况建议引入虚拟滚动库处理长列表渲染性能会好很多。5.4 表单组件受控与非受控混用表现明明给了 defaultValue输入框输入后值却不更新或者编辑表单时初始值变了输入框内容没跟着变。这通常是因为把某个中途变化的 props 当作defaultValue传给了输入框。defaultValue只在组件首次挂载时生效后续 props 变化不会更新输入框的内容。正确做法是使用value加onChange完全受控或者直接使用key来强制重新挂载表单组件。实际项目中编辑页很容易踩这个坑打开弹窗、异步拿到详情、再把详情传给表单组件结果表单内容不刷新。解决方式就是在拿到详情数据后给表单组件设置一个关键的key比如key{detailId}让 React 在数据变化后重新创建表单组件实例。5.5 状态管理中的数据同步问题表现两个组件都用同一个全局状态A 修改了B 没变。绝大多数时候这个问题的原因是 B 组件读的不是同一个状态比如有的组件直接从 store 读有的组件把 store 的值复制到了自己的本地 state 里本地 state 只有挂载时同步一次之后 store 怎么变本地 state 都无感知。排查思路在 B 组件里打日志看刷新时拿到的值是不是最新再确认 B 是不是被某个 parent 挡住了比如 parent 没有正确订阅 store。另外一个隐蔽点是 selector 的写法如果 selector 返回的是新引用的对象配合某些库时会造成死循环或频繁重渲染用shallow相等比较能解决。6. 性能优化的几个实际手段性能优化这个话题很大我挑几个在 React 项目里最常用、最见效的手段按收益从高到低排一下。6.1 路由级代码分割上面提到过的动态import()是 React 项目性能优化里性价比最高的一步。初始打包的 bundle 会被分割成多个 chunk首屏只加载当前路由对应的 chunk。尤其是中后台项目登录之后不同部门、不同角色的页面差异很大首屏加载全部页面代码实在没意义。实际测量中一个包含 20 多个路由的页面做路由级分割后首屏 JS 体积通常能减掉一半以上加载时间可以快不少。这一步的实现成本很低但收益很明显。6.2 大数据列表的虚拟化当列表长度达到几千甚至上万条时DOM 节点的数量会直接拖垮渲染性能。虚拟化的核心思想是只渲染可视区域内的那几十个节点滚动时动态替换内容。这个方案对于表格、长列表、聊天记录这类场景非常有效。引入一个成熟的虚拟滚动组件把列表区域的高度固定数据走虚拟列表滚动流畅度会有质的提升。需要注意的地方是虚拟列表的每一项最好有稳定且唯一的 key否则滚动时会出现错乱测量行高的方式要统一否则滚动位置会抖动。6.3 减少不必要的重新渲染减少不必要的重新渲染靠的不是疯狂加React.memo而是提升组件设计本身的质量。比较实用的拆法有两种把“频繁变化的部分”和“稳定部分”拆开。比如列表页里筛选条件区域和表格区域拆成独立组件筛选条件输入变化时表格不应该刷新。让状态尽量靠近真正使用它的组件不要让无关组件因为某个状态变化而都刷新一遍。用 React DevTools 的 Profiler 面板记录交互操作的渲染耗时能直观看到哪些组件渲染了、耗时多少。对照着这种数据去优化远比盲猜要靠谱。6.4 图片资源和静态体积的控制中后台项目可能对图片体积不那么敏感但对前端整体性能而言静态资源的处理同样重要。图片尽量用现代格式、按需压缩图标尽量用字体图标或 SVG 而不是一张张图片公共的工具函数库要按需引入避免把整个库打包进主 bundle。一个比较容易忽略的点是引入的第三方库如果支持按需加载尽量按需引不然打包后的体积会很难控制。7. 一些在真实项目中总结的经验细节最后一部分分享几个比较零散、不容易在官方文档里看到的个人经验。这些细节影响面不算大但积累多了会让代码质量上一个台阶。7.1 给列表项加稳定 key 的重要性列表渲染时给每一项设置key是 React 的基础要求。很多人图省事用数组索引当 key这在列表项不增删、不排序的静态场景里能用但一旦涉及增删、排序、拖拽用索引作为 key 就会引发很多诡异 bug项状态错乱、输入框内容串位、动画错乱等。可靠的做法是使用业务 id 作为 key如果没有 id也要构造一个稳定的唯一标识比如复合字段拼接。关键点都在于 key 必须能唯一标识这一项在整个列表中的身份而不是标识它的位置。7.2 配置项尽量收敛不要散落各处项目里经常会遇到一些业务配置比如状态枚举的文案和颜色、路由的标题和权限、表单项的校验规则。这些配置如果散落在各个组件里后续改动起来非常痛苦。我习惯把这类业务配置收敛到单独的配置文件中统一维护。比如订单状态有几种、每种的状态值、展示文字、徽章颜色集中放在一个文件里组件中通过工具函数引用。这样做的额外好处是做权限控制、做筛选下拉选项、做导出数据映射都可以复用这同一份配置保证数据的一致。7.3 错误边界和兜底展示不是可有可无React 组件在渲染过程中如果发生未捕获的异常会导致整个应用白屏。这不是一个“加了更好”的优化项而是一个必须做的兜底措施。主流做法是配置错误边界组件在组件树中包住业务区域一旦子组件抛出错误就降级渲染为友好的错误提示页面而不是让整个应用崩溃。轻微一点的也可以给数据加载失败、为空的情况设计统一的空状态和重试按钮这是产品体验的一部分不能省略。7.4 组件命名和信息架构要提前对齐React 项目里组件文件命名、组件内部变量命名、props 的命名看似琐碎但在协作项目里影响很大。最好在项目开始几天内就形成一套约定而不是每个开发者各写各的。例如所有组件文件从语义角度命名变量一律不用缩写布尔型 props 统一以is、can、has开头。这些约定一旦成行后面读代码、修 bug 的体验会很不一样。如果团队风格还没有统一最简单的建议就是社区里通行的那套组件文件用大驼峰命名普通工具函数用小驼峰命名布尔变量用isXxx这种格式。先统一命名再谈维护性这个顺序不能反。写在最后的个人体会用了这么久 React我最大的体会是React 本身只是一层视图层能力你对工程化、状态拆分和数据流组织的理解和实践才真正决定这个项目能撑到多大。很多项目的代码复杂其实不是 React 用错了而是组件划分、状态归属、数据请求这些基础问题没想清楚日积月累变成了庞大难维护的代码体。每次重构后链路顺畅、组件拆得干净的那种感觉真的比多写几个组件更让人觉得踏实。最后分享一个维护老项目的小技巧如果拿到一个别人写的 React 项目不要先把所有代码都看完先整理出路由表、组件树、状态分布图用这三张图作为地图去读代码会省下很多时间。这个习惯我在接手任何一个新项目时都会用很管用。希望这篇经验对你有参考价值。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
