要在showModalBottomSheet中使用Provider，我需要用ChangeNotifierProvider包装我的MaterialApp。如果MaterialApp与多个ChangeNotifierProviders嵌套在一起，这些CC_6主要用于处理特定屏幕的底部表，是否会对性能产生影响?在showModalBottomSheet中使用Provider还有其他有效的方法吗?
添加多个提供商或在MaterialApp之上使用MultiProvider是完全可以的，这实际上是为全局依赖做正确的事情。
MultiProvider嵌套大量依赖项，则会有潜在的性能影响。这与小部件树的性能关系不大，而是一次实例化大量小部件所带来的影响。
正如文档所解释的那样，有一些方法可以解决这个问题，包括拆分依赖项并根据状态加载它们，或者简单地避免使用MultiProvider。你的问题特别要求用多个ChangeNotifierProviders包装你的MaterialApp，而不是使用MultiProvider，所以我认为你在这方面很好。
对你的问题更彻底的解释是，你的Providers需要插入到Navigator之上用于你在堆栈上推送的新路由，无论是使用Navigator.push,showModalBottomSheet，还是根据你使用的导航样式修改Navigator.pages，以便能够通过上下文访问那些Provider。
MaterialApp构建你的"根"这就是为什么他们需要在MaterialApp之上。如果你正在使用嵌套导航的模式，我们在我工作的应用程序中使用了很多，你需要确保你想要的任何Provider在特定的嵌套Navigator中都在Navigator之上。除了能够重用这些"内部旅程"之外，您还可以定制这些导航树所需的依赖项(Providers或其他InheritedWidgets)，从而允许您只在需要的地方注入所需的内容。
你不需要，也不应该仅仅为了在情态动词(any)中使用它，就把你的提供商包裹在整个应用程序中。只需使用提供程序的.value构造函数，并将已经创建的提供程序提供给适用于该模式的新部件树(上下文)。
在SO上有几个这样的例子，以及为什么你不应该用一堆不必要的提供者包装你的整个MaterialApp的例子和解释。