主题：全局变量"满天飞"！！！局限性和影响有哪些，什么情况下才不得不使用？
一、全局变量为什么会被"狠批"？
全局变量在嵌入式开发中，几乎是"人人喊打"的存在。但很多刚入行的同学，尤其是实习生，往往因为图方便、图省事，随手就定义一堆全局变量，结果代码越写越乱、越改越难改。今天我就从"为什么不能滥用全局变量"说起，再讲清楚"什么时候不得不用"，最后给出"实在要用该怎么用"的代码示例。
二、全局变量的局限性与负面影响
1. 破坏模块化，代码耦合度极高
全局变量可以在任何地方被读写，导致模块之间高度耦合。一个模块修改了全局变量，另一个模块的行为可能莫名其妙就变了，排查问题极其困难。
2. 可读性差，难以理解数据流向
代码中到处是 g_xxx、g_yyy，你根本不知道这个变量在哪个函数里被修改过，也不知道修改的时机和条件，阅读和维护成本极高。
3. 可测试性差，单元测试几乎无法做
单元测试要求"隔离环境"，但全局变量把状态散布在整个程序里，你很难构造一个干净的测试环境，也很难验证某个函数在特定输入下的行为。
4. 多任务/中断环境下，容易产生竞态条件
在 RTOS 或多中断场景下，全局变量被多个任务/中断同时访问，如果没有加锁或使用原子操作，很容易出现数据不一致、状态错乱等难以复现的 Bug。
5. 生命周期不可控，资源管理混乱
全局变量从程序启动到结束一直存在，如果它持有资源（如动态内存、外设句柄），很容易出现"谁申请谁释放"不明确的问题，导致内存泄漏或资源泄露。
三、什么情况下才"不得不"使用全局变量？
虽然全局变量问题很多，但在嵌入式开发中，确实有一些场景很难完全避免：
1. 硬件寄存器映射
很多 MCU 的寄存器是通过全局结构体或宏映射到固定地址的，这是硬件设计决定的，无法避免。
2. 中断服务程序（ISR）与主循环之间的数据交换
中断中不能调用带锁的函数，也不能做复杂操作，通常只能通过全局标志位或缓冲区与主循环通信。
3. 系统级配置参数
如系统时钟频率、外设使能状态等，这些参数在系统初始化后基本不变，且多个模块都需要访问，用全局变量或只读全局结构体比较合适。
4. 资源极度受限的单片机
在资源极其紧张（RAM 只有几 KB）的 MCU 上，为了节省栈空间，有时不得不把一些大数组或结构体放在全局区。
5. 跨模块的只读常量
如字库、图片资源、配置表等，这些数据在运行时不修改，且多个模块都需要访问，用 const全局变量是比较合理的。
四、实在必须使用全局变量时，要用结构体整合
如果确实需要全局变量，一定要遵循一个原则：用结构体把相关全局变量打包，并尽量通过接口函数访问，而不是直接读写。
1. 为什么用结构体？
减少全局变量数量：把多个相关变量打包成一个结构体，全局变量数量从 N 个变成 1 个。
提高可读性：通过结构体成员名，能清晰看出这些变量属于哪个模块、哪个功能。
便于封装：可以配合 static和接口函数，实现一定程度的封装，减少直接访问。
2. 代码示例：用结构体整合全局变量
假设我们有一个按键模块，需要记录按键状态、消抖计数等，传统写法可能是：
c
// 传统写法：一堆全局变量
uint8_t g_key_pressed = 0;
uint32_t g_key_debounce_cnt = 0;
uint8_t g_key_last_state = 0;这种写法的问题很明显：变量散落、可读性差、容易误修改。
改进写法：用结构体整合
c
// 按键模块全局状态结构体
typedef struct {
uint8_t pressed; // 当前按键状态
uint32_t debounce_cnt; // 消抖计数器
uint8_t last_state; // 上一次状态
} key_state_t;
// 全局结构体实例（尽量用 static 限制作用域）
static key_state_t g_key_state = {0};
// 获取按键状态的接口函数
uint8_t key_get_pressed(void)
{
return g_key_state.pressed;
}
// 设置按键状态的接口函数（内部可做校验）
void key_set_pressed(uint8_t state)
{
g_key_state.pressed = state;
}
// 按键处理函数（示例）
void key_scan(void)
{
uint8_t current = read_key_gpio();
if (current != g_key_state.last_state) {
g_key_state.debounce_cnt = 0;
} else {
g_key_state.debounce_cnt++;
}
if (g_key_state.debounce_cnt >= DEBOUNCE_THRESHOLD) {
g_key_state.pressed = current;
}
g_key_state.last_state = current;
}3. 多任务/中断环境下的保护
如果按键扫描在中断中执行，而主循环会读取按键状态，就需要考虑竞态条件：
c
// 使用原子操作或关中断保护（示例）
uint8_t key_get_pressed_safe(void)
{
uint8_t ret;
// 关中断保护（具体实现取决于平台）
__disable_irq();
ret = g_key_state.pressed;
__enable_irq();
return ret;
}或者使用 RTOS 提供的互斥锁：
c
// 使用 RTOS 互斥锁（示例）
static osMutexId_t g_key_mutex;
void key_init(void)
{
g_key_mutex = osMutexNew(NULL);
}
uint8_t key_get_pressed_rtos(void)
{
uint8_t ret;
if (osMutexAcquire(g_key_mutex, osWaitForever) == osOK) {
ret = g_key_state.pressed;
osMutexRelease(g_key_mutex);
}
return ret;
}4. 只读全局配置的写法
对于系统配置参数，建议用 const修饰，并放在单独的头文件中：
c
// config.h
typedef struct {
uint32_t sys_clk_hz; // 系统时钟频率
uint8_t uart_baudrate; // 串口波特率索引
// ... 其他配置
} sys_config_t;
extern const sys_config_t g_sys_config;
// config.c
const sys_config_t g_sys_config = {
.sys_clk_hz = 72000000,
.uart_baudrate = 3,
// ...
};这样其他模块只能读取配置，不能修改，既安全又清晰。
五、总结与建议
能不用全局变量就不用：
优先使用局部变量、函数参数、返回值传递数据。
必须用时，用结构体整合：
把相关全局变量打包成结构体，减少全局变量数量。
提供接口函数访问：
通过 get/set函数访问全局结构体，而不是直接读写。
多任务/中断环境要加保护：
使用原子操作、关中断或互斥锁保护共享数据。
配置参数用 const 全局：
系统配置、资源表等只读数据，用 const全局变量或结构体。
有什么想法，欢迎大家评论