React中创建大量组件是否会影响应用性能？

首先纠正一个常见认知偏差："创建过多React组件会影响性能"是脱离适用场景的过时经验，合理拆分组件本身就是React缩小重渲染范围、提升运行性能的核心手段，不需要为了刻意减少组件数量把所有逻辑、状态、UI堆在单个巨型组件里。

这个说法的来源不是组件数量本身会拖慢性能，而是早年React版本的组件初始化开销较高，加上很多人无意义过度拆分、拆分后写法不规范导致的无效重渲染，才会给人"组件多了卡"的错觉。实际开发可以按下面的原则落地：

• 按职责边界做拆分，不刻意凑组件也不刻意不拆。判断是否要拆出独立组件的核心标准不是代码行数，而是这部分内容是否满足三个条件之一：有独立的内部状态、有独立的更新触发源、会在多个场景复用。比如表单场景下把每个输入项拆成独立组件管理自身的校验、输入状态，远比把所有输入项的状态全堆在表单根组件性能更好——单输入项更新只会触发自身重渲染，不会拖整个表单所有节点一起重绘。
• 拒绝无意义的过度拆分。那种只有1-2行静态JSX、没有独立状态、没有复用价值、仅在单个位置使用的"薄组件"不要拆，这类组件除了增加虚拟DOM遍历开销、提升代码维护成本外没有任何收益。
• 拆分后配合正确的重渲染拦截逻辑，不要滥用memo。默认React的更新逻辑是父组件重渲染会递归触发所有子组件重渲染，当你拆分出的子组件本身没有状态变更、传入的props也没有变化时，才需要给函数组件套React.memo、给类组件继承PureComponent做浅比较拦截重渲染。注意如果父组件每次渲染都给子组件传内联函数、临时创建的对象/数组这类引用类型props，就算套了memo也无法拦截重渲染，这种场景下的性能问题是写法不规范导致的，和组件拆分无关。
• 不要提前做臆想型性能优化。开发阶段先按职责边界正常拆分组件完成业务逻辑，等实际遇到交互卡顿、加载慢等问题时，再用React DevTools的Profiler工具定位具体的性能瓶颈点，针对性做调整即可，没必要在写代码阶段就过度纠结"组件多了会不会影响性能"。

补充一个背景：React 16推出Fiber架构后，函数组件的初始化开销已经做了多轮优化，正常业务场景下，合理拆分组件带来的可维护性提升、重渲染范围缩小的性能收益，远大于组件实例化产生的微小开销。

内容的提问来源于stack exchange，提问作者Pedro