——从“系统为什么会抖一下”开始，把这件事彻底讲清楚
这一篇，我们不追求短，也不追求快。
目标只有一个：
把“中断与异常”这件事，讲到你能在脑子里“跑一遍系统”。你不需要记住寄存器名，
但你必须知道：
- CPU 在什么情况下会被打断
- 为什么有的打断可以等，有的不能等
- 为什么很多系统问题，看起来像“玄学”，其实都能解释
一、先把话说重一点：中断与异常，是系统秩序的核心
在一颗真实运行的芯片里，
CPU 几乎从来不是顺着你写的 main() 一直跑下去的。
外设在随时说话：
- 数据到了
- 计数到了
- 传输出错了
系统内部也在不断“自检”：
- 地址是不是合法
- 指令是不是能执行
- 栈有没有被踩坏
中断与异常，就是 CPU 面对这种混乱现实时，
用来维持秩序的两套机制。
如果你只把它们当成：
“跳一个函数”
那后面 80% 的问题，你都会觉得莫名其妙。
二、中断和异常的本质区别，不在来源，而在“态度”
2.1 中断：外部世界的请求，CPU 可以选择什么时候回应
中断，本质上是一种请求。
外设不会强迫 CPU 立刻停下来，
它只是举手说：
“我这边有事，你方便的时候看一下。”
所以中断有几个非常重要的特性：
- 异步：和当前执行的代码没有直接因果关系
- 可屏蔽：CPU 可以暂时不理
- 可排序：多个中断可以排队
这也是为什么：
- 中断延迟不是固定值
- 有些中断会被“饿死”
这些现象，本身就是设计的一部分。
2.2 异常：CPU 自己发现问题，不能继续装没事
异常完全不一样。
异常的触发，和当前执行的那条指令强相关。
比如：
- 你这条指令要访问的地址不存在
- 你这条指令算了个除零
在这种情况下，CPU 的态度是：
“我继续执行下去，只会把事情搞得更糟。”
所以异常有几个鲜明特点：
- 同步发生：就在当前指令点
- 不可忽略：必须立刻处理
- 强制跳转：没有“等一等”这种选项
这就是为什么说：
异常不是通知，是刹车。
三、为什么 CPU 需要“被打断”？轮询不行吗？
这是一个很多人心里都会冒出来的问题。
如果你只站在“写代码”的角度，确实会觉得：
我 while(1) 一直查状态不就行了？
问题在于，现实系统有三个你无法回避的事实。
3.1 事实一：外部事件不按你节奏来
串口什么时候来数据，
总线什么时候完成一次传输，
这些都不是你能预测的。
如果你靠轮询：
- 要么查得太频繁，浪费算力
- 要么查得太慢，错过时机
3.2 事实二：CPU 不是只干一件事
在真实系统里：
- 控制逻辑
- 通信
- 安全监测
都在争抢 CPU 时间。
中断的意义在于：
让“重要但不可预测的事情”，能插队进来。
3.3 事实三：实时性需要一个“硬入口”
如果没有中断，
你永远无法给出一句有底气的话：
“这个事件，最多延迟多少时间能被响应。”
所以中断不是优化手段，
而是系统能力的下限保障。
四、中断体系不是一个点，而是一条完整链路
很多资料把中断讲得很“轻”，
仿佛就是一个信号进来、CPU 跳一下。
真实情况要复杂得多。
一次中断，从“发生”到“处理完成”，
至少要经过下面这些环节：
- 中断源产生请求（外设、定时器、DMA）
- 中断控制器记录并排队
- CPU 判断当前是否允许响应
- 硬件自动保存部分现场
- 跳转到统一入口
- 软件分发到具体 ISR
- ISR 执行并清除中断源
- 恢复现场并返回原程序
你在代码里看到的，
往往只是第 6 步。
但系统行为，
是前面 1~5 步和后面 7~8 步一起决定的。
五、什么决定了“中断延迟”？为什么它一定会抖？
这是很多实时问题的核心。
5.1 中断延迟不是一个数，而是一个区间
影响中断延迟的因素包括：
- 当前是否关中断
- 当前正在执行什么指令
- 有没有更高优先级的中断在跑
- 总线和 Cache 是否在忙
所以你能保证的，只能是：
最坏情况延迟（Worst Case Latency）
而不是“平均多快”。
5.2 为什么 Debug 和 Release 表现不同？
因为：
- Debug 会插入额外指令
- Trace/JTAG 会改变时序
- Cache 行为不同
你看到的“稳定”，
往往是系统被放慢了。
六、优先级真正解决的是什么问题？
很多人把优先级理解成：
谁更重要
这是一个非常危险的理解。
6.1 优先级的真实含义
优先级只解决一件事：
谁有资格打断谁。
如果 A 的优先级不能打断 B，
那不管 A 多重要，
它都只能等。
6.2 中断嵌套为什么是“双刃剑”
嵌套确实能降低某些事件的响应延迟，
但代价是：
- 栈深不可控
- Cache 抖动加剧
- 系统分析复杂度陡增
所以在工程上：
中断嵌套不是默认选项，而是被迫使用的工具。
七、异常体系：系统最后一道“自救机制”
如果说中断是在管理外部世界，
那异常就是在处理系统自身的失控风险。
7.1 为什么异常必须立刻发生？
因为异常意味着：
- 当前状态已经不可信
如果你继续执行，
错误只会像墨水一样扩散。
所以异常的设计哲学是：
宁可停得早，也不要错得深。
7.2 为什么很多异常看起来像“直接死机”？
因为：
- 异常发生时，系统状态已经很糟
- 如果你没有提前设计“抓现场”的机制
那 CPU 跳到异常入口时，
你看到的只剩下一个“结果”。
这不是异常太狠，
而是：
你没有给它留后路。
八、中断 / 异常 与实时系统的真实关系
实时系统最怕的不是：
- 慢一点
而是：
- 不知道会慢多久
中断和异常，
直接决定了系统的时间确定性。
8.1 ISR 写得“干不干净”，比优先级更重要
一个 ISR 如果：
- 做了大量计算
- 调用了复杂函数
那它就是在偷走别人的时间预算。
九、那些“系统抖一下”的真实来源
现在，你可以重新看那些熟悉的现象：
- 偶发延迟 → 中断被长时间屏蔽
- 一开某外设就不稳 → 中断风暴
- Debug 稳定，Release 抖 → 时序窗口被放大
这些都不是玄学，
而是中断与异常体系的自然结果。
十、工程级生存原则（非常重要）
- ISR 只做“非做不可的事”
- 中断不是线程，不能当普通函数
- 异常一定要设计“留痕机制”
- 优先级与屏蔽策略，是系统设计的一部分
十一、最后一句话
一个系统稳不稳，
很少取决于你写了多少代码，
而取决于：
当世界突然插话时，CPU 有没有能力优雅地应对。
理解中断与异常体系，
你才真正理解了：
一颗芯片是如何在不确定的世界里，保持秩序运行的。
)
