全局变量导致状态不可预测，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，但新手往往忽略
替代方案比你想象中更轻量
不用全局变量，并不意味着要重写整个架构。很多场景下，几行代码就能解耦。
立即学习“C++免费学习笔记（深入）”；
- 配置参数：用
struct Config { static constexpr int timeout_ms = 5000; };—— 编译期常量，零运行时开销 - 跨函数传参：把
g_state封装进类，用MyApp& app当参数传，比裸指针安全，IDE 还能跳转追踪 - 模块间通信：用回调函数或观察者模式，而不是让 A 模块直接改 B 模块的
g_flag
真正难处理的从来不是“怎么去掉全局变量”，而是“哪个函数偷偷依赖了它却没声明接口”。这类隐式依赖，只有在移除时才会浮出水面。
