set_error_handler仅捕获E_WARNING、E_NOTICE、E_USER_ERROR等非致命错误，不捕获E_ERROR、E_PARSE等致命错误；需严格4参数回调、显式掩码控制、全局唯一且须早于框架注册。
set_error_handler 能捕获哪些错误
set_error_handler 只捕获 PHP 运行时触发的 E_WARNING、E_NOTICE、E_USER_ERROR 等（除 E_ERROR、E_PARSE、E_CORE_ERROR 等致命错误外）——这些错误本不会中断脚本，但默认会直接输出到页面或日志。你不能用它拦截语法错误或内存耗尽导致的崩溃。
常见误判场景：
- include 'missing.php' 触发 E_WARNING → 可捕获
- call_user_func('nonexistent') 触发 E_WARNING → 可捕获
- undefined_variable 触发 E_NOTICE → 可捕获
- new NonExistClass() 触发 E_ERROR → 不可捕获，回调函数根本不会执行
回调函数签名必须严格匹配
PHP 对回调函数的参数个数和类型有硬性要求。少一个参数、多一个参数、类型不兼容，都会导致 set_error_handler 失效且不报错——错误照常输出，你的回调却静默跳过。
正确写法（4 参数完整）：
function my_error_handler($errno, $errstr, $errfile, $errline) {
// 必须接收这 4 个参数
error_log("[$errno] $errstr in $errfile:$errline");
return true; // 阻止默认处理
}
容易踩的坑：
- 忘记第 4 个 $errline，尤其在 IDE 自动生成时被省略
- 使用 ...$args 或声明为 function ($errno, ...$rest) → 不被识别为合法处理器
- 返回 false 或不返回值 → 默认错误处理继续执行，看起来像“没生效”
错误级别掩码要主动控制
不传第二个参数时，set_error_handler 默认只接管 E_WARNING | E_NOTICE | E_USER_WARNING | E_USER_NOTICE | E_USER_ERROR。如果你希望也捕获 E_DEPRECATED 或 E_USER_DEPRECATED，必须显式传入掩码。
实操建议：
- 生产环境通常要加 E_DEPRECATED 和 E_USER_DEPRECATED，避免旧代码埋雷
- 测试阶段可设为 E_ALL，但注意：它包含 E_ERROR 等不可捕获项，实际生效的仍是子集
- 掩码组合示例：set_error_handler('my_error_handler', E_ALL & ~E_STRICT)
全局作用域 + 优先级冲突很隐蔽
set_error_handler 是全局设置，一旦调用就覆盖之前注册的处理器。框架（如 Laravel、Symfony）或 Composer 加载的库可能已注册自己的处理器，你的调用若在它们之后，就会把原有逻辑干掉——结果是日志丢失、监控失效，而你完全没意识到。
立即学习“PHP免费学习笔记（深入）”；
排查要点：
- 在入口文件最顶部（index.php 开头）就调用，早于任何 autoload 或框架初始化
- 检查是否重复调用：两次 set_error_handler 会导致前一个彻底失效
- 若需共存，得手动保存原处理器并转发：$old = set_error_handler(...);，然后在新函数里判断是否需要委托给 $old
真正难调试的是：错误没进你预期的日志，也不报错，只是“消失”了——大概率是别的代码悄悄替换了 handler，或者你忘了 return true。
