PHP异常处理，表面上看就是try、catch、finally三件套，但真正落到Zend引擎底层，每一步都是硬核的C语言控制流切换。先把结论摆在这儿：异常对象不是普通PHP对象，是由Zend引擎创建的一个zend_exception结构体，带着message、code等字段，一创建就标记栈中断；throw触发的是引擎级控制流切换，catch靠编译期生成的映射表匹配，而且只认当前函数帧；finally则通过编译阶段在所有退出路径末尾插入opcode，实现“无条件执行”。
PHP异常对象在Zend引擎里怎么被创建
当你写下throw new Exception()这行代码时，PHP并不像平时那样简单地在堆上分配一个PHP对象。Zend引擎会在底层直接分配一个C语言结构体zend_exception。这个结构体不是PHP层的Exception实例，而是实实在在的C结构，里面装着message、code、file、line、trace这些字段，还握着一个指向原始调用栈（zend_backtrace）的指针。
最核心的一点是：这个结构体一创建出来，当前执行栈立刻被标记为“中断”。后面的字节码不会再执行了——不是靠PHP代码做跳转，而是引擎级控制流直接切换。这就像游戏里按下了暂停键，后续所有动作都失效。
zend_exception才是真正参与异常传播的实体，PHP层的Exception对象只是它的用户态封装，相当于一个袋里。- 如果没被
catch捕获，这个结构体会一路向上回溯调用栈，每层都检查有没有匹配的catch指令（对应opcodeZEND_CATCH）。 - 整个过程不依赖任何PHP用户代码的条件判断，是Zend VM在解释执行时硬编码好的控制流切换逻辑。
为什么 catch 块必须紧挨 try，不能跨函数边界自动捕获
很多新手会疑惑：为什么子函数里抛了异常，父函数不写try就抓不到？答案在于PHP的try/catch根本不是“作用域查找”，而是编译期生成的指令映射表。每个try块在编译后会记录自己的起始和结束opcode位置，以及对应的catch跳转地址——但这个映射表只对当前函数有效。
换句话说，异常从子函数抛出后，引擎只会检查当前函数帧里有没有能匹配的catch，不会自动“穿透”到上层函数去扫描它们的try块。除非上层显式写了try，并且这个函数调用恰好被包裹在try块里。
- 子函数里
throw，父函数没写try→ 异常直接上抛，别指望隐式捕获。 - 父函数写了
try，但catch类型不匹配（比如抛PDOException却只catch (Exception)）→ 仍然上抛，不会降级匹配。 - 多个
catch块按源码顺序线性匹配，引擎不做类型继承关系推导，只做指针比对——判断是否属于同一类或其子类。
finally 是怎么做到“无论是否异常都执行”的
finally的魔力不在运行时，而在编译阶段。编译器不会等到执行时再去判断“有没有异常”，而是直接把finally块的opcode插入到所有可能退出路径的末尾：包括正常return、throw、exit()，甚至goto跳转——只要退出当前函数，就得先执行finally块。
这导致一个容易踩坑的行为：如果finally里有return或再次throw，它会覆盖前面try或catch中的返回值或异常。也就是说，finally里的return是“最终决定权”。
finally在Zend VM中对应独立的opcode序列，与try/catch解耦。- 即使
catch块里throw了新异常，finally仍然会先执行完，再抛新异常。 - PHP 5.5+才支持
finally，旧版本只能靠手动register_shutdown_function()模拟，但无法拦截exit()。
未捕获异常最终落到哪里
当异常一路向上找不到任何catch，Zend引擎会终止当前请求，并把控制权交给全局异常处理器。默认行为是输出堆栈并终止脚本，但你可以用set_exception_handler()替换它。
注意：set_exception_handler()只接管未被捕获的Exception和Error（PHP 7+），但不接管传统PHP错误（比如E_WARNING），那些还得靠set_error_handler()。
- 全局处理器函数接收的是原始
Throwable对象，不是字符串。 - 如果全局处理器本身也抛异常，PHP直接fatal error，不再尝试二次处理。
- CLI模式下未捕获异常会打印到stderr；Web模式下取决于
display_errors和SAPI层处理逻辑。
真正难调试的，往往不是throw那行，而是异常在调用栈中“静默穿越”多层函数时，哪一层意外吞掉了它，或者finally里悄悄改写了返回结果。这一点，值得反复留意。
