trigger_error 会触发什么级别的错误
trigger_error 默认抛出的是 E_USER_NOTICE 级别错误，它不会中断脚本执行，也不影响返回值——这点和 throw new Exception() 完全不同。如果你需要中断流程，得手动配合 die() 或 exit()，或者改用更高严重级。
常见错误现象：写了 trigger_error("参数为空")，但程序继续往下跑，日志里也看不到，因为默认级别被错误处理器忽略或静默丢弃了。
-
E_USER_WARNING：会显示警告（不中断），适合提醒开发者注意潜在问题 -
E_USER_ERROR：中止脚本执行，等价于内置的致命错误，适合不可恢复的业务校验失败 - 别用
E_ERROR这类内置级别——trigger_error不接受它们，会直接报错Warning: Invalid error type specified
如何让 trigger_error 写入日志而不是屏幕输出
PHP 默认把 E_USER_* 错误输出到页面（开发环境）或 Apache/Nginx 错误日志（生产环境），但行为取决于 error_reporting 和 display_errors 配置。想稳定写入文件，不能只靠 trigger_error，得配好错误处理器。
使用场景：API 接口里抛错，你不想让用户看到堆栈，但又要留痕排查。
立即学习“PHP免费学习笔记（深入）”；
- 确保
log_errors = On且error_log = /var/log/php-error.log在php.ini中生效 - 如果用了自定义错误处理器（
set_error_handler），必须显式处理E_USER_*类型，否则会被忽略 -
trigger_error("库存不足", E_USER_WARNING)只有在error_reporting包含E_USER_WARNING时才会被记录
trigger_error 和 throw Exception 的关键区别
它们根本不是替代关系：trigger_error 是错误（error），面向 PHP 的错误系统；throw 是异常（exception），面向 try/catch 流程控制。混用会导致逻辑断裂。
容易踩的坑：在 Laravel 或 Symfony 项目里用 trigger_error 做业务校验，结果中间件捕获不到，日志分散，调试时找不到源头。
-
trigger_error无法被try/catch捕获，除非你用set_error_handler把它转成异常 -
throw new RuntimeException("xxx")能被框架统一处理、带上下文、支持响应格式化；trigger_error只能打字符串+级别 - 性能上差异不大，但可维护性差很多——没人会 grep
trigger_error来找业务失败点
实际该在哪儿用 trigger_error
它只适合极少数场景：给扩展开发者留钩子、兼容老代码的错误提示、或在没有异常机制的函数式代码段里做轻量提醒。
比如写一个纯工具函数库，不依赖任何框架，又想让调用方知道传了非法参数，但又不想强制要求对方写 try/catch。
- 示例：
function safe_json_decode($json) { if (!is_string($json)) { trigger_error("safe_json_decode expects string, " . gettype($json) . " given", E_USER_WARNING); return null; } ... } - 不要在控制器、服务类、数据库操作里用它——这些地方都有明确的错误传播路径，该 throw 就 throw
- 如果真要用，务必加级别参数，别省略；否则默认
E_USER_NOTICE在多数生产配置下等于“没发生”
真正难的不是怎么调用 trigger_error，而是判断此刻该不该用它。绝大多数时候，答案是否定的。
