全局变量导致状态不可预测，g_mode值取决于谁先改、改几轮；多线程下易产生竞态，单元测试难隔离；链接时可能报multiple definition错误；嵌入式中还占用固定ram。

全局变量导致状态不可预测

函数调用后，g_mode 值变成 2 还是 1，取决于谁先改、改了几轮——没人能一眼看穿。因为任何函数都能读写同一个 g_mode，调试时你得翻遍所有源文件找赋值点，而不是只看当前函数逻辑。

• 没有调用栈提示“这里改了全局变量”，IDE 也不标红警告
• 多线程下更危险：g_mode 可能被两个线程同时读写，结果既不是 1 也不是 2，而是随机值
• 单元测试几乎无法隔离：一个测试改了 g_mode，下一个测试就继承这个脏状态

链接阶段报错：multiple definition of 'xxx'

两个 .cpp 文件都写了 int config_timeout = 5000;，编译各自通过，链接时报错 multiple definition of 'config_timeout'。这不是语法错误，是链接器发现重复的全局符号。

• 解决办法不是删掉一个，而是用 extern 声明 + 单文件定义，或改用 static 限定作用域
• 更隐蔽的是头文件里误写定义（比如在 common.h 中直接写 int log_level = 1;），每个包含它的 .cpp 都会生成一份定义
• const 全局变量默认有内部链接，所以 const int MAX_RETRY = 3; 放头文件里通常不报错，但非常量不行

嵌入式环境里 RAM 被悄悄吃光

未初始化的全局变量进 .bss 段，已初始化的进 .data 段——它们都占真实 RAM。一个 uint8_t sensor_data[1024] 全局数组，不管用不用，启动就占 1KB。

C++ Code Review Master

组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。

下载

• 局部变量在栈上分配，函数返回即释放；全局变量从开机到关机一直占着
• RTOS 下栈空间紧张，把大缓冲区声明成全局看似省事，实则让所有任务共享同一块内存，容易互相踩
• 静态分析工具（如 cppcheck）常对未使用的全局变量报 warning，但新手往往忽略

替代方案比你想象中更轻量

不用全局变量，并不意味着要重写整个架构。很多场景下，几行代码就能解耦。

• 配置参数：用 struct Config { static constexpr int timeout_ms = 5000; }; —— 编译期常量，零运行时开销
• 跨函数传参：把 g_state 封装进类，用 MyApp& app 当参数传，比裸指针安全，IDE 还能跳转追踪
• 模块间通信：用回调函数或观察者模式，而不是让 A 模块直接改 B 模块的 g_flag

真正难处理的从来不是“怎么去掉全局变量”，而是“哪个函数偷偷依赖了它却没声明接口”。这类隐式依赖，只有在移除时才会浮出水面。

C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！