set_error_handler仅能捕获e_warning、e_notice、e_user_*等可恢复错误，无法处理e_error、e_parse等致命错误；必须返回true才生效；掩码需明确包含目标级别；全局注册应置于入口文件顶部。
set_error_handler 不能捕获所有错误类型
PHP 的 set_error_handler 只能接管 E_WARNING、E_NOTICE、E_USER_* 等「可恢复」错误，对 E_ERROR、E_PARSE、E_CORE_* 这类致命错误完全无效——它们发生时脚本直接终止，回调函数根本没机会执行。
- 常见错误现象：
Parse error: syntax error或Fatal error: Class 'XXX' not found永远不会进你写的 handler 函数 - 真正能拦截的典型场景：数组下标不存在（
E_NOTICE）、调用未定义函数（E_WARNING）、trigger_error('xxx', E_USER_WARNING) - 如果想兜底致命错误，得配合
register_shutdown_function+error_get_last()做事后检查，但此时 PHP 已经退出执行上下文，无法“继续运行”
自定义 handler 必须返回 true 才算接管成功
很多人写完 handler 发现错误还是照常输出到屏幕或日志，问题就出在函数末尾没 return true。PHP 默认行为是：handler 返回 false 或不返回值 → 让内置错误处理器继续处理（比如打印到 stderr）；返回 true → 表示“我全权负责，别插手”。
- 典型错误写法：
function myHandler($errno, $errstr) { error_log("[$errno] $errstr"); }→ 缺少return true，错误仍会原样抛出 - 正确写法：
function myHandler($errno, $errstr) { error_log("[$errno] $errstr"); return true; } - 注意：PHP 8.0+ 对参数类型更严格，建议显式声明类型，如
function myHandler(int $errno, string $errstr): bool，避免因类型不匹配导致返回值被忽略
错误级别掩码容易配错，导致 handler 不触发
set_error_handler 第二个参数是错误级别掩码，默认是 E_ALL，但实际项目中常需要过滤，比如只捕获用户触发的错误。一旦掩码写错，handler 就像没注册一样安静。
- 常见错误配置：
set_error_handler('myHandler', E_USER_WARNING | E_USER_NOTICE)→ 漏掉了E_USER_ERROR，而trigger_error('xxx', E_USER_ERROR)就不会进 handler - 推荐写法：
set_error_handler('myHandler', E_USER_WARNING | E_USER_NOTICE | E_USER_ERROR | E_WARNING | E_NOTICE)，明确列出要捕获的级别 - 兼容性提醒：PHP 8.0 移除了
E_STRICT，旧代码若依赖它需调整；另外E_DEPRECATED在开发环境常被开启，但生产环境一般关闭，要注意测试环境和线上行为差异
全局 handler 和局部作用域冲突时优先级混乱
PHP 允许多次调用 set_error_handler，后注册的会覆盖前一个——但仅限同一作用域。如果在函数内调用，handler 只在该函数执行期间生效；函数返回后，自动恢复上一级 handler（或默认行为）。这点很容易被忽略，导致调试时发现 handler “有时起作用，有时不起”。
立即学习“PHP免费学习笔记（深入）”；
- 错误使用场景：在某个类方法里调用
set_error_handler，以为整个对象生命周期都生效，其实只在该方法执行时有效 - 安全做法：把
set_error_handler放在入口文件（如index.php）最顶部，确保全局生效；如需临时切换，用restore_error_handler()显式还原 - 性能影响：频繁注册/还原 handler 本身开销不大，但 handler 内部逻辑（比如写文件、发 HTTP 请求）必须轻量，否则会影响所有错误路径的响应速度
事情说清了就结束。最常掉坑里的，是以为它能抓 fatal error，或者 handler 里忘了 return true，再就是掩码漏了关键级别——这三处一错，整个错误处理就形同虚设。
