为何不可恢复的段错误（segfaults）被称为fault而非abort？

这个问题真的戳中了很多人对异常分类的误区！先帮你把几个核心术语的定位理清楚，再好好唠唠段错误的命名为啥看似矛盾～

• Interrupt（中断）：硬件主动发起的“紧急招呼”，比如键盘按下去、磁盘IO完成了，硬件会给处理器发信号，让操作系统赶紧停下手里的活，去处理这个硬件请求。
• Trap（陷阱）：软件主动发起的“求助申请”，比如程序执行int这类指令（x86架构里的系统调用指令），主动喊操作系统过来帮忙干活——本质是程序自己要切换到内核态拿服务。
• Fault（故障）：处理器碰到了能“抢救”的错误，抛出异常后，操作系统有机会把问题修复，让程序回到出错前的指令重新跑。比如常见的页错误：程序要访问的内存页还在磁盘上，内核把页加载到物理内存后，程序就能接着执行了。
• Abort（中止）：处理器碰到了彻底救不回来的致命错误，此时整个执行状态已经烂到根了，连回到出错点重新尝试的机会都没有，只能直接把整个执行流程掐断。

这里的关键是：“可恢复”的判断标准是处理器/内核的能力，不是应用程序能不能接着跑。

段错误的本质是程序越界访问了不属于它的内存（比如空指针解引用、数组越界），处理器检测到这个违规操作后，会抛出#PF（页故障）或者#GP（一般保护故障）——这些都属于Fault类异常。

内核收到这个异常后，从技术层面它完全能把处理器的状态拉回正轨：它知道错误出在哪个指令，也能重置处理器到稳定状态。但问题在于，应用程序的逻辑已经崩了——你都访问空指针了，后续代码的执行逻辑已经完全没有意义，内核总不能帮你把程序的逻辑错误给修复了吧？所以内核最终只能选择终止进程。

而Abort类异常是那种连处理器自己的状态都救不回来的情况：比如处理器拿到了完全无法解码的垃圾指令，或者内部硬件出了故障，此时连“回到出错指令重试”的可能性都没有，只能直接拍桌子中止所有操作。

总结一下：

• Fault：处理器能“复位”到出错前的状态，只是内核觉得应用程序没救了才终止它，但技术上的恢复能力是存在的。
• Abort：处理器自身都已经彻底失控，根本没有任何恢复的可能。

内容的提问来源于stack exchange，提问作者AlanSTACK