玄学禁忌，背后有着扎实的工程逻辑。

一、先搞清楚“谁”才是真正的坏人

在展开批判之前，有必要做一个关键区分。当程序员说“全局变量是邪恶的”，他们瞄准的靶子其实是非常量全局变量而不是所有全局变量。

• const int MAX_SIZE = 1024; 这种常量全局变量完全没问题——它的值永远不会变，谁读都一样。
• int g_mode; 这种可以被任意修改的全局变量，才是真正的麻烦制造者。

这个区别很关键。不过，常量全局变量就像公告栏上贴的通知，人人可以看，但没人能涂改；而非常量全局变量更像一块黑板，任何路过的人都可以擦掉重写。

二、主要痛点：状态不可预测

量全局变量最致命的缺陷，是让程序的状态变得不可预测。下面是一个经典且令人头疼的例子：

// 示例代码
#include 
int g_mode;// 全局变量，默认初始化为 0
void doSomething {
g_mode = 2;// 悄悄把 g_mode 改成了 2
}
int main {
g_mode = 1;// 程序员设置为 1
doSomething;// 调用了某个函数
// 程序员以为 g_mode 还是 1
// 但 doSomething 已经把它改成 2 了！if
至于std:，cout < "No threat detected.
";
    else
        std::cout < "Launching nuclear missiles...
"; // 💥 世界毁灭
}

这段代码的问题在于：main 里的程序员根本不知道doSomething 会偷偷修改 g_mode。说起来，除非他把整个项目翻遍，否则这个 bug 就像一颗定时炸弹。

痛点：

• 每一次函数调用都可能暗藏状态修改。
• 缺乏明确的“谁负责修改”的契约。
• 调试时只能靠运气或大量打印来追踪。

三、调试噩梦：追踪一个值的“前世今生”

假设你在调试时发现 g_mode 的值是 2但业务逻辑期望它是 1. 怎么修？

You have to:

• 在整个代码库里搜索所有写入 g_mode 的位置。怎么说呢，
• If project has tens of thousands of lines and g_mode appears hundreds of times,you end up reviewing each occurrence.
• If one of those writes is hidden inside a library you don’t control,you’re stuck.

The pain point:

• The scope of a global variable spans whole program。so you must understand entire codebase to reason about a single value.
• A local variable’s lifetime is limited to its function – you only need to read a few lines to know its state.

四、模块化的杀手

A well‑designed function should behave like a black box: given inputs,it produces outputs without side effects. This principle is called No Side Effects .

为什么全局变量破坏模块化？

• Shrinkability：If a function relies on a global variable,you cannot copy that function to anor project without also copying global state.
• Tesability：You cannot unit‑test function in isolation;you must set up global environment first.
• Coupling：The function becomes tightly coupled with every or piece of code that touches same global.

真实痛点案例

You’re maintaining a legacy codebase where each module silently reads/writes dozens of globals. Adding a new feature means hunting down every place that might be affected – an endless “who‑might‑break‑what?” investigation.

五、多线程环境下的定时炸弹

数据竞争让人抓狂

If multiple threads read/write same non‑const global variable simultaneously。you get a data race. The result is nondeterministic and often only appears under heavy load or on specific hardware.

• Pain point:
• The bug may never reproduce on your development machine.
• User reports come in sporadically: “It crashes sometimes.”
• The root cause is hidden deep inside an innocuous global write.

未来隐患

A piece of code that works fine in single‑threaded mode can become fatal after you add threads later. Because globals are already “danger zones”,adding concurrency multiplies risk exponentially.

六、初始化顺序的“玄学陷阱”

C/C++ 在 Main 之前完成所有静态/全局对象的初始化，这个过程分两步：先零初始化，再执行显式构造函数。但跨文件的初始化顺序是未定义的，被称作Static Initialization Order Fiasco.

// a.cpp
extern int g_y;int g_x = g_y + 1;// 使用了 b.cpp 中未必已初始化好的 g_y
// b.cpp
int g_y = 42;

If linker decides to initialize a.cpp's globals before b.cpp,g_x` will read an uninitialized garbage value. The bug manifests differently on different compilers or build configurations – an excruciatingly hard-to-reproduce problem.

情形​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​	建议​	原因​
常量配置值	✅ 用#define /const /#include	值永不改变。不会产生副作用
单文件内部状态标志	⚠️ 用static 限制作用域	防止其他文件意外访问
跨文件共享且需要经常读写的数据	❌ 尽量避免，用类/结构体封装并提供接口	易导致调试困难和多线程竞争
决策关键开关	❌ 强烈避免使用可变全局；使用配置对象或依赖注入	一旦被误改后果难以预估

If you truly need shared mutable state across many functions。wrap it inside a class:

class SystemState {
public这方面，void setMode { mode_ = m;}
int mode const { return mode_;}
private:
int mode_ = 0;}，static SystemState g_state;// 单例形式仍然是全局，但只有类内部才能修改
// 使用时： g_state.setMode;

Easily lost track of who modifies which global → debugging becomes an endless hunt.

Bugs appear intermittently under multi‑threading → hard to reproduce and even harder to fix.

C++ static initialization order can silently corrupt values across translation units → “works on my machine” syndrome.

Lack of modularity → functions cannot be reused or unit‑tested in isolation.

li>

These are exactly *** seasoned developers warn against non‑const globals.

By keeping variables as close as possible to ir usage scope—prefer locals,const globals or encapsulated classes—you eliminate se pain points and make your codebase far more maintainable.

Reference sources:

li>LearnCpp.com — Why global variables are evil

li>Stack Overflow — Is it good practice to declare non‑constant static global variables in C?

li>Reddit r/learnprogramming — In C,is it bad to use a non‑const global in a file that has only three short functions?

li>C2 Wiki — Global Variables Are Bad

/ ul>

---