Flutter路由跳转时为何ChangeNotifierProvider会从组件树消失？

两种写法的组件树本质差异 #

• 第一种（Provider会丢失的场景）的层级链路是：
  根Widget → MaterialApp → 根Navigator路由栈 → 首个路由（home）节点 → ChangeNotifierProvider → SplashWidget
  这里的home参数本身就是根Navigator管理的第一个路由的根节点，你挂载在这个节点下面的所有组件，都属于这个路由的私有子树。
• 第二种（Provider正常保留的场景）的层级链路是：
  根Widget → ChangeNotifierProvider → MaterialApp → 根Navigator路由栈 → 首个路由（home）节点 → SplashWidget
  这里的Provider挂载在MaterialApp节点之上，完全处于Navigator的管理范围之外。

为什么pushReplacement会导致Provider消失 #

Navigator.of(context).pushReplacement的行为逻辑非常直白：

把当前栈顶对应的整个路由子树从组件树中完全移除，再把新路由对应的子树插入到栈顶位置。

可以把根Navigator理解成一个存放页面路由的文件夹，每个路由都是文件夹里的独立文件，文件内容就是对应页面的完整组件子树。你把ChangeNotifierProvider写在了Splash这个路由文件的内容里，现在你用pushReplacement把整个Splash文件替换成Home文件，写在Splash内容里的Provider自然就跟着被一起删掉了。

这种场景下哪怕你不用pushReplacement，只要你把Splash页面对应的路由从栈里移除，Provider就一定会消失，和跳转方法本身没有特殊关联。

为什么放在MaterialApp上方的Provider不会丢失 #

Navigator的所有路由操作，都只会修改自身管理范围内的组件子树，绝对不会越界修改自己父级的组件节点。
当Provider挂在MaterialApp之上时，它属于MaterialApp本身的父级节点，不管Navigator在自己的栈里怎么替换页面、压入弹出路由，都完全碰不到这个Provider节点，自然会一直保留在组件树中。

为什么说“把Provider放在MaterialApp上方不被推荐” #

这个说法本身是有前提的，不是放上面就是错的：

• 如果你的状态是全局共享的（比如用户登录信息、全局配置、跨页面通用的业务状态），把Provider放在MaterialApp上方是Flutter生态里的标准写法，完全符合官方推荐的最佳实践。
• 不推荐的场景是：你把只给特定页面使用的局部状态，放在了MaterialApp这么高的层级。这种写法会导致状态的生命周期被错误拉长——哪怕对应使用的页面早就被销毁了，状态实例还会一直留在内存里，容易造成不必要的内存占用甚至泄漏。
  简单说：Provider的放置位置完全由它的作用范围决定，全局状态就放高层，页面局部状态就放在对应页面的子树里，没有绝对的位置对错。

ChangeNotifierProvider有没有特殊的持久化能力 #

完全没有。
ChangeNotifierProvider本身没有任何跨路由保留状态的特殊逻辑，它的生命周期和它挂载的组件节点完全绑定：只要节点还在组件树上，它创建的状态实例就会保留；节点被移除，它就会自动销毁状态实例，没有任何例外。

如果你既不想把全局Provider放得太高，又想让Provider在Navigator跳转时不被销毁，可以把Provider挂载在MaterialApp.builder下，这种写法的位置在MaterialApp内部、所有Navigator路由的上层，既不会越出App的作用域，又不会被路由操作销毁：

MaterialApp(
  builder: (context, child) {
    return ChangeNotifierProvider(
      create: (context) => MyModel(),
      child: child!,
    );
  },
  home: SplashWidget(),
)

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