e_user_error 默认会终止脚本，但若被 set_error_handler() 拦截且未手动 exit 或返回 false，则脚本继续执行；需确保 error_reporting 包含该级别，并用 trigger_error('msg', e_user_error) 正确触发。
PHP 中 E_USER_ERROR 不会自动终止脚本？先确认错误报告级别
默认情况下，E_USER_ERROR 确实会中止脚本执行，但前提是它没被 set_error_handler() 拦截后又没手动 exit 或 die。很多人以为抛了 E_USER_ERROR 就“肯定停”，结果发现后续代码还在跑——八成是自定义错误处理器吞掉了它，却忘了处理逻辑里的退出动作。
检查当前错误报告配置：error_reporting() 必须包含 E_USER_ERROR（比如设为 E_ALL 或显式加 | E_USER_ERROR），否则连错误都不会触发。
-
error_reporting(E_ALL | E_USER_ERROR)是安全起点 - 用
var_dump(error_reporting() & E_USER_ERROR)验证是否生效（返回非零即开启） - 若用了
set_error_handler()，必须在 handler 函数里对$errno === E_USER_ERROR的情况调用exit，否则脚本继续执行
用 trigger_error() 抛出 E_USER_ERROR 的正确姿势
trigger_error() 是唯一标准方式，别用 throw new Exception() 冒充——它们类型不同，set_error_handler() 接不到异常，而 try/catch 也捕不到 E_USER_ERROR。
常见错误是消息级别写错或参数缺失：
立即学习“PHP免费学习笔记（深入）”；
- 第二个参数必须是
E_USER_ERROR，写成'E_USER_ERROR'（字符串）或漏掉会变成默认E_USER_NOTICE - 消息字符串不能为
null或空，否则某些 PHP 版本会静默失败 - 示例：
trigger_error('数据库连接失败', E_USER_ERROR)—— 这样才会真正中断
调试时看不到 E_USER_ERROR 输出？检查输出通道和日志配置
即使触发成功，你也可能看不到任何提示：PHP 默认把错误输出到 SAPI（如 Apache 的 error log），而不是浏览器或 CLI 终端。本地开发时容易误以为没生效。
- CLI 模式下，确保
display_errors = On且error_reporting = E_ALL在php.ini或用ini_set()动态设置 - Web 环境下，
display_errors常被关掉，优先查error_log文件路径（用ini_get('error_log')看） - 若用 Xdebug，它可能拦截并美化错误；关掉 Xdebug 或检查其
xdebug.mode是否含develop，否则错误可能被重定向
和 Exception 混用时的兼容性陷阱
有人想“统一错误处理”，在 set_error_handler() 里把 E_USER_ERROR 转成 Exception 再 throw，这会导致两个问题：一是原有错误上下文（如触发位置的行号、文件）丢失；二是如果外层没 try/catch，最终还是转成致命错误，但堆栈已变形。
- PHP 8.0+ 对
trigger_error(..., E_USER_ERROR)的堆栈追踪更准确，但转成 Exception 后就退化为普通异常堆栈 - 框架（如 Laravel）通常只接管
Exception，不处理E_USER_ERROR，混用会让错误流分裂 - 真要统一，建议全程用
Exception，放弃E_USER_ERROR；若必须用，就别转，直接exit并记录日志
最常被忽略的是：自定义错误处理器一旦注册，所有错误（包括 E_USER_ERROR）都走它，而它的返回值决定是否继续执行——返回 false 才让 PHP 执行默认行为（中断），返回 true 或 void 就完全由你负责收尾。
