企业官网建设流程全解析

很多同学学 React，两周就能照着文档写出一个 ToDo List，可一旦进入真实项目，代码就开始失控：组件拆得乱七八糟、状态满天飞、改一个需求崩三处、页面一卡就是几十毫秒的渲染任务。问题不在语法，而在思维模型。React 真正改变的不是写法，而是你思考用户界面问题的方式。

这篇内容我围绕自己用 React 做过多个中后台项目、跨端应用和实时数据面板之后沉淀下来的东西来写。不打算讲一遍 API，那没有意义；我想聊的是那些文档里没人写、但决定项目成败的认知和习惯——从组件设计到渲染控制，从状态管理到工程化治理，全部基于我实际踩过的坑和验证过的方案。

1. 入门容易进阶难：真正拦住你的是三个思维转变

React 的入门曲线在主流框架里算平缓的，JSX 看起来像 HTML，组件看起来像函数，useState 看起来像变量声明。可一旦脱离教程，进入复杂业务，差异立刻就出来了。我见过很多从 Vue 或 jQuery 转过来的开发者，写了两三个月还停留在"用 React 的方式写旧代码"的状态。这里的核心差距，是三个思维转变没有完成。

1.1 从"操作界面"到"描述状态"

传统开发思维里，我们习惯拿到一个 DOM 元素，然后调用方法去改它的属性、样式、内容。这种命令式的写法很直观，但在复杂交互里很容易出问题：顺序错了、条件漏了、状态不一致了。React 逼你换一个角度——不考虑"怎么改界面"，只考虑"界面应该长什么样"，而且这个长相完全由数据决定。

举一个我实际经历的例子。某后台项目有个批量操作按钮，需求是：选中行后按钮可用，没选中时置灰，操作期间禁用并显示 loading。命令式写法需要分别在选中事件、提交事件、网络回调里维护几个布尔变量，稍不注意就出现"按钮置灰了但 loading 还在转"的诡异状态。React 的写法完全不同：只声明一个status字段，它的取值决定按钮的全部表现，UI 永远是这个状态的投影。

刚开始你会觉得麻烦，什么都得声明状态、设计状态。但坚持半年后你会发现，界面已经被你"降维"成了数据的函数，bug 的来源从"操作顺序有误"变成了"状态设计不合理"，后者要容易定位得多。

1.2 从"全局查找"到"单向数据流"

jQuery 时代，一个页面上十几个控件互相读写，调试靠全局搜索变量名谁改过。React 用单向数据流切断这种混乱：数据从父组件流向子组件，子组件想改数据，必须通过回调通知父组件。方向统一了，出问题就知道往上游找，这在团队协作里价值巨大——每个组件的数据来源和变更出口是显式的，不靠猜。

团队里有个实习同学问过我一个问题：React 的数据流这么严格，那岂不是子组件想改个本地状态都得往上提？其实不用。单向数据流约束的是"跨层级的共享数据"，组件内部完全可以用自己的 state。一个判断标准：当前组件的兄弟组件或父组件需不需要同步这个数据？不需要就留在原地，需要就往上提。过度提升数据层级是新手常见问题，数据都在根部，所有组件都变成纯展示组件，看着很"标准"，实际上每次修改都要顺着 callback 一路下传，改个文案要动五层文件，维护成本极高。

1.3 从"写一次跑通"到"组件即契约"

React 组件本质上是接口：输入 props，输出界面。写组件的时候，你实际上是在定义一份团队内部的契约。这个视角转不过来，写出来的组件就只是"某次需求的临时产物"——props 命名随意、复用碎片化、耦合业务细节，等下个人要用时发现完全没法接。

我现在的习惯是：写每个组件前先问自己四个问题——它的输入是什么？输出是什么？它会改变外部状态吗？如果剥离当前业务，它还能不能独立存在？按这套标准写出来的组件，即使不抽象成独立组件库，在项目内部的可复用性也明显好很多，后续需求变更时改动的半径大幅缩小。

2. 组件化不是拆文件：先想清楚边界再动手

很多团队要求"组件愈细愈好"，于是出现了 50 行一个 Button、10 个文件完成一个 form 的奇观。组件化的核心目标是控制复杂度，不是比谁的文件数量多。我用过的项目里，代码最难维护的从来不是"大组件"，而是"边界模糊、职责混乱的假组件"。

2.1 组件的边界划分标准

我划分组件的依据其实只有一条：变化的方向是否一致。如果 A 和 B 永远一起变化，它们就适合放同一个组件里；如果 A 变了 B 永远不动，它们就该拆开。举个例子，一个用户卡片同时包含头像、昵称、等级徽章和最近活跃时间，如果这四个元素来自同一份数据、展示在同一个上下文中，拆成四个组件再拼回去就是纯粹的绕路；但如果其中某个元素有自己的交互逻辑（比如徽章可点击弹出说明），这时候单独抽出来才有意义。

另一个角度是看"复用的层级"。组件不是只有"全项目通用"和"单页面私有"两种，还有一种常见的中间层——业务组件，即由基础组件组合而成、封装了某类业务语义的组件。比如"订单状态标签"，它内部是一段翻译逻辑加样式映射，在很多页面共用，但又依赖于订单这个业务概念，不适合放进通用组件库。这个中间层我会单独建目录，按业务域组织，避免通用组件目录被各种业务代码污染。

2.2 props 设计：宽度和深度的取舍

props 是组件的对外契约，设计得好不好直接影响组件能不能活下去。我观察过很多糟糕的 props 设计，共性问题是"宽度太大"——一个组件接收十几个 props，一半是控制边距的 CSS 类名，另一半是分支逻辑的布尔开关。这种组件"万能"，但用起来极其痛苦：你永远不知道哪些 props 组合合法、哪些组合会导致界面异常。

我的原则是控制 props 数量，复杂交互通过组合而不是配置。如果 props 超过七个，先停下来想：这个组件是不是承担了太多职责？是不是某些配置可以内置为子组件？是不是有些布尔开关可以合并成枚举值？比如"按钮类型"不要拆成isPrimary、isDanger、isGhost三个布尔值，而应该用一个variant枚举，语义清晰，也不会出现"同时是 primary 又是 danger"这种非法组合。

另一种常见问题是 props 里塞对象。传入整个user对象确实省事，但会让组件隐含依赖对象内部结构，数据来源稍有变动就要连带改组件。除非是这个对象的直接消费者，否则我宁可拆成几个基本值。拆开之后组件更"笨"，但更稳定，复用性也更好。

2.3 组合优于配置：React 给的可复用武器

刚做组件时，我总想用配置项解决一切差异，后来被教育了。React 的组合机制比配置项强得多。配置项是"预设好可能的形态"，组合则是"让调用方自己定义形态"。最典型的两个机制是children和 render props。

有段时间我做一个筛选面板，支持多种筛选类型：单选框、复选框、日期段、数字区间。第一版我把所有类型做成配置项，组件内部一大坨条件渲染，加一个新类型就要动组件本体。后来改成"面板只负责布局和折叠逻辑，具体筛选控件通过 children 传入"，组件本体变得又瘦又稳，新类型的扩展完全在组件外部完成，不再触碰原代码。组合的代价是调用方多写几行，收益是整个核心组件永远不需要为未知需求改动。

2.4 自定义 Hook：复用逻辑的正确容器

组件拆分解决的是界面复用，逻辑复用要交给自定义 Hook。写过一段时间 React 的同学都会有这种体验：useEffect 里一堆 wiring 代码，把数据请求、状态更新、清理动作粘在一起，放在多个组件里只能复制粘贴。自定义 Hook 的粒度可以很小——比如useDebouncedValue、usePrevious、useLocalStorageState，也可以很大——比如管理整个弹窗生命周期的useDialog。

我的建议是：当你在两个及以上组件里复制了同一段逻辑，立即抽成 Hook，不要等。抽 Hook 的时机不用太严谨，反正它只是个函数，边界不对随时调整。比起组件抽象，Hook 的调整成本低很多，因为函数的入参和返回值都是显式的，不涉及复杂的渲染关系。但要注意一点：Hook 内部不要偷偷做 UI 修改，不要在 Hook 里获取 DOM 操作，渲染相关的事情留给组件层，Hook 只处理状态和副作用逻辑。

3. 被误解最多的渲染机制：虚拟 DOM 和重新渲染的真实关系

关于虚拟 DOM 的讨论特别多，很多说法把它当成"React 什么都比你快"的保证，这是重大误解。虚拟 DOM 的价值不是"最快"，而是提供了一种跨平台的能力（因为操作的不再是真实 DOM，而是普通的 JavaScript 对象），配合 diff 算法，让"每次渲染都重建整个 UI"这件事变得可接受。真正影响 React 应用性能的，从来不是虚拟 DOM diff 本身，而是组件函数体里那些不必要的执行。

3.1 理解渲染发生的时机和过程

一个 React 组件函数被调用，不等于 DOM 被更新。组件执行后产生新的虚拟 DOM 结构，React 与上次的虚拟 DOM 做对比，找出需要变化的最小路径，再更新真实 DOM。所以"组件函数很重"和"页面很卡"之间不是直接的等号——如果对比下来没有变化，真实 DOM 不会被碰。但组件函数本身的重型计算、大数组遍历、对象创建，仍然会占用主线程时间，这就是性能问题的根源之一。

我见过一个性能问题案例。某数据面板页面，顶部有个全局筛选器，每次筛选条件变化，整个页面所有组件统统重新执行。用 React DevTools 的 Profiler 一看，有十几个组件根本不需要更新，但它们仍然执行了完整的函数体和虚拟 DOM diff。这个问题不是虚拟 DOM 慢，而是我的组件设计让"做无用工"的组件太多了。

3.2 React.memo 的正确与错误用法

React.memo 是控制组件重渲染的第一道闸门。它的作用是对 props 做浅比较，如果 props 没变化，跳过组件函数执行，直接复用上次的渲染结果。听起来很美好，但直接用经常无效——因为 props 里有新创建的函数或对象，浅比较永远不相等，memo 形同虚设。

举一个实际场景：父组件里写<Child onClick={() => doSomething()} />，每次父组件渲染都会创建新函数，memo 比较发现 props 变了，照样重渲染。要解决，得配合useCallback固定函数引用。所以在我现在的写法里，memo 和 useCallback 是一对搭档，单独用哪个都难以发挥效果。还有一个细节：memo 比较是浅比较，props 里有嵌套对象时，对象引用变化就会触发渲染，这是正常的，不用刻意去深比较，深比较的开销可能比渲染本身还大。

3.3 useMemo 不是缓存所有计算的神器

有人把 useMemo 当万能性能工具，任何计算都包一层，这其实是个误区。useMemo 本身有内存开销和依赖比较的开销，如果计算本身不重，包一层反而更慢。我通常只在两种情况用 useMemo：一是渲染路径上的重型计算（大数组 filter、排序、格式化），二是需要保持引用稳定的对象（传给 memo 子组件的 props、useEffect 的依赖）。

基础规则是：useMemo 不是为了"不用重新计算"而存在，是为了"在依赖没变时维持引用稳定"而存在。理解到这个层面，你就不会到处乱用了。比如一个普通数组 map 出来的一列<li>，直接写就行，根本不需要 useMemo——重新执行一遍 map 的代价远小于 useMemo 的依赖追踪成本。

3.4 稳定优先：减少渲染爆炸的实战手段

控制重渲染除了 memo，还有很多工程手段。首先是状态位置的问题——状态放在哪个组件，决定了它的更新会波及多大的渲染范围。一个典型的反面案例：把弹窗开关状态放在页面根部，每次开关都触发整个页面重渲染，页面组件一重，体验就明显卡顿。我把这类状态下放给弹窗组件自己管理之后，不再影响页面主体。

其次是数据抽象层的优化。给 Context 的 value 包一层 useMemo，防止 value 对象引用变化导致所有消费者重渲染。这一点很容易漏——很多人只 memo 了子组件，却没意识到 Context 的 value 每次都是新对象，一传下去全白搭。还有key的正确使用：需要强制重建组件时（比如表单重置）可以用 key 变化来触发，这是合法技巧，但不要滥用。

4. Hooks 使用边界：从依赖地狱到顺手的封装模式

Hooks 是 React 近年最核心的变革，但它确实容易被用坏。useEffect 依赖数组的失控、闭包陷阱、过度抽取导致的流，我在代码审查里见过太多。这个部分讲讲我总结出来的使用边界和封装模式。

4.1 useEffect 的依赖数组不是"数组里装了谁就监听谁"

新手经常把 useEffect 当成"watch"来用——某个值变了就执行副作用。这个理解在大方向差不多，但少了一个关键：effect 执行后不仅能读取依赖值，还能通过 setState 引入新的数据流，而这些新数据的变化又可能再次触发 effect。循环依赖、重复请求、频繁重渲染，很多都从这里来。

我踩过这样一个坑：一个搜索页，useEffect 里监听 keyword 变化然后请求列表，请求结果回来后 setState 更新列表数据。看起来没问题，但某次代码改动在依赖数组里加了一个取自列表数据的字段，结果每次请求回来列表更新，字段变化，又触发请求，死循环了。定位半天才明白，依赖数组不只是"触发条件"，它是副作用执行所需的外部变量的完整清单。加了不需要的依赖，就会制造不稳定。

4.2 闭包陷阱：为什么 effect 里永远读到旧值

闭包陷阱也是高频问题。useEffect 里引用了一个 state，但没写进依赖数组，于是 effect 捕获的是某次渲染时的旧值。典型的场景是：点击按钮后每隔一秒打印当前计数值，useEffect 里 setInterval 引用了 count，但依赖数组是空的，于是 interval 回调永远读到初始值 0。原因很简单——effect 函数是那次渲染时创建并捕获了那次渲染的 props 和 state，不重新创建就无法拿到新值。

解法有几个，取决于场景。需要用最新值的：可以用 ref 保存最新值，在 interval 回调里读 ref。需要响应变化的：把 count 加入依赖数组，effect 重新创建，同时清理上一次的定时器。还有一种是函数式更新setCount(c => c + 1)，让更新本身不依赖旧值。关键在于理解"依赖数组的作用是让 effect 保持新鲜"，而不是抄文档模板。

4.3 自定义 Hook 的三条"手感"经验

自定义 Hook 写多了之后，我发现有三个非常影响使用体验的设计原则。第一，返回值尽量是稳定引用，内部用 useMemo/useCallback 包一下，不然使用方每次拿到新引用，就不得不到处加依赖，数据流会变得很烦躁。第二，对外暴露的状态粒度要贴合业务语义，不要暴露一堆原始 state，让调用方自己去凑；比如useDialog暴露open、close、visible，而不是让你手动改一个布尔值。第三，内部不要产生隐式数据流，比如 Hook 内部修改了外部变量、或者硬编码了业务常量，这些会让调用方完全摸不着头脑。

4.4 useReducer：复杂状态管理的隐藏高手

很多项目只要状态一复杂就上外部状态库，其实大部分"多状态联动"场景，useReducer就够了。我去过的一个实时数据面板项目，一个组件同时维护五六个互相影响的状态字段，useState 拆成一堆 setState 调用，逻辑一长就失控。换 useReducer 之后，所有状态变更收敛到 action 类型里，每个变更意图清晰可见，调试时可以非常直观地"回放"整个状态流转过程。

useReducer 的适用信号很明确：setState 调用之间有关联性、有先后顺序、或者有需要集中处理的边界条件。比如提交表单，要同时处理 loading、错误信息、字段校验、成功跳转，用 reducer 集中管理非常顺手。纯前端的状态流转不需要每次都动用 Redux 级别的工具。

5. 状态管理的选择逻辑：从 useState 到外部状态库的完整决策链

状态管理被谈得太多，反而容易让人迷失。我觉得核心问题只有一个：数据需要在多大范围内共享和同步，以及这个数据的变更来源有多复杂。数据流设计清楚了，用什么库只是实现细节。

5.1 不要什么都放进全局状态

在一个业务组件的项目里，全局 store 里的状态大概有多少？我的经验是：只有真正跨页面共享、或者跨深层组件共享的数据才值得放进全局。用户信息、权限标识、主题配置、全局通知列表，这些可以放。一个只在某个表单内部使用、只有两个兄弟组件共享的筛选条件，绝对不应该出现在全局 store 里——它会导致无关页面的重渲染，还会让状态来源变得模糊。

团队里曾有个项目，全局 store 里躺着几十个从 useState 搬到 redux 的"历史遗留"字段，页面渲染性能下降不说，每次新同学接手都会疑惑"这个字段到底是哪个组件在用"。我后来做了一个清理：对每个全局状态字段做 usage 扫描，凡是只在单页面内部使用的，一律改回组件本地状态或 Context，全局 store 瘦身后重渲染性能立刻上去一截。这个经验我一直牢记：全局状态是需要成本的，放进去容易，拿出来难。

5.2 Context 的适用边界：低频、稳定、少量

Context 是 React 内置的"跨层级传值"方案，但它有两个特点需要重视：一是 value 变化时，所有消费该 Context 的组件都会重渲染（除非你手动对子组件做渲染隔离），二是它不适合高频变化的数据。把"鼠标位置"这类高频状态放 Context，页面上每个消费它的事件都被迫重渲染，性能很难看。

所以我的习惯是：Context 放"配置类信息"而不是"业务类数据"。比如主题、语言、当前用户信息，这些变化频率极低、但是被大量深层组件读取。如果想要"上下文传值 + 响应式更新"更强力的组合，可以考虑用 useReducer 配合 Context 形成轻量状态管理，应用规模中等的时候完全够用，不必引入外部依赖。

5.3 外部状态库的引入时机与选型观

真正需要外部状态库的场景，核心信号是"跨组件、跨页面的协作型状态，且变更来源多元化"。比如一个购物车，多个页面都要读写，还要处理异步价格计算、优惠规则、库存校验，这时候靠 Context + useReducer 手写一套状态管理，反而出现大量样板代码。外部库的价值是把"状态的组织方式"和"变更的追踪方式"标准化。

选型上我试过多种库。Redux Toolkit 适合大型、团队协作密集的项目，它有完备的 devtools、中间件生态和规范化约束；Zustand 更轻，API 直接，适合中小项目和想要极简体验的场景；Jotai 更偏原子化，适合状态粒度很细、组件需要细粒度订阅的场景。同一个项目里不要混用多套状态管理，统一才是最优解。我在某跨端项目中开始时用了两套，结果维护成本指数级上升，后来统一收敛才舒坦。

5.4 服务器状态与客户端状态：不要一起管理

这个观念改变了我写数据请求的方式。客户端状态是"界面的临时状态"，比如弹窗开关、下拉框选中项、输入框内容；服务器状态是"服务器数据的缓存视图"，比如用户列表、订单详情、权限列表。两者生命周期完全不同，混在一起会导致大量冗余逻辑——每一次"服务器状态变化"都要手动同步到客户端 store。

解决思路是引入数据请求相关的框架或工具，让"请求-缓存-更新"自动化。目前常见的方案是 React Query/SWR。使用这类工具后，组件直接调用 hook 拿数据，依赖它的缓存机制和失效策略，不需要手动维护"加载完成"标志、跨页面同步更新这些问题，客户端状态管理的负担会骤减。我用过一段时间后，项目里"loading 状态满天飞"的情况基本消失了。

6. 从"能跑"到"能维护"：亲测有效的工程化习惯

最后一部分，聊几个我每次做 React 项目都坚持的工程化习惯。这些可能不是某个 API 的学习，但对项目的长期健康影响不亚于任何技术选型。

6.1 目录组织：按业务域而不是按技术类型

我见过太多项目把目录分成 components / pages / utils / hooks / store，每个目录下再堆一堆文件，业务分散得厉害。长时间后找东西全靠搜索，新功能无从下手。我更习惯按业务域组织：一个业务模块就是一组目录，组件、Hook、状态、样式都在这个域下面。这样的好处是"一个需求只动一个区域"，代码影响范围是局部的，出问题时排查面很小。

当然，跨模块共享的基础组件还是会抽出来放在独立目录，但共享的原则是"被三个以上模块使用才提升"，而不是一开始就把所有东西全抽象到公共层。过早抽象是我见过的最大的工程浪费之一——费力设计的通用能力，最后只有两个地方用，还被过度设计约束得死死的。

6.2 命名和可读性：好的代码是自解释的

React 项目里最常见的坏味道是：组件名含混不清、props 命名只对写的人有意义、多用"data"、"info"这种万能词。我的习惯是：组件名体现职责，比如UserAvatar、OrderStatusLabel；props 命名体现语义，不用data，用user或order；布尔 props 用is、can、should前缀开头，一眼能看出这是个条件。这个看似基本的要求，在真实项目里发现能做到的团队真的不多，但收益是实打实的——code review 效率、新人上手速度都会明显不同。

还有一点，我会尽量避免在 JSX 里写三层以上的三元表达式嵌套。这种代码"能跑"但不可维护，宁可拆成变量或者子组件。渲染逻辑一旦复杂，就值得抽成函数或组件，本质上是把"机器可读但人不可读"的代码，变得对人更友好。

6.3 测试和调试：把时间花在刀刃上

针对 React 组件，我不会每个组件都写测试，重点测试的是"有业务规则的地方"。比如权限判断、状态流转、表格筛选的边界条件。测试不是为了凑覆盖率，是为了让回归成本可控。某项目改一个权限逻辑，10 个页面牵连，有测试和没测试的维护感受完全是天壤之别。

调试方面，React DevTools 的 Profiler 是性能排查第一工具，我几乎每周都用。它能看到每个组件渲染耗时、渲染次数、触发原因，很多"页面为什么不流畅"的问题，打开 Profiler 一看就明白是哪个组件的渲染次数异常。另一个技巧是给 react 应用留一条"严谨模式下排查副作用"的开关——在开发环境开启 StrictMode，能帮助暴露 effect 重复执行的问题。

6.4 Code Review 中最常提的几条 React 审查要点

我在带团队时 code review 会重点关注几类问题：props 命名是否语义化、是否过度使用 context、组件边界是否合理、effect 依赖是否正确、有没有不必要的 useState（能用派生值就别存状态）。其中"能派生就别存储"是很关键的一条：比如fullName可以由firstName和lastName拼接而来，就没必要单独维护一份 state；filteredList可以由list加筛选条件派生而来，也不用 setState 去同步。派生值天然同步，不会出现"数据改了但派生值没更新"的不一致问题。

刚开始做审查时，我也容易纠结于"某个写法是不是绝对正确"，后来发现 React 里绝大多数选择都是权衡而不是对错，关键是每个选择背后是否有明确理由。能对你的每个组件设计、每个状态方案说出"为什么"，这个项目的健康度就不会太差。

最后分享几个我常年保留的 React 实操小习惯

写到最后，分享几个我在多个项目里反复验证有用的细节习惯，不算宏大，但很实用。

第一，善用 key 控制组件生命周期，比如在需求切换时用 userId 作为重置组件的 key，能干净地重置内部所有状态，比手动逐字段清理靠谱得多。第二，大列表使用虚拟滚动，几百上千条数据全量渲染必然卡顿，业界成熟的虚拟滚动库稳定好用，不必自己造轮子。第三，useEffect 里发起请求一定要记得清理——组件卸载后 setState 会在控制台刷一堆警告，更严重的是可能造成状态更新泄漏。第四，生产环境记得关闭 Redux DevTools 和 React StrictMode，这些问题在开发环境不明显，上线后反而会出一些诡异现象。

React 这个框架本身不难学，难的是把它真正用好。我不建议一上来就追求各种高端架构，先把组件边界、渲染机制、状态流向这三件事想明白，比追赶任何新特性都重要。框架的 API 会更新，但组件思维、数据流思维、性能思维这些底层认知，会在你整个前端生涯里持续起作用。