React性能优化：将对象定义在组件外避免重渲染的方案是否有缺陷？

方案可行性结论 #

在你给出的这个示例场景下，该方案是可行的：
因为person是完全固定的静态对象，定义在组件外部后引用地址永远不会变化，配合React.memo对子组件的props浅比较逻辑，确实可以避免父组件状态更新触发的子组件不必要重渲染，且这种方式的性能开销比用useMemo包裹还要略低，不需要在每次父组件重渲染时执行依赖比对逻辑。

存在的核心缺点 #

这个方案的适用场景极窄，存在很多不可忽视的问题：

• 无法支持动态数据需求：如果后续person的值需要依赖组件内部的state、props或者React上下文数据，组件外部的定义根本无法访问到这些运行时的动态值，完全无法满足需求，只能写死静态常量。
• 存在全局数据污染风险：你这里用let定义的是模块级别的共享变量，整个JS文件的任意逻辑都可以直接修改这个对象的属性，甚至如果同一个组件被多次实例化，所有实例会共享同一个person对象，一处修改全量受影响；而且直接修改这个对象不会触发React的重渲染，会出现数据和UI不一致的问题，排查难度非常高。
• 不兼容服务端渲染(SSR)场景：在Next.js等SSR框架下，模块级变量会在多个用户请求之间共享，不同用户的请求可能拿到被其他请求修改过的person值，出现跨请求的数据串扰，完全不符合服务端渲染的请求隔离要求。
• 维护成本高：后续如果需要调整person的生成逻辑，只要涉及依赖组件内部数据，就需要把整个定义逻辑迁移到组件内部，改动成本高；同时大量模块级的零散变量也会降低代码的可读性，逻辑拆分不如集中在组件内部清晰。
• 无法支持响应式更新：如果person的内容需要随业务逻辑动态更新，外部定义的对象无法触发组件的自动重渲染，最终还是需要把它放到React的状态管理体系中，之前的优化逻辑完全作废。

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