重要的是要记住总体目标:清晰

“无全局变量”规则的存在是因为大多数时候，全局变量使代码的含义不太清楚。

然而，像许多规则一样，人们记住的是规则，而不是规则的意图。

我曾经见过一些程序，为了避免全局变量的危害，通过传递大量参数，使代码的大小增加了一倍。最后，使用全局变量将使程序对阅读它的人更清楚。由于盲目地遵守规则的文字，原来的程序员未能实现规则的意图。

所以，是的，全局变量通常不好。但是如果你觉得在最后，程序员的意图通过使用全局变量变得更加清晰，那么就继续吧。但是，请记住，当您强迫某人访问第二段代码(全局代码)以理解第一部分是如何工作的时，清晰度会自动下降。

只有在别无选择时才应该使用全局变量。在90%的情况下，引入全局变量是为了节省传递参数的成本。然后发生多线程/单元测试/维护编码，你就有问题了。

是的，在90%的情况下全局变量是不好的。在你的大学生活中，不太可能遇到例外。我能想到的一个例外是处理固有的全局对象，比如中断表。像DB连接这样的东西似乎是全局的，但不是。

我认为你的教授试图在一个坏习惯开始之前就阻止它。

全局变量有自己的位置，就像许多人说的，知道在哪里和何时使用它们可能很复杂。所以我认为与其深入研究全局变量的原因，方式，时间和地点教授决定禁止。谁知道呢，将来他可能会取消禁令。

是的，但是在停止使用全局变量的代码并开始编写使用全局变量的代码之前，您不会招致全局变量的成本。但成本依然存在。

换句话说，这是一种长期的间接成本，因此大多数人认为这并不坏。

我想要反驳这篇文章所提出的观点，即它使多线程更加困难或根本不可能。全局变量是共享状态，但全局变量的替代方法(例如传递指针)也可能共享状态。多线程的问题在于如何正确地使用共享状态，而不是该状态是否恰好通过全局变量或其他方式共享。

大多数情况下，当你执行多线程时，你需要共享一些东西。例如，在生产者-消费者模式中，您可以共享一些包含工作单元的线程安全队列。您可以共享它，因为该数据结构是线程安全的。当涉及到线程安全时，队列是否是全局的完全无关紧要。

在这个线程中隐含的希望是，在不使用全局变量的情况下，将程序从单线程转换为多线程会更容易，这是天真的。是的，全局变量让搬起石头砸自己的脚变得更容易，但搬起石头砸自己的方法有很多。

我并不提倡全局变量，因为其他观点仍然成立，我的观点仅仅是程序中的线程数与变量作用域无关。

在企业内的web应用程序中，可以用于在服务器上保存会话/窗口/线程/用户特定的数据，以优化和保存连接不稳定时的工作损失。如前所述，需要处理竞争条件。我们使用类的单个实例来获取这些信息，并且对其进行了仔细的管理。