React重渲染规则：props.children不变时局部状态变更的组件渲染差异

两个示例表现不同的根源，是Demo组件在组件树中的归属作用域完全不同，不存在React的特殊黑盒优化逻辑：

• 第一个children props场景的实际结构：Demo组件是由最外层的App组件创建、作为children参数传入Top组件的。Top本身是counter状态的持有者，当counter更新时Top会触发自身重渲染，但Top接收到的children是一个引用完全不变的React元素对象——它是App在自己的渲染流程中提前生成好的，和Top自身的渲染逻辑完全解耦。React在做diff比较时，发现这个children节点的引用和上一次渲染完全一致，就会直接跳过对应组件的重渲染流程，因此Demo不会触发重渲染。
• 第二个局部状态变更场景的实际结构：Demo组件是直接写在Top组件的内部渲染逻辑里的，是Top渲染树中的直接后代。当Top因为自身状态更新触发重渲染时，会在自身的JSX生成阶段重新创建Demo的React元素，沿着组件树向下进入diff流程。因为Demo没有做任何React.memo之类的渲染优化，默认只要父组件重渲染、收到的元素引用变化，就会触发自身的重渲染逻辑，因此控制台能看到Demo的重渲染日志。

• React的状态更新传播是有固定边界的：一个组件的状态变更，只会触发自身以及自身渲染范围内的后代组件的重渲染，永远不会反向触发上层组件、或是不属于自己作用域的外部组件的重渲染。
• children本质上只是父组件收到的一个普通prop，和其他数字、字符串类型的prop没有区别：只要这个prop的引用没有变化，哪怕父组件自身重新执行了渲染函数，也不会触发children指向的组件重渲染。很多开发者的认知误区来自于JSX的书写形式——不管Demo的代码写在Top标签的内部还是外部，只要这个元素的创建者是上层的App，它就不属于Top的渲染作用域。
• 不存在针对Top组件的“自动智能优化”：所有重渲染的触发和跳过，都是基于固定的渲染链路、引用对比逻辑运行的，没有针对局部状态变更的特殊判断分支。

两个场景的组件树归属差异可以简化为：

1. children props场景的元素链路：

   App （创建<Demo />元素）
   └── Top （持有counter状态，接收App传下来的<Demo />作为children prop）
   

   Top更新时，只是复用了App早就传过来的Demo元素，不会主动重新渲染Demo。
2. 局部状态变更场景的元素链路：

   App
   └── Top （持有counter状态，在自己的JSX里创建<Demo />元素）
       └── Demo
   

   Top更新时，会在自己的渲染函数里重新生成Demo的元素，顺着组件树向下传播diff，触发Demo的渲染判断。

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