react/jsx-no-constructed-context-values规则作用：未用memo()时是否必要？

你的理解是否正确？ #

不完全准确，核心差异在于Context的订阅机制和普通组件props传递的区别：

• 当Provider的value引用变化时，所有订阅该Context的组件（不管用useContext还是<Consumer>）都会强制重渲染——哪怕这些组件自身用了memo，或者父组件用memo阻止了重渲染。因为memo只负责对比组件的props是否变化，管不了组件内部依赖的Context值变化。
• 如果Provider所在组件重渲染时，value是每次新建的对象（比如{{ something: 123 }}），哪怕订阅组件本来可以通过父组件的memo避免重渲染，也会因为Context值的引用变化被迫重渲染，这会带来不必要的性能开销。
• 只有当value引用稳定时（比如用useMemo包裹），订阅组件才会只在value实际内容变化时重渲染，避免无效重渲染。

所以这个问题的重要性，不只是下游有memo的Consumer时才存在——哪怕没有memo，不稳定的value也可能导致更多不必要的重渲染（比如跨层级的订阅组件，本来父组件的memo能挡住重渲染，却被Context值变化打破）。

为什么ESLint不统一要求所有重建对象用memo？ #

因为Context的value和普通组件props的影响范围、触发逻辑完全不同：

• 普通组件传递新对象作为props，影响的只是单个子组件；如果子组件没用到memo，那父组件重渲染本来就会触发子组件重渲染，传递新对象不会带来额外的重渲染；如果子组件用了memo，那开发者可以根据实际情况决定是否用useMemo稳定props引用，这属于可选优化。
• 但Context的value是共享状态，影响的是所有订阅的组件，一旦引用变化，可能导致大量组件跨层级重渲染，性能影响更大。而且这种重渲染是memo无法阻止的，所以ESLint专门针对这个场景做强制提示，避免开发者无意识引入性能问题。
• 另外，ESLint的规则是针对性设计的，react/jsx-no-constructed-context-values这个规则就是为了规避Context的独特行为带来的性能坑，和普通props的场景不通用。

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