php 的 try/catch 无法捕获传统 fatal Error（如未定义函数调用），仅能捕获 throwable 子类（如 error、exception）；需结合 set_error_handler（处理 e_warning 等）和外层 try/catch(throwable) 日志记录，禁用 display_errors 防信息泄露。
怎么让 try/catch 真正捕获到 PHP 的致命错误
PHP 的 try/catch 默认不捕获 Fatal error（比如调用未定义函数、内存耗尽、类未找到），这是新手最常误以为“已兜底”却线上崩掉的原因。
真正能拦截的，只有继承自 Throwable 的异常和错误（PHP 7+）。但像 ParseError、TypeError、ArgumentCountError 这些是 Error 类的子类，属于 Throwable，可以被 catch (Throwable $e) 捕获；而传统 Fatal error（如 Call to undefined function）仍会直接终止脚本。
- 用
set_error_handler()+error_reporting()配合，把部分E_ERROR级别错误转为异常（但不是全部，比如语法解析失败就做不到） - 关键入口（如 CLI 脚本、Web 请求主流程）外层加
try/catch (Throwable $e)，并记录$e->getMessage()和$e->getTraceAsString() - 不要依赖
register_shutdown_function()做“兜底日志”就以为稳了——它只能看到错误，不能阻止进程退出，也不能恢复执行
set_exception_handler() 和 set_error_handler() 怎么分工
二者定位不同：set_exception_handler() 处理未被捕获的 Exception 或 Throwable；set_error_handler() 处理 trigger_error() 或运行时警告/错误（E_WARNING、E_NOTICE 等），但对 E_ERROR 及以上默认无效（仅部分可接管）。
-
set_error_handler()必须返回true才能屏蔽原生错误输出，否则错误照打，handler 白注册 - 若同时用了
set_error_handler()并想把某些错误转成异常，建议只转E_WARNING、E_NOTICE、E_USER_*，别碰E_ERROR——强行 throw 可能导致二次崩溃 -
set_exception_handler()中不要再抛异常，否则进程直接 exit，连日志都可能写不完
日志里为什么总看到 Uncaught TypeError 却没进 catch
因为这个错误发生在 try 块之外，或者发生在 catch 块内部又没被再次包裹。常见于：异步回调（如 array_map() 里的闭包）、构造函数中抛出、或 finally 里发生新错误覆盖了原异常。
立即学习“PHP免费学习笔记（深入）”；
- 检查
catch是否写在了正确作用域——比如函数内try，但错误实际发生在函数调用后返回值被使用时 -
__construct()抛出异常不会被父类构造函数的try捕获，必须在 new 表达式外层包try - 避免在
catch或finally中调用可能失败的函数（如file_put_contents()写日志失败），否则原错误丢失，只剩新错误
生产环境要不要开 display_errors
不要。设为 Off 是底线，否则任何错误都会直接输出到响应体，可能泄露路径、数据库结构、甚至 Token。
-
display_errors = Off+log_errors = On+error_log = /var/log/php/error.log是基础组合 - CLI 模式下可临时设
display_errors = Stderr，方便调试，但上线前必须关掉 - 框架项目（如 laravel、symfony）通常自带错误处理器，此时更要确认其配置没被
php.ini的display_errors覆盖
错误处理最难的不是写 try/catch，而是搞清哪一层该由谁拦截、哪一层根本拦不住，以及日志里那条报错，到底是在哪个括号外面发生的。