Flutter中setState()如何重建子组件？两种写法差异及底层原理

这是个非常好的问题，正好能帮你吃透Flutter里Widget、Element和State三者的核心协作逻辑，我来一步步拆解清楚：

先明确两种写法的本质差异 #

首先抓准两个写法的核心区别：

• 写法1（直接在build里写StatefulChild()）：每次父组件执行build()时，都会创建一个全新的StatefulChild实例
• 写法2（复用成员变量statefulChild）：父组件的State类里提前维护了一个固定的StatefulChild实例，每次父build都是直接复用这个对象

底层更新逻辑深度解析 #

Flutter的UI更新依赖于Widget树、Element树、State三者的配合，核心逻辑是通过对比新旧Widget的变化，来决定是否更新对应的Element和State：

对于写法1：每次创建新的子Widget实例 #

当你点击按钮触发父组件的setState()后：

1. 父组件的build()被调用，生成新的Widget树，这里会创建一个全新的StatefulChild对象
2. Flutter框架开始对比新旧Widget树：在子组件的位置，旧Widget是上一次build创建的StatefulChild实例，新Widget是这次的新实例
3. 因为两者的runtimeType（都是StatefulChild）和key（默认都是null）都匹配，框架会复用现有的Element和对应的State对象（不会销毁重建State）
4. 但由于新Widget是不同的实例，框架会调用StatefulElement.update()方法，把新Widget传递给Element
5. 这个过程会触发State.didUpdateWidget()（哪怕你的子Widget没有任何属性变化），同时会将Element标记为dirty（需要更新）
6. 最终，子组件的build()方法会被执行，所以你会看到"Child00 build method invoked"的日志

对于写法2：复用同一个子Widget实例 #

当父组件setState()后：

1. 父组件build()执行，但子组件的位置复用的是同一个StatefulChild实例（引用完全相同）
2. Flutter框架对比新旧Widget时，发现这个位置的Widget引用完全相等（==判断为true），会直接跳过这个Element的更新流程
3. 子Element不会被标记为dirty，所以子组件的build()方法不会被触发，自然看不到子组件的build日志

补充几个关键知识点 #

• Widget的相等性判断：Flutter默认用==来判断Widget是否需要更新，而Widget默认继承自DiagnosticableTree，没有重写==方法，所以默认是引用相等（即只有同一个实例才会被认为是相同的Widget）
• 不要修改Widget的属性：如果你尝试修改成员变量statefulChild的属性（比如statefulChild.title = "new title"），这是违反Flutter设计原则的——Widget应该是**不可变（immutable）**的，这样会导致Widget配置和实际状态不一致，引发奇怪的bug
• 如何让复用的子组件也触发build：如果需要让复用的子组件在父组件更新时也执行build，可以通过以下方式：
  • 给子组件添加唯一的Key，强制框架对比Widget的属性而非引用
  • 在子组件内部使用setState()触发自身更新
  • 使用状态管理工具（如Provider、Riverpod）将状态提升，让子组件响应状态变化

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