与建筑物颤振有关的许多问题归结为错误的（例如显示一个）。答案通常提供使用BuildContext或使用SnackBar的方法。两种方法都有效，但我注意到GlobalKey的文档说明：
全球密钥相对昂贵。如果您不需要上面列出的任何功能，请考虑改用Builder、GlobalKey、Key或ValueKey。
所提到的特征是唯一的识别和子树重新育儿。在这些情况下使用ObjectKey的“相对费用”是否足以代替使用UniqueKey的原因？
最佳答案
我们倾向于避免的真正原因不在于性能。这与它在颤振中破坏一些模式的事实更为相关。
根据定义，小部件不应该能够访问其他小部件的具体信息（例如它们的大小或位置）。并且授予访问这些信息的能力；允许人们做反模式的事情。
将GlobalKey视为弹出颤振反应层的方法。
下面是一些使用GlobalKey的示例，说明人们想要做什么：
有一个公共的单身。用作不提升状态的手段。很难预测小部件之间的交互，因为这种关系不再是单方面的（父/子关系变成了双向关系）
使用GlobalKey计算布局的大小。然后使用此信息触发重新渲染。这是GlobalKey的角色，不应该在小部件中执行。它使布局更难维护
另一方面，不要破坏这些模式。因为，根据定义，GlobalKey什么都不做。这只是一种使用不同GlobalKey的简单方法。
这通常意味着，如果您可以使用RenderObject而不是Builder来解决布局问题，那么您就可以使用可维护布局了。
何时使用Builderthen？
好吧，如果你能，永远不会。尝试使用诸如BuildContext或Builder之类的东西。您可能还需要考虑为特定布局创建一个自定义的GlobalKey。如果您需要父母/子女之间的关系，GlobalKey与context.ancestorStateOfType结合可能也是您想要的。
但这可能更复杂。它会消耗比你想要的更多的时间。或者您可能会陷入使用当前API难以实现的边缘情况。
在这种情况下，只要知道潜在的后果，就可以使用context.inheritWidgetOfExtactType。