我们倾向于避免的真正原因
GlobalKey与性能无关。它与以下事实更为相关：它会打乱一些图案。
根据定义，小部件不应能够访问其他小部件的具体信息（例如其大小或位置）。并
GlobalKey授予访问此类信息的能力；允许人们做反模式的东西。
可以认为
GlobalKey是 弹出 Flutter反应层的一种手段。
举个例子说明人们倾向于使用的方法
GlobalKey：
- 公开单身
GlobalKey
。用作不 提起国家的手段 。使得小部件之间的交互变得难以预测，因为这种关系不再是单面的（父母->孩子变成了双向关系） - 使用
GlobalKey
来计算布局的大小。然后使用此信息触发重新渲染。相反，这是RenderObject
小部件中的角色，不应在小部件中完成。这使布局难以维护
Builder另一方面，类似的东西不会破坏这些模式。按照定义
Builder， 什么 也 没有做
。这只是使用其他方法的一种巧妙方法
BuildContext。
这通常意味着，如果您可以使用
Builder而不是来解决布局问题
GlobalKey，那么您将走上可维护布局的正确轨道。
什么时候使用
GlobalKey呢？
好吧，如果可以，永远不会。尝试改为使用诸如
context.ancestorStateOfType或
context.inheritWidgetOfExtactType。您可能还需要考虑
RenderObject为特定布局创建自定义。如果您需要父母/孩子之间的关系
RenderObject，
parentData则也可以与结合
但是，这可能更加复杂。它可能消耗比您想要的更多的时间。否则您可能陷入使用当前API难以实现的极端情况。
在这种情况下，
GlobalKey只要您知道潜在的后果，就可以使用。
