企业官网建设流程全解析

前阵子清理代码仓库，翻出一个相当偷懒的目录名：rea。没有后缀，没有说明文档，当初建这个内部项目的人早就转岗了。顺着代码往回查，才发现这个三字母缩写背后是一整套实时日志看板的前端工程——从最开始的自然语言需求，陆续演变成React技术栈主导的状态管理、性能优化和异常恢复方案。如果你也在维护一个“只有简写代号”的老系统，或者正在做数据密集型页面的React重构，这篇内容应该能对上胃口。

这个代号有意思的地方在于它模棱两可。有人说是real简化，有人说是realtime摘出来的，还有人觉得是react的前半截。其实哪种都说得通，三种解释恰好对应了项目三条主线的来源：真实数据接入、实时刷新逻辑、React组件体系。我花了大半天时间把这一团乱麻捋清楚，最后发现它本质上是一个典型的“标题信息过载、正文信息缺失”的工程——代码很多，但能直接说明设计意图的文字几乎为零。这篇文章就记录一下我是怎么把这个残缺标题还原成一整套可运行、可维护、可复现的系统，以及过程中踩过的坑。

1. 从写在白板上的三字母，到一份能落地的需求清单

先说清楚这个rea系统到底长什么样。它本来是一个给运维和研发同事用的日志查看面板，需要把后端推送过来的日志流实时渲染到浏览器里，支持按级别、关键字、时间范围过滤，还要能展示某一行的上下文。听起来不复杂，但旧版本的人均使用体验是：打开页面等3秒，滚动页面卡成PPT，日志一多浏览器直接崩溃。

我接手时的第一反应不是去看代码，而是花了半天时间做需求反推。因为代码本身也没有注释，唯一明确的线索就是“rea”这个目录名。我把它的三种可能解释分别拉出来，对应成三组问题：真实数据怎么来、实时刷新怎么做、React组件怎么组织。用这种方式把标题里的歧义变成一个需求矩阵，比直接闷头读源码要快得多。

1.1 “rea”的三层含义对应三类工程问题

这三列一下子就把项目边界划清了。很多同事一开始以为工作重点是“把表格做出来”，实际上核心难度在第二列和第三列：实时数据流怎么进浏览器，以及大量数据进来之后React怎么扛住渲染压力。后面所有技术选型都是围绕这两点展开的。

1.2 从需求清单反推出“不做清单”

需求反推最容易跑偏的地方，是想把什么东西都塞进第一个版本。我当时的做法是给每一项需求打三个标签：必须做、最好做、以后再说。比如“日志按时间回放”属于以后再说，因为旧系统里根本没有人用过；“单条日志定位到源码文件”属于最好做，但没有它也不影响核心闭环；“每3秒自动拉取新日志”属于必须做，因为这是实时性的底线。

最后形成的工作清单基本只有五件事：数据通道、日志缓存、过滤与检索、列表渲染、异常恢复。标题里的“rea”给出的只是方向感，真正决定工期的是这份清单。对于一个只有代号、没有文档的旧项目来说，先把需求画出来再谈重构，比直接优化一个不知道在解决什么问题的组件要稳妥得多。

2. 数据流重构：从十来个互改对方的 state，到单一事实来源

旧版本最让人头疼的不是界面丑，而是状态完全散落。光是一个日志级别筛选，就有三个组件各自存了一份；关键字输入框每次敲一个字，父组件setState之后，全页面十几个子组件全部重新渲染一遍。我把这种状态叫做“互改对方的state”：A组件改了B组件要用的数据，B组件再通过回调把结果传回A，循环到最后没人知道当前真正生效的过滤条件是什么。

React的受控组件在这里就是双重陷阱。表面上input框直接绑定value和onChange，即时反馈，实际上每一个按键都触发了从input到父组件再到整棵组件树的state更新。日志列表里如果有几千行，哪怕每行只是虚拟内容，也会跟着一起重算。我用一个点击按钮的断点测试过：一次按键最深层子组件被调用了两万多次，浏览器卡顿完全是意料之中。

2.1 状态分类：哪些该进reducer，哪些该留在原地

我的解法不是上重型状态管理库，而是先把状态按照“生命周期”分成三类：

• 服务端状态：日志数据流本身、连接状态、最后同步时间
• UI状态：当前选中行、折叠状态、关键字输入框的草稿值
• 派生状态：过滤后的日志列表、统计数字、高亮标记

服务端状态单独放在请求层管理，用一个简单的发布订阅缓存住最新数据。UI状态收进useReducer，集中到页面容器里。派生状态一律不存state，组件渲染时现场计算。这个分法最大的好处是让每条数据只有一个“法定来源”，不会出现同一份日志列表在两个组件里各存一份修改副本。

// 过滤目录看到这种结构，基本就是状态被拆碎了的信号 const [logs, setLogs] = useState([]) const [keyword, setKeyword] = useState('') const [level, setLevel] = useState('') const [filteredLogs, setFilteredLogs] = useState([]) const [visibleLogs, setVisibleLogs] = useState([]) // 重构后：filteredLogs和visibleLogs全部删掉，渲染时再算 const state = useReducer(logReducer, initialState)

2.2 Context value 的引用稳定性，比业务本身更容易踩坑

把状态收敛完之后，我又踩了一个更隐蔽的坑：虽然reducer里的state结构清晰了，但只要我把整个state对象通过Context传给子组件，任何一个子组件调用dispatch，所有消费了这个Context的组件都会重新渲染。第一次实测时性能比旧版还差，因为旧版只是“渲染很多”，新版是“每次按键都重新渲染很多”。

解决办法是把Context拆成两个：一个只放dispatch，一个放state。同时用useMemo把state字段拆成最小粒度的value对象传给真正需要的子组件，避免整棵树一锅端。这里有一个值得记住的经验：reducer解决的是“状态该放在哪”，useMemo解决的是“状态变了谁该重新渲染”，两者是正交问题，不能混着谈。

2.3 数据流重构后的对照效果

这组数据并不夸张。对于一个中等复杂度的数据面板来说，状态收敛带来的性能收益是立竿见影的，因为它直接砍掉了大量无效渲染的来源——不是优化渲染本身，而是让不该发生的渲染根本不发生。如果你正在做一个列表、筛选、详情互相联动的页面，我建议你也先盘一下当前状态到底散落在多少个组件里，这一件事做完，比任何性能插件都管用。

3. 渲染性能：从刷屏式渲染到虚拟列表的两次试错

状态收敛之后，页面逻辑上已经干净了，但还有一个硬骨头：日志来了就是要上屏。比较极端的场景是后端一次性补发3万行历史日志，浏览器要把它们全部渲染成行。我第一次用重构后的版本跑这个场景，整个页面卡死了6秒，鼠标移动都是锯齿状。

很多文章会从React.memo、useMemo这些细节开始讲性能优化，但我的真实体验是：数据量级不对的时候，微优化全是白费功夫。3万行DOM元素摆在那儿，div数量可能超过10万个节点，这已经不是“减少几次render”能解决的问题，而是要从渲染数量上做减法。

3.1 第一轮试错：给所有子组件套 React.memo，效果却接近为零

我最初怀疑是父组件更新导致每个日志行组件都重渲染，于是给日志行组件套了React.memo，又把过滤方法用useCallback包好。结果实测性能只提升了不到5%，原因有两个：一是日志列表本身没有任何子组件，每行渲染时都会创建新的对象引用；二是React.memo只对props浅比较有效，我当时传进去的是一个包含复杂对象的行数据，浅比较永远判断为“变了”，memo直接失效。

严格的memo需要配合不可变数据结构才有效。比如把日志行的对象更新成新引用，memo一看引用变了自己就知道该重渲染。但日志数据本身是追加型增长，旧行根本不更新，给它们套memo纯属浪费。正确的做法是让日志行组件只依赖基础的不可变字段，比如id、level、message，任何派生高亮都放到行组件内部去算。

3.2 第二轮试错：useMemo 用错了依赖数组，越优化越慢

改用useMemo缓存过滤后的列表时，我又犯了一个典型错误：把依赖数组填得过于“精确”，字段多到只要日志对象有一点变化就重新计算。日志流是典型的高频追加场景，每次推送都新增好几条数据，结果useMemo形同虚设，还额外增加了比较成本。

后来我把依赖收敛成“只有当关键字、级别、时间范围这三个筛选条件变化时才重新计算过滤”，日志本身的追加完全走增量管道，不再触发全量过滤。这一改效果非常明显：输入一个关键字从原来的300ms降到30ms左右。每次看到这里我都想提醒同行：useMemo不是用来“防止计算”的咒语，它的本质是“让不必要重复的计算避免发生”，依赖数组才是真正的核心。

3.3 决定性优化：虚拟滚动，只渲染看得见的行

真正让3万行日志跑顺的是虚拟滚动。思路很简单：浏览器只渲染可视区域内的那十几行，滚动时通过定位偏移把当前显示内容快速切到新的行区间。外面的容器高度仍然用总行数撑开，所以滚动条的滑动范围是符合用户预期的。

// 伪代码：固定行高时的可视区换算 const rowHeight = 24 const containerHeight = 700 const visibleCount = Math.ceil(containerHeight / rowHeight) // 滚动时根据scrollTop算出startIndex，然后只渲染这visibleCount+缓冲行

这套方案的收益可以从两个角度看：一是DOM节点数量从3万降到100个以内，渲染时间从秒级降到毫秒级；二是事件处理和滚动计算的开销也大幅降低，因为页面同时只存在极少数行组件。再加上一个针对滚动位置的rAF节流，实测滚动帧率稳定在60fps附近。

3.4 优化前后对比，量级差距比系数差距更值得关注

这个对比说明了一件事：遇到大数据量渲染别急着抠组件细节，先算清“页面同时最多需要多少个DOM节点”，这个问题解决掉，后面所有优化才有意义。我后来把所有列表类场景都默认按虚拟滚动处理，哪怕数据只有几千行，也当成上万行的规模来设计，因为用户总会有一天塞进比预期更多的数据。

4. 页面白屏：一次线上事故逼出来的错误边界设计

数据流和渲染都优化完了，系统上线跑了一个多月都挺稳。然后有一天运维同事发来消息：页面白屏了，控制台一堆红色报错。我第一反应是后端接口挂了，但接口状态码正常，数据也返回了。真正的原因是在某次发布中，后端日志结构加了一个新字段，而旧缓存里的数据没有这个字段，叶子组件读了一个undefined的属性值，异常冒泡到根部，整个React应用直接白屏。

React应用的一个老问题在这次事故里暴露无遗：只要有一个子组件在渲染阶段抛出未捕获异常，整棵树都会挂掉，页面变成空白。这不是某个组件的问题，而是缺少配套的异常兜底机制。

4.1 白屏事故的完整排查链路

我不建议一看到白屏就急着改代码，先把排查步骤固定下来，能省很多时间：

1. 先看浏览器Network面板，确认核心接口是否正常返回，排除网络和服务端问题
2. 再看Console面板，抓住第一个抛错信息，滚动到调用栈最底层，定位到具体组件文件
3. 用接口返回的原始数据构造一个最小复现页面，本地复现白屏现象
4. 对比本次发布和前一次版本的差异，找出新引入的数据结构假设
5. 修复数据缺失问题，同时补上兜底逻辑

那次定位最终落在一个展示字段上。后端在对象里新增了traceId，但旧日志没有这个字段，前端组件直接渲染obj.traceId.children，结果traceId本身就不存在，等于在一个undefined上面继续取属性，自然抛错。修复很简单，加一层可选链和默认值就行。但如果没有错误边界，这类问题会以“整个页面白屏”这种最糟糕的方式暴露出来。

4.2 ErrorBoundary 怎么用才算真正兜住底

React官方提供错误边界能力的方式是类组件里实现getDerivedStateFromError和componentDidCatch。我把整个主内容区域包了一层ErrorBoundary，约定所有子组件渲染异常都先落到这里，页面不会整体白屏，而是降级显示一个“当前区域暂时不可用，数据已为你保留”的提示，同时自动触发一次数据重拉。

class ErrorBoundary extends React.Component { constructor(props) { super(props) this.state = { hasError: false, errorInfo: null } } static getDerivedStateFromError() { return { hasError: true } } componentDidCatch(error, errorInfo) { // 异常信息不能吞掉，要上报到监控系统 reportError({ error, errorInfo }) } render() { if (this.state.hasError) { return <FallbackUI onRetry={() => this.setState({ hasError: false })} /> } return this.props.children } }

有一个实际约束要知道：错误边界捕获不到事件处理器、异步代码和服务端渲染中的错误。比如用户点击按钮后请求失败的场景，错误发生在onClick回调里，错误边界根本感知不到。这类错误要靠try-catch配合全局error事件兜底，然后把用户操作路径一起上报。错误边界加全局监控，两层配合才算完整的恢复机制。

4.3 把“异常态界面”当成正常需求来做

经过这次白屏事故，我把“异常态显示”正式写进了需求模板：数据为空时、接口超时时、渲染出错时、局部数据缺失时，每个状态都要有对应的界面。以前这些往往被当成边界情况忽略，但线上环境永远不按你的预想出牌。宁可多写几个可降级的组件，也不能再让整个页面变成一个没有信息量的白屏。

现在团队内部有一条不成文规则：任何新增组件在合入主分支之前，必须主动做一次“断字段”测试，把组件依赖的数据对象里的字段随机删除几个，看组件是否优雅降级。这种做法成本极低，却能把白屏事故这类问题的发生率压到最低。

5. 这套组合拳的适用范围：从日志看板到表格、表单与工作台

写到这里可能有人会问：这个rea项目的经验是不是只能用在日志看板上？我的答案是完全不是。日志看板最大的特点是数据量大、更新频率高、展示密集，而这三个特征在审批中心、监控大盘、数据报表、流程追踪、知识库列表这些页面上同样存在。只要页面符合“表格或列表 + 高频更新 + 筛选项联动”，这套方法论基本都可以平移。

我把整个项目沉淀下来的思路归纳成四条检查线，每次做类似页面时都会从头过一遍：

1. 需求反推线：先确认这个页面到底解决谁的问题，数据从哪里来，最不能挂掉的是哪条路径
2. 数据流线：状态按服务端、UI、派生三类拆分，不该进state的坚决不进state
3. 渲染分治线：先看量级再做微优化，优先考虑虚拟滚动和增量渲染，再考虑memo和缓存
4. 兜底恢复线：每个异常场景都必须有可展示的降级界面，错误监控要覆盖渲染错误和异步错误

5.1 一个真实的移植案例：把日志方案用到审计列表

正好后来团队要做一个新的审核记录列表，每一行代表一次审核操作，单表数据预计会到几十万条，还要支持按操作者、时间段、结果状态实时过滤。我们没有重新设计架构，直接把rea方案里服务端状态加虚拟滚动的部分搬过去，再在UI状态里加了一个跨页选择标志，整个开发周期压缩到了原来的三分之一。

这个案例让我真正体会到，“可复现的工程模板”比“单一的页面组件”价值高得多。组件只能解决一个界面，模板可以解决一类问题。当你把一个项目拆成需求、状态、渲染、恢复四个层次之后，任何新页面都可以快速对号入座，知道自己该重点解决哪一层。

5.2 代号短是好事，但也提醒我们要写上下文

“rea”这个三字母代号，优点是任何人提起来都不费力，缺点是如果当初没有配套的说明文档，后来者要花很长时间去猜它到底是什么。我的习惯是：代码里可以继续用短简写，但仓库根目录一定要放一个几十行的README，写明白这个项目是什么、给谁用、核心数据管道怎么走。后来我每次看到代码仓库里的裸缩写目录，都会先补一个说明文档再动手改代码，这个习惯确实避免了好几次误伤。

整套重构走完，我最深的体会是：做这类系统，页面好看只是顺带的结果，真正要紧的是让数据流、渲染数量和异常恢复都在你的掌控之内。与其被一个又一个线上问题追着跑，不如把四道检查线前置到设计阶段。该砍的渲染要敢砍，该兜的底要提前兜，该写清楚的需求背景一定要写清楚——这样就算某天所有文档都丢了，后来者面对“rea”这种三字母代号，也不会觉得无从下手。