全局变量生命周期从程序启动到结束，作用域默认为定义它的翻译单元；const全局变量默认内部链接以支持头文件常量定义；多线程读写需atomic或锁防护；静态局部变量更安全且线程安全。
全局变量的生命周期和作用域怎么算
全局变量从程序启动就存在，到程序结束才销毁，所有函数都能访问——但“能访问”不等于“能直接用”。它在定义它的翻译单元（通常是 .cpp 文件）里才有外部链接，默认其他文件看不到。
常见错误现象：undefined reference to 'g_counter'，明明定义了全局变量却链接失败，就是因为另一个文件里只写了 extern int g_counter; 却没在任何地方真正定义它，或者定义在头文件里被多个 .cpp 包含导致重定义。
- 定义只能出现一次：在某个 .cpp 里写
int g_counter = 0; - 其他文件要用，必须用
extern int g_counter;声明（不要加=） - 千万别在头文件里写
int g_counter = 0;，否则每个包含它的 .cpp 都生成一份定义，链接时报错
const 全局变量为什么默认是内部链接
C++ 规定：带 const 且非 extern 的全局变量，默认是 internal linkage（只在当前文件可见），哪怕它是基本类型。这不是 bug，是设计——为了方便头文件里定义常量而不引发 ODR 违规。
使用场景：你想在头文件里写一个“看起来像全局常量”的东西，比如 const double PI = 3.14159;，又不想每次包含都出链接错误，它就靠这个规则活下来。
- 想让它跨文件用？显式加
extern const double PI;在头文件，再在某个 .cpp 里定义const double PI = 3.14159; - 如果只是
const int N = 100;，它本质是个编译期常量，多数编译器会内联，不会分配存储空间——所以你甚至没法取它的地址（除非强制用&N，这时编译器才真给它分配） - 注意：
const std::string s = "hello";不同，它有构造函数，必须有定义，不能只在头文件里声明+初始化
多线程下读写全局变量有多危险
全局变量天然跨线程可见，但 C++ 不保证对它的读写是原子的——哪怕只是 ++g_counter;，背后也是读-改-写三步，两个线程同时执行就会丢更新。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
性能影响：加锁（如 std::mutex）会串行化访问，可能成瓶颈；用 std::atomic 虽快，但不是所有类型都支持，且要注意内存序。
- 基本整型计数器优先用
std::atomic<int> g_counter{0};</int>，比 mutex 轻量 - 结构体或对象别直接用 atomic 包裹，得自己保证操作的原子性，或者换锁
- 千万别以为“只读不写”就安全：如果写线程正在修改，读线程可能看到撕裂值（尤其是非对齐、跨 cache line 的变量）
静态局部变量 vs 全局变量，什么时候该换
如果你只需要“第一次调用时初始化、之后一直存在”，但又不想暴露给整个模块，静态局部变量是更干净的选择。它延迟初始化、线程安全（C++11 起），且作用域锁死在函数内。
容易踩的坑：有人用全局变量模拟单例，结果初始化顺序不确定（不同 .cpp 里的全局变量初始化顺序未定义），导致 A 依赖 B，但 B 还没构造完。
- 把
MyClass& get_instance() { static MyClass inst; return inst; }当作首选，而不是全局MyClass g_instance; - 静态局部变量的析构顺序也确定：按构造逆序，在 main 返回后执行
- 但注意：它不能用于需要显式控制生命周期的场景（比如想在 main 结束前手动清理）
全局变量本身不难理解，难的是它把链接、初始化、并发、生命周期这些横切关注点全搅在一起。哪怕只是加个 static 或 extern，语义就彻底不同——漏掉一个修饰符，可能让程序在优化后行为突变。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
