全局变量需严格管理：头文件仅用extern声明，单个源文件定义；禁在头文件定义非inline非const变量；避免跨编译单元初始化依赖；多线程须同步访问；推荐函数封装或类封装。
全局变量在 C++ 里不是“用不用”的问题，而是“怎么管住它”的问题——直接定义 int g_count; 能跑，但稍一扩展就崩。
全局变量声明和定义分不清，链接错误 undefined reference to `g_var'
常见现象：头文件里写了 extern int g_var;，多个 .cpp 都 #include 了，编译报错找不到定义。
- 声明（
extern int g_var;）只告诉编译器“这玩意儿存在”，不分配内存；定义（int g_var = 0;）才真占空间 - 定义只能出现在一个源文件里，否则链接时重复定义报错
- 推荐做法：头文件只放
extern声明；选一个 .cpp（比如globals.cpp）放定义
头文件里直接写 int g_flag = 1;，导致 ODR 违规
现象：每个包含该头文件的 .cpp 都生成一份 g_flag，链接时报 multiple definition，或运行时值不一致。
- C++ 标准禁止在头文件中定义非 inline、非 const 的变量（C++17 之前）
-
const int g_max = 100;可以——因为隐式static，每个 TU 独立副本，不违反 ODR - C++17 起可用
inline int g_counter = 0;，但注意：所有 TU 中的inline定义必须完全一致，且仅限变量，不适用于函数外的普通初始化逻辑
跨编译单元访问全局变量，初始化顺序不确定
现象：A.cpp 里 int g_a = func();，B.cpp 里 int g_b = g_a + 1;，但 g_b 总是 1 ——func() 没被调用，g_a 还是 0。
立即学习“C++免费学习笔记（深入）”；
- 不同 .cpp 文件的全局变量初始化顺序未定义（ISO C++ standard §3.6.2），编译器不保证谁先谁后
- 不要在全局变量初始化表达式中依赖其他 TU 的全局变量
- 替代方案：用函数封装，靠首次调用保证初始化，比如
int& get_g_a() { static int val = func(); return val; }
想线程安全？别碰裸全局变量
现象：多线程下 g_counter++ 结果随机，std::cout << g_msg; 输出乱码。
- 读写非原子类型（如
int、std::string）必须加同步，std::mutex或std::atomic<int> - 即使
std::atomic，也要注意：g_str = "hello";不是原子操作，得用std::atomic<std::string*>加指针管理，或换锁 - 更稳妥的做法：把状态封装进类，构造时初始化，用成员函数控制访问路径
全局变量真正的麻烦不在定义，而在“谁改了它”“什么时候改的”“改完谁看到了”。哪怕只是调试时加个 printf 打印 g_debug_flag，也得确认它没被另一个线程悄悄覆写。这种隐式耦合，比编译错误更难揪。
