显然，人们对于这个问题有许多不同的意见，从“永远不要使用全局变量！即使只是一个宏也要封装起来！”到“没有什么大不了的——在需要时使用它们比不使用更方便。”
因此，需要具体而明确的原因（最好附带示例）：
虽然这是主观的，但我会选择一个答案（对我来说最能代表每个开发者与全局变量之间的爱恨关系），而社区将投票选出他们认为最好的答案。
我认为新手有这样的参考资料很重要，但如果存在与您的答案实质上相似的另一个答案，请不要混淆它——可以添加评论或编辑其他人的答案。
变量应该尽可能具有较小的作用域。这背后的原因是，每当您增加作用域时，就会有更多的代码可能修改变量，从而在解决方案中引入更多的复杂性。
因此，很明显，如果设计和实现自然允许，避免使用全局变量是首选。由于这个原因，除非真正需要，我不喜欢使用全局变量。
我也不能同意“永远不”的说法。像任何其他概念一样，全局变量只有在需要时才应该使用。我宁愿使用全局变量，而不是使用一些人工构造（如传递指针），这只会掩盖真正的意图。
一些使用全局变量的好例子包括单例模式实现或嵌入式系统中的寄存器访问。
关于如何实际检测过度使用全局变量：检查、检查、检查。每当我看到一个全局变量时，我都必须问自己：这真的需要在全局范围内吗？
唯一让全局变量工作的方法就是给它们命名以确保它们是唯一的。
通常这个名字有一个前缀，与一些“模块”或函数集合相关联，这些函数特别关注或具有意义的全局变量。
这意味着这个变量“属于”这些函数——它们的一部分。事实上，全局变量通常可以与其他函数一起“包装”在同一 .h 文件中，使用相同的名称前缀。
奖励。
这样做后，它不再是真正的全局变量了。它现在是一些相关函数的模块的一部分。
这始终可以做到。通过一点思考，每个以前的全局变量都可以被分配给一些函数集合，分配给特定的 .h 文件，并使用函数隔离，允许您更改变量而不会破坏任何东西。
与其说“永远不要使用全局变量”，不如说“将全局变量的职责分配给一些最合适的模块。”
C语言中的全局变量在多个方法中需要使用同一个变量时可以提高代码的可读性（而不是将变量传递给每个方法）。但是，它们很危险，因为所有位置都有修改该变量的能力，这可能会导致难以追踪错误。如果必须使用全局变量，请始终确保只有一个方法直接修改它，并让所有其他调用者使用该方法。这将使跟踪与该变量更改相关的问题更加容易。
当你不用担心线程安全问题时：可以在适合的地方使用全局变量，换言之，在适合表达为全局状态的任何地方都可以使用。
当你的代码可能会被多线程调用时：尽量避免使用全局变量。将抽象的全局变量转换成工作队列或其他线程安全结构，或者如果绝对必要，将其包装在锁中。但请记住，这些很可能是程序中的瓶颈。
我曾经一直坚持“从不使用全局变量”的立场，直到我开始在国防工业领域工作。有一些行业标准要求软件必须使用全局变量而非动态内存（在C语言中是malloc）。因此，我需要重新考虑我对于某些项目的动态内存分配方式。如果你能够使用合适的信号量、线程等来保护“全局”内存，那么这种内存管理方法是可以被接受的。
你需要考虑全局变量将在什么上下文中使用。未来是否希望这段代码复制。
例如，如果您正在使用系统内的套接字访问资源。未来是否希望访问多个这些资源，如果是，则首先避免使用全局变量，以免需要进行重大重构。
