PHP异常处理必须用set_exception_handler()全局兜底并设500状态码，按类型分层catch、禁用静默吞异常，业务异常需自定义子类并带HTTP码和详情，finally内操作须try包裹防覆盖原异常。
PHP 异常未被 catch 时默认行为必须接管
PHP 在未捕获异常时会终止脚本并输出错误（E_FATAL 级别），但生产环境不能依赖这个默认行为——它不记录上下文、不触发监控、不兼容 API 返回格式。必须用 set_exception_handler() 全局兜底。
常见错误是只在 try/catch 里处理，漏掉顶层异常；或在 handler 里直接 die()，导致 HTTP 状态码仍是 200。
- handler 中第一件事是设置正确状态码：
http_response_code(500) - 避免在 handler 中抛出新异常，否则进程直接退出，日志都来不及写
- 记录要包含
$exception->getTraceAsString()和$_SERVER['REQUEST_URI']，否则无法复现请求链路
try/catch 不该包裹整个控制器方法
把整个 indexAction() 或 handle() 套进一个大 try/catch，看似“安全”，实则掩盖了异常类型差异，让业务逻辑和系统级错误混为一谈。
比如数据库连接失败（PDOException）和用户输入校验失败（自定义 ValidationException）应走不同恢复路径：前者需降级/告警，后者只需返回 400。
立即学习“PHP免费学习笔记（深入）”；
- 按异常类名分层 catch：
catch (ValidationException $e)优先于catch (Exception $e) - 不要用
catch (Throwable $e)替代Exception，除非你明确要捕获ParseError这类致命错误（通常不该恢复） - catch 后不要静默吞掉异常，至少调用
error_log()或写入结构化日志（如 Monolog 的Logger::error()）
自定义异常类必须继承 Exception 且带业务标识
直接 throw new Exception('xxx') 是反模式：无法区分、无法过滤、无法绑定监控规则。所有业务异常必须是具体子类，命名体现领域语义，如 InsufficientBalanceException、OrderAlreadyPaidException。
这类异常不是错误，而是业务流程的合法分支。它们不该触发告警，但需被 API 层识别并转成对应 HTTP 状态码（如 402、409）。
- 构造函数中固定传入
$code（HTTP 状态码）和$details（数组，含 trace_id、user_id 等） - 避免在异常消息里拼接用户数据（防信息泄露），敏感字段走
$details - 框架如 Laravel 的
render()方法可统一拦截这些子类，避免每个 controller 重复判断
finally 里做资源清理，但别 throw 新异常
finally 块适合关文件句柄、释放锁、关闭 PDOStatement，但它执行时若再抛异常，会覆盖原始异常，导致根因丢失。
典型陷阱是：DB 查询失败后，在 finally 里调用 $pdo->rollBack()，而此时连接已断，又抛出 PDOException —— 原始的 SQL 错误就被吞了。
- 所有
finally内部操作必须用 try/catch 包裹，并仅记录错误，不 throw - 数据库事务建议用显式
try { commit(); } catch { rollback(); throw; }，而非依赖 finally - 文件操作可用
register_shutdown_function()补充清理，但仅限极端场景（如 fork 子进程后主进程异常）
set_exception_handler() 就能解决的。 
