set_error_handler仅捕获e_warning、e_notice、e_user_error等可恢复的非致命错误，不处理e_error、e_parse、e_fatal_error等致命错误及异常，后者需用set_exception_handler或register_shutdown_function+error_get_last()兜底。
set_error_handler 能捕获哪些错误
set_error_handler 只能捕获 PHP 运行时的 非致命错误，比如 E_WARNING、E_NOTICE、E_USER_ERROR 等，但不会触发 E_ERROR（如语法错误、未定义函数调用）、E_PARSE 或 E_FATAL_ERROR —— 这些会直接中止脚本，必须靠 register_shutdown_function + error_get_last() 补漏。
常见误判：在 try/catch 里 expect 它捕获 new Exception()，其实不行 —— 异常得用 set_exception_handler 处理。
- 它接收的错误级别是位掩码，推荐用
E_ALL & ~E_DEPRECATED & ~E_STRICT（PHP8 默认已禁用E_STRICT，但显式排除更稳妥） - PHP8 中
E_DEPRECATED和E_USER_DEPRECATED仍可被捕获，但默认不显示；若要记录弃用提示，需主动包含 - 回调函数签名必须是：
function($errno, $errstr, $errfile, $errline, $errcontext)，第 5 个参数$errcontext是可选的，但开启后会传入当前作用域变量快照（慎用，可能含敏感数据或大对象）
日志内容该写什么才真正有用
只记 $errstr 和文件行号远远不够。生产环境定位问题，至少要补全：$_SERVER['REQUEST_URI']、$_SERVER['HTTP_USER_AGENT']、请求方法、当前执行脚本路径、PHP 版本、以及是否为 AJAX 请求（$_SERVER['HTTP_X_REQUESTED_WITH'] === 'XMLHttpRequest'）。
特别注意：$errcontext 在 PHP8 中默认为 null，除非你在 set_error_handler 第二个参数显式传入 E_ALL 并确保 track_errors ini 配置为 On（但该配置自 PHP7.4 起已废弃，实际无效）—— 所以别依赖它自动带变量，真要调试上下文，改用 debug_backtrace(DEBUG_BACKTRACE_IGNORE_ARGS) 更可靠。
- 避免直接
file_put_contents(..., FILE_APPEND)：高并发下可能丢日志或损坏文件；改用error_log($message, 3, $log_file)，它内部做了 flock - 日志格式建议用 JSON 行格式（每行一个 JSON 对象），方便后续用 logstash 或 grep 解析；字段名统一小写加下划线，如
error_level、request_uri - 敏感字段如
$_POST、$_COOKIE绝对不能原样写入，必须脱敏（例如用array_map(fn($v) => is_string($v) ? '***' : $v, $_POST)）
PHP8 的类型声明和错误处理怎么共存
PHP8 的严格类型（declare(strict_types=1)）不会产生传统 E_RECOVERABLE_ERROR，而是直接抛出 TypeError 异常 —— 所以你注册的 set_error_handler 根本收不到这类问题。它们归 set_exception_handler 管。
这意味着：如果代码里混合了弱类型调用（如传 string 给 int 参数）和强类型声明，你必须同时配齐两套处理器，否则会漏掉一半错误。
- 在
set_exception_handler回调里，检查$exception instanceof TypeError或$exception instanceof ValueError（PHP8.0+ 新增），再按同样逻辑写日志 - 不要在错误处理器里 throw 新异常（尤其不要 throw 同类异常），PHP8 会报
Fatal error: Uncaught TypeError并终止脚本 - PHP8.1+ 的
enum类型错误、PHP8.2 的readonly属性赋值错误，也都走异常通道，不是错误处理器的管辖范围
为什么日志看起来“没写进去”或重复写两次
最常见原因是：框架（如 Laravel、Symfony）或 Composer 自动加载器（如 vendor/autoload.php）已经调用了 set_error_handler，你的自定义函数被覆盖了。PHP 只允许一个活跃的错误处理器。
- 用
var_dump(set_error_handler('var_dump'));测试 —— 如果返回NULL，说明已被占用；返回旧回调函数则表示替换成功 - 正确做法：在框架启动前尽早注册（如入口文件
index.php最顶部），或通过框架提供的钩子（Laravel 的App::error()已废弃，改用report()方法） - 重复写日志？检查是否同时启用了
error_log的syslog模式（error_log($msg, 0)）又写了文件，或者display_errors = On导致错误既输出到页面又被 handler 捕获一次 - 日志权限问题：PHP 进程用户（如
www-data）必须对日志目录有w权限；用ls -ld /path/to/log/确认，别只看文件权限
PHP8 的错误处理本身不复杂，难的是把错误、异常、致命错误、静态分析警告（如 Psalm）这几条线都串起来，且不互相干扰。最容易被忽略的，是 register_shutdown_function 那一环 —— 它才是真正兜底的最后防线。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
