你是不是也遇到过这种情况：串口中断明明进了，接收完成标志也在中断里置 1 了，可主循环就是没反应？

或者外部按键中断已经触发，调试时也能看到中断函数执行了，但 while(1) 里的判断像“瞎了一样”，一直读不到变化。

更离谱的是，代码在 Debug 模式下好好的，一切正常；一旦开了优化，或者换成 Release 编译，项目直接卡死。你开始怀疑中断、怀疑串口、怀疑芯片，最后发现问题竟然出在一个小小的关键字：volatile。

很多初学者第一次看到 volatile，会觉得它只是“修饰变量”的东西，好像可有可无。其实在单片机项目里，它非常关键。尤其是中断、定时器、串口接收、ADC采样完成标志、DMA完成标志这些场景，不加它，程序可能真的会跑飞。

先看一个很常见的代码：

uint8_t rx_done = 0;

void USART1_IRQHandler(void)
{
    // 假设这里接收完成
    rx_done = 1;
}

int main(void)
{
    while (rx_done == 0)
    {
        // 等待串口接收完成
    }

    // 处理接收到的数据
}

这段代码看起来没毛病吧？

中断里把 rx_done 改成 1，主循环检测到之后继续往下走。逻辑很顺。

但编译器不一定这么想。

在编译器眼里，rx_done 在 while 循环里并没有被修改。它只看到主函数里面一直在判断这个变量，却没看到主函数里有人改它。于是编译器为了提高效率，可能会把 rx_done 读到寄存器里，然后反复判断寄存器里的值。

问题来了：中断确实把内存里的 rx_done 改成 1 了，但主循环一直盯着寄存器里的旧值看。

这就像你在办公室门口贴了“有人来了”的纸条，结果门卫一直低头看自己手里的旧纸条，根本不抬头看门口。你说气不气？

正确写法应该是这样：

volatile uint8_t rx_done = 0;

void USART1_IRQHandler(void)
{
    rx_done = 1;
}

int main(void)
{
    while (rx_done == 0)
    {
        // 等待中断修改标志位
    }

    // 处理数据
}

volatile 的意思不是“这个变量很重要”，也不是“这个变量不能改”。

它真正想告诉编译器的是：这个变量可能会在你看不见的地方被修改，每次用它的时候，都老老实实去内存里重新读取，不要自作聪明缓存起来。

在单片机里，什么叫“你看不见的地方”？

最典型的就是中断。

比如按键中断：

volatile uint8_t key_flag = 0;

void EXTI0_IRQHandler(void)
{
    key_flag = 1;
}

while (1)
{
    if (key_flag)
    {
        key_flag = 0;
        // 处理按键事件
    }
}

再比如定时器标志：

volatile uint8_t tick_1ms_flag = 0;

void TIM2_IRQHandler(void)
{
    tick_1ms_flag = 1;
}

还有串口接收完成、DMA传输完成、ADC转换完成，这些本质上都是：一个地方改变量，另一个地方读变量。

初学者最容易错的地方，就是把“代码逻辑正确”当成“程序一定正确”。

但嵌入式不一样。你的程序不是从上到下一条路跑完的。中断会突然插进来，DMA会自己搬数据，外设寄存器会自己变化，硬件状态不是主函数说了算。

所以，只要变量会被中断修改、被主循环读取，就要认真考虑 volatile。

不过这里有个大坑：volatile 不是万能药。

它只能保证“每次都去读真实变量”，不能保证操作是安全的。

比如下面这个代码：

volatile uint32_t count = 0;

void TIM_IRQHandler(void)
{
    count++;
}

如果主循环也在修改 count，比如：

count++;

这就不一定安全了。

因为 count++ 不是一个动作，它通常包含三步：先读出来，再加 1，再写回去。中断如果刚好插在中间，就可能造成数据丢失。

所以项目里遇到共享计数器、状态机变量、多个字节的数据时，不能只靠 volatile。必要时要关中断保护一下：

__disable_irq();
temp = count;
__enable_irq();

或者在 RTOS 里用队列、信号量、任务通知，不要靠一个全局变量硬扛。

还有一个场景也必须用 volatile：直接访问硬件寄存器。

#define GPIOA_IDR  (*(volatile uint32_t *)0x40020010)

因为寄存器的值可能随硬件变化。比如输入引脚电平，上一秒是 0，下一秒就是 1。编译器如果觉得“这个地址我刚读过，不用再读了”，那整个外设驱动就废了。

所以你会发现，芯片厂家给的头文件里，寄存器定义基本都带 volatile。不是他们写着好看，而是项目真会翻车。

总结一下，单片机里什么时候该用 volatile？

中断里改、主循环读，要用。

主循环改、中断里读，也要用。

硬件寄存器、外设状态寄存器，要用。

DMA会改的数据缓冲区，很多时候也要考虑用，至少相关状态标志一定要谨慎处理。

但变量只是普通局部计算，没人异步修改，就别乱加。乱加 volatile 会影响优化，让代码变慢，也会让真正的问题被掩盖。

我以前调串口接收时就踩过这个坑。中断函数进了，数据也收了，标志位也写了，主循环就是不动。加断点正常，不加断点卡死。后来才发现，优化等级一开，编译器直接把标志位“记住”了。

所以记住一句话：在单片机里，凡是可能被中断、DMA、硬件偷偷改变的变量，都别让编译器猜，明确加上 volatile。

很多项目问题，不是逻辑错了，而是你以为编译器会按你想的方式执行。

收藏这篇，下次遇到“中断改了变量，主循环却读不到”的玄学问题，先回来看看是不是 volatile 忘了加；也欢迎留言说说你踩过的最离谱嵌入式坑。