PHP 8.0 中 throw 是表达式，但 catch 不穿透嵌套层级，仅捕获语法上直接包裹该 throw 的 try 块中的异常；array_map 等回调内 throw 不被外层 try 捕获，finally 也不保证在所有 throw 场景执行。
throw 在表达式里能用，但 catch 不会自动“穿透”嵌套层级
PHP 8.0 把 throw 变成了表达式，意味着它能出现在三元运算、数组值、函数参数甚至闭包返回位置。但很多人误以为「只要 throw 出来，上层 try 就一定能捕获」——这不成立。异常捕获只看调用栈中最近的、**语法上包裹该 throw 所在表达式的 try 块**，而不是逻辑上“看起来该归谁管”。
常见错误现象：array_map(fn($x) => $x > 0 ? $x : throw new InvalidArgumentException('negative'))，结果没被外层 try 捕获，而是直接 fatal error；原因在于 array_map 内部不提供 try 上下文，throw 发生在回调内部，调用栈已脱离你写的 try 范围。
- 只有显式写在
try块内的表达式里的throw，才会被该try的catch捕获 - 闭包、回调、array_filter/array_map 的回调函数，即使由你定义，也不自动继承外层 try 的作用域
- 函数内联调用（如
foo(bar() ?: throw new Exception())）中，throw属于foo()的参数表达式，捕获权取决于foo()是否在 try 内，而非 bar() 是否在 try 内
catch 无法匹配 throw 表达式产生的 Throwable 子类以外的类型
PHP 8.0 要求所有被抛出的对象必须是 Throwable 实例。但 throw 作为表达式时，容易和类型推导、泛型（伪）混淆，导致静态分析或运行时类型不匹配。
典型问题：写 $result = $x ?? throw new LogicException('missing')，然后在外层 catch (InvalidArgumentException $e) —— 永远不进这个块，因为抛出的是 LogicException，不是 InvalidArgumentException。
立即学习“PHP免费学习笔记（深入）”；
-
catch匹配严格按类继承链，不看 message 或 code - 别指望「写个通用
catch (Exception $e)就能兜住所有 throw 表达式」——如果 throw 的是Error（比如throw new TypeError()），它不会被Exception捕获，必须用catch (Throwable $e) - 自定义异常类必须继承
Exception或Error，否则throw new MyBadClass()直接报Fatal error: Uncaught TypeError
finally 不会在 throw 表达式求值中途执行
finally 的触发时机只和 try 块的完整执行有关，而 throw 表达式可能发生在任意子表达式中，此时 finally 还没轮到它执行。
例如：try { $a = some_func() ?: throw new RuntimeException(); } finally { echo "cleanup"; } —— 如果 some_func() 返回 falsey 值，throw 立即中断，finally 仍会执行；但如果是 try { $a = [throw new RuntimeException(), 'other'] }，这个数组构造本身就会失败，finally 不会触发，因为 try 块连入口都没完整进入。
-
finally保证的是「try 块开始执行后、无论是否抛出异常，都会执行」，不是「任何 throw 都会触发 nearby finally」 - 嵌套 try 中，每个
finally只对自己所属的try负责，不能跨层“感知”内层 throw 表达式 - 资源清理逻辑别依赖 throw 表达式 + finally 的组合，优先用
try ... finally显式包裹关键路径
类型推导工具（如 PHPStan、Psalm）对 throw 表达式支持有限
虽然运行时没问题，但静态分析器常把 throw 表达式当作“可能返回 void”，进而误判后续代码不可达，或对变量类型推导失效。
比如：$id = $input['id'] ?? throw new InvalidArgumentException('id required');，PHPStan 可能仍认为 $id 是 mixed，而非 int|string，因为它没把 throw 当作控制流终结点来建模。
- 这类问题不影响执行，但会导致 IDE 提示不准、CI 报告冗余错误
- 临时缓解：在 throw 后加注释
// @phpstan-ignore-next-line，或改用传统 if + throw - 更稳妥的做法：把复杂表达式拆成语句，例如先判断再赋值，避免把 throw 塞进深层嵌套表达式
最易被忽略的一点：throw 表达式让代码“看起来很短”，但异常边界反而更难追踪——尤其当它藏在高阶函数、箭头函数或 null 合并操作里时，调用栈深度和实际捕获点可能隔了三四层函数调用。写之前，先想清楚这个 throw 最终该由谁负责处理，而不是让它自由“上浮”。
