静态局部变量在嵌入式中断/多线程中危险，因其不可重入：所有调用共享同一静态存储区，isr打断后再次进入会导致变量覆盖、错乱或未定义行为。
静态局部变量在嵌入式中断/多线程中为什么危险
它不是“线程不安全”那么简单，而是根本不可重入——static局部变量存放在静态存储区，所有调用共享同一块内存。一旦函数被中断服务程序（ISR）打断，又在中断里再次进入该函数，count或buffer这类变量就会被覆盖、错乱，甚至触发未定义行为。ARM Cortex-M上常见现象是：调试时正常，开优化后偶发数据错位；RTOS下任务切换时值突变；串口接收回调里用static uint8_t rx_buf[64]，结果两个设备同时收数据就互相踩内存。
哪些场景必须避免静态局部变量
以下情况直接禁用static局部变量，没有例外：
- 任何可能被中断服务程序（ISR）调用的函数，包括注册为GPIO中断、UART RX callback、定时器超时回调的函数
- RTOS中多个任务共用的回调入口（如CAN总线事件统一处理函数）
- 函数内含非原子操作且依赖
static状态做判断（例如static bool initialized = false; if (!initialized) { init(); initialized = true; }） - 函数返回指向
static缓冲区的指针（如const char* get_version() { static char v[16]; ... return v; }）
替代方案：用栈+参数传递代替静态记忆
把状态从“隐式共享”转为“显式传入”，是最轻量、最确定的解法。例如原写法：
void handle_sensor_data() {
static uint32_t last_ts = 0;
uint32_t now = get_tick_count();
if (now - last_ts > 100) {
process_sample();
last_ts = now;
}
}
改成：
struct sensor_ctx {
uint32_t last_ts;
};
void handle_sensor_data(struct sensor_ctx* ctx) {
uint32_t now = get_tick_count();
if (now - ctx->last_ts > 100) {
process_sample();
ctx->last_ts = now;
}
}
关键点：
-
ctx由调用方分配（栈上 or 静态全局结构体），生命周期可控 - 每个任务/中断有自己的
ctx实例，天然隔离 - 不引入锁、不依赖编译器初始化顺序、无RAM额外开销
- 若需跨函数传递，用
void*参数（如FreeRTOS的xTaskCreate参数）或封装成对象（但避免虚函数）
真要保留静态状态？加原子或互斥，且仅限必要路径
极少数场景（如硬件寄存器配置只允许写一次），必须用static状态时，按如下原则收紧：
- 只读状态用
const static（如查表），放.rodata段，无并发风险 - 可写状态必须配同步：中断上下文用
__disable_irq()/__enable_irq()临界区（注意不能嵌套）；RTOS任务间用StaticSemaphore_t+xSemaphoreTake()（避免动态分配） - 禁止在
static变量上做复合操作（如++counter），改用__atomic_fetch_add(&counter, 1, __ATOMIC_SEQ_CST)（GCC 9+）或CMSIS__LDREXW/__STREXW - 永远不要在
static变量上做“检查-执行-赋值”三步逻辑，这是竞态温床
最易被忽略的一点：即使你加了锁，如果该函数又被中断调用，而中断优先级高于当前临界区保护等级，锁就形同虚设——这时候只能靠关中断或设计成纯栈函数。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
