企业官网建设流程全解析

React 组件巡检，重点是找出不该发生的更新

页面出现卡顿时，“加一个 memo”往往是最先想到的办法，也是最容易白做的办法。组件重新渲染并不天然是错误：用户输入、筛选结果更新、路由切换都需要渲染。真正值得处理的是一次局部交互触发了大范围、与当前内容无关的更新。

日常巡检的目的不是把渲染次数压到最低，而是建立一个可解释的基线。关键页面在搜索、切换 tab、展开详情这些操作下，哪些组件会提交、提交花了多久、数据量变化后是否明显退化，都应该能被复现和比较。

先从更新来源，而不是组件名字开始

React Profiler 能记录一次提交耗时，但读数据时要结合交互路径。父组件更新会让子组件进入渲染流程；context value 更换会通知所有订阅者；props 中每次都创建的新对象和回调，会让 memo 无法跳过。看到列表渲染多次后，先确认是哪一种原因，而不是立刻在每一层包 memo。

常见的边界问题包括：把搜索输入、弹窗开关和用户资料塞进同一个 context；列表行从父组件拿到整个用户对象而实际只用名字；为每行创建不稳定的 style 对象；筛选时在渲染函数中反复做排序和复杂计算。它们不一定每次都造成明显问题，但在数据量变大后会共同放大。

列表滚动的性能还和 DOM 数量有关。若页面确实需要展示很长的结果集，虚拟化比微调单行组件更有效。不过虚拟化也要验证键盘导航、动态高度和辅助功能，不能只看滚动帧率。

指标收集要低侵入，不能反过来拖慢页面

可以在开发、测试或抽样环境给关键区域加 Profiler，收集组件标识、阶段、实际耗时、提交时间和当前交互标签。不要把每次渲染都同步上报到后端，这样采集本身可能成为新的请求噪声。聚合后再上报，或只在测试环境读取内存中的结果，会更稳妥。

阈值不应照搬别的项目。不同机器、浏览器扩展和数据量都会影响时间。先从同一环境下的历史数据建立基线，再把明显偏离的变化作为提示。巡检结果可以让 CI 标记风险，但不要因为一次波动就阻塞每个 PR；真正的阻断规则需要稳定、可重现。

采集的范围也要克制。包住整个应用只会得到一个很粗的数字，难以定位；给每个小按钮都加探针又会淹没结果。优先选择用户明显感知的区域，例如搜索结果、编辑器、数据表和复杂弹窗。

修复时让数据接口更窄

优化通常从缩小 props 开始。列表行只需要 id、标题和选中状态，就不必拿到整个页面状态。回调若传给 memo 化子组件，可以在父层保持稳定，或让子组件用 id 组合自己的事件。对象字面量和数组转换若确实造成重复更新，再考虑缓存；不要为了“规范”把所有表达式都套进 useMemo。

context 也可以按变化频率拆分。主题、当前用户等低频数据与输入框内容、流式文本等高频数据不该共用一个 value。拆分后要注意读取位置，避免为了取一个字段又让组件订阅多个频繁变化的源。

修复前后用同一组操作跑一次采样：输入一段固定文本、快速切换筛选项、滚动到长列表中段、打开并关闭详情。若更新次数下降但交互结果错了，说明状态边界拆得不对。性能优化必须以功能正确为前提。

渲染巡检最终给团队的不是一份“谁渲染得最多”的排行，而是一条反馈线：某次改动是否扩大了更新范围，是否让常用操作跨过了可接受的等待时间。把这条线放进日常开发，性能问题就不必总等到用户抱怨后才出现。