在研究InheritedWidget 经典案例的时候，我以为只要改了共享变量的值，count++，InheritedWidget 里面监听到count值变了，就会自动通知所有依赖，所以只要设置了count++,不需要调用setState，ui就会更新(就跟Obx变量一样)，这才显得InheritedWidget有逼格,但是实际操作时发现，设置完count++之后，还要调用setState才会更新UI，这.... , setState调用之后，本来就会全局rebuild，那InheritedWidget的意义是啥？

这个问题困扰了很久，现在总算搞清楚了

InheritedWidget并没有我一开始想的那么牛逼，值一变就会立马通知所有依赖项更新，或者说，它确实可以通知所有依赖性更新，但是有一个被我遗忘的前提，那就是，他自己的build被调用，他才会通知所有依赖项更新，如果只是count++,没有调用setState，ShareDataWidget的build是不够重构的，而且这里面有个细节，ShareDataWidget里面的data是final的，

也就是说，在外面直接修改count++，ShareDataWidget里面的data是不会修改的，只有_InheritedWidgetTestRouteState调用rebuild，才会把新的count赋值给ShareDataWidget里面的data，本质上是创建了一个新的ShareDataWidget,然后调用ShareDataWidget里面的updateShouldNotify,这里面会比较新的data和老的data，值不一样，就会通知所有依赖的子组件更新(本质上就是把所有子组件设置为dirty，加入到dirty列表，等待下一次时钟信号就刷新)，

所以，InheritedWidget的data值变量是可以通知所有依赖组件刷新的，只不过，前提是，他自己要先重构，刷新里面的data值，才会进行后面的通知流程

最后再赘述一下，

当_InheritedWidgetTestRouteState里面调用setState(() => ++count)之后，确实会引起全局的rebuild，但是因为ShareDataWidget里面的data可能还没发生变化，_TestWidget里面的count也不会发生变化，所以，第一次全局rebuild，_TestWidget并没有重构，而是等到ShareDataWidget重构完成调用updateShouldNotify的时候再去通知所有的依赖项重构，_TestWidget才重构成功，因为此时他才发现count值变了,刷新ui