set_error_handler仅捕获E_WARNING、E_NOTICE、E_USER_ERROR等运行时警告级错误，不处理Fatal error、Parse error及PHP启动错误；需手动调用http_response_code()设置状态码，CLI下须禁用display_errors才能生效。
set_error_handler 能捕获哪些错误
set_error_handler 只接管 PHP 的「运行时警告级错误」，比如 E_WARNING、E_NOTICE、E_USER_ERROR 这类。它不处理 Fatal error（如语法错误、未定义函数、内存耗尽），也不管 Parse error 或 PHP Startup errors——这些在脚本还没真正跑起来时就挂了，根本轮不到它。
常见误判场景：
- 写错函数名导致
Fatal error: Uncaught Error: Call to undefined function xxx()→set_error_handler完全收不到 -
require 'missing.php'报Warning: require(): Failed opening required→ 这个能被捕获 - 在
__construct里抛出throw new Exception()→ 属于异常，不是错误，得用set_exception_handler
怎么让 404/500 页面真正返回对应 HTTP 状态码
很多人以为只要 set_error_handler 里 include 'error_500.php' 就完事了，结果浏览器看到的是 200 OK —— 因为 PHP 默认状态码就是 200，错误处理器本身不会自动改状态。
必须手动发状态头：
立即学习“PHP免费学习笔记（深入）”；
- 对
E_USER_ERROR或严重运行时错误，用http_response_code(500) - 如果是路由层判定的 404（比如 Slim/Laravel 的 NotFoundHttpException），应在触发前就调
http_response_code(404) - 注意：Apache + mod_php 下，若配置了
ErrorDocument 404 /404.html，会绕过 PHP；Nginx 则需确认没配error_page 404直接跳转静态页
自定义错误页里 echo 输出被缓冲干扰怎么办
错误发生时，输出缓冲（output buffering）可能处于开启状态，导致你 echo 的错误页内容被卡住不显示，或者和之前缓存的内容混在一起。
稳妥做法是强制清空并关闭缓冲：
- 开头加
if (ob_get_level()) { ob_end_clean(); } - 确保错误页模板里没有
ob_start()或未匹配的ob_end_flush() - 避免在错误处理器里再调用可能触发新错误的函数（比如访问一个已销毁的对象属性），否则会二次崩溃
示例片段：
function myErrorHandler($severity, $message, $file, $line) {
if (ob_get_level()) { ob_end_clean(); }
http_response_code(500);
include __DIR__ . '/templates/error_500.php';
exit;
}
为什么 set_error_handler 在 CLI 模式下看起来“不生效”
CLI 模式默认把错误直接打到终端，且 display_errors = 1 时，即使设了 set_error_handler，系统仍会照常输出原始错误信息（比如 PHP Notice: Undefined variable: x in test.php on line 5），你的处理器只是「额外执行」了一次。
要让它真正接管，得关掉原生输出：
- 运行前加
ini_set('display_errors', '0'); - 或启动时用
php -d display_errors=0 script.php - 注意：CLI 下
http_response_code()无效，别白费劲设状态码
这个点容易被忽略——开发时在浏览器看没问题，一上命令行调度任务就漏掉错误页，只留一行裸错误文本。
