问题不在于它们有多坏，而在于它们有多危险。他们有自己的优点和缺点，在某些情况下，他们要么是最有效的，要么是完成特定任务的唯一方法。然而，它们很容易被误用，即使你采取措施总是正确使用它们。

一些优点:

可以从任何函数访问。 可以从多个线程访问。 在项目结束前都不会超出范围。

一些缺点:

可以从任何函数访问，而不需要显式地作为参数拖入和/或记录。 不是线程安全的。 污染全局名称空间并可能导致名称冲突，除非采取措施防止这种情况。

请注意，如果你愿意的话，我列出的前两个优点和前两个缺点是完全相同的事情，只是措辞不同。这是因为全局变量的特性确实是有用的，但使它们有用的特性正是它们所有问题的根源。

一些问题的潜在解决方案:

Consider whether they're actually the best or most efficient solution for the problem. If there are any better solutions, use that instead. Put them in a namespace [C++] or singleton struct [C, C++] with a unique name (a good example would be Globals or GlobalVars), or use a standardised naming convention for global variables (such as global_[name] or g_module_varNameStyle (as mentioned by underscore_d in the comments)). This will both document their use (you can find code that uses global variables by searching for the namespace/struct name), and minimise the impact on the global namespace. For any function that accesses global variables, explicitly document which variables it reads and which it writes. This will make troubleshooting easier. Put them in their own source file and declare them extern in the associated header, so their use can be limited to compilation units that need to access them. If your code relies on a lot of global variables, but each compilation unit only needs access to a handful of them, you could consider sorting them into multiple source files, so it's easier to limit each file's access to global variables. Set up a mechanism to lock and unlock them, and/or design your code so that as few functions as possible need to actually modify global variables. Reading them is a lot safer than writing them, although thread races may still cause problems in multithreaded programs. Basically, minimise access to them, and maximise name uniqueness. You want to avoid name collisions and have as few functions as possible that can potentially modify any given variable.

它们是好是坏取决于你如何使用它们。大多数人倾向于不好地使用它们，因此对它们普遍持谨慎态度。如果使用得当，它们可以成为一大福音;然而，如果使用不当，它们可能会在你最意想不到的时候回来咬你一口。

从一个好的角度来看，它们本身并不坏，但它们导致了糟糕的设计，并且会成倍地增加糟糕设计的影响。

即使你不打算使用它们，知道如何安全使用它们并选择不使用，也比不使用它们因为你不知道如何安全使用它们要好。如果您发现自己处于需要维护依赖于全局变量的预先存在的代码的情况下，如果您不知道如何正确使用它们，那么您可能会遇到困难。

正如有人在另一篇文章中所说的那样:“在你完全理解这样做的后果之前，不应该打破这样的规则。”

有时候，全局变量是必要的，或者至少是非常有用的(例如，处理系统定义的回调)。另一方面，他们也非常危险，因为所有你被告知的原因。

编程的许多方面可能应该留给专家去做。有时候你需要一把非常锋利的刀。但在你准备好之前，你不能使用它……

是的，因为如果你让不称职的程序员使用它们(阅读90%，尤其是科学家)，你最终会得到600多个全局变量分布在20多个文件和一个12000行的项目中，其中80%的函数采用void，返回void，完全在全局状态下运行。

除非你了解整个项目，否则你很快就不可能在任何一个点上理解正在发生什么。

全局变量通常很糟糕，特别是当其他人正在处理相同的代码，并且不想花20分钟搜索变量被引用的所有位置时。添加修改变量的线程带来了一个全新的问题。

在单个翻译单元中使用匿名名称空间中的全局常量是很好的，在专业应用程序和库中无处不在。但是如果数据是可变的，并且/或者它必须在多个tu之间共享，那么您可能想要封装它——如果不是为了设计，那么也是为了任何人调试或使用您的代码。

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

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

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