set_error_handler 默认抓不到 e_warning，因其属非中止型错误，仅当显式在第二个参数中包含 e_warning 时才触发回调；php 8.0+ 的 e_all 包含它，但旧版本需兼容性显式声明。
为什么 set_error_handler 默认抓不到 E_WARNING
因为 PHP 的错误处理机制里，E_WARNING 属于「非中止型错误」，默认不会触发你注册的 set_error_handler 回调——除非你显式告诉它要处理这个级别。PHP 默认只把 E_ERROR、E_USER_ERROR 等中止型错误交给自定义处理器，E_WARNING 被直接输出到 stderr 或日志，跳过你的回调。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 调用
set_error_handler时，第二个参数必须显式包含E_WARNING，例如：set_error_handler($handler, E_WARNING | E_USER_WARNING | E_NOTICE) - 不要依赖
E_ALL：在 PHP 8.0+ 中，E_ALL已包含E_WARNING，但老版本（如 7.2）的E_ALL不含它，兼容写法建议显式列出 - 注意运行时上下文：CLI 模式下
E_WARNING可能被静默吞掉，需确认display_errors = On或log_errors = On配置生效
捕获后怎么区分是文件操作警告还是函数参数警告
set_error_handler 回调收到的第四个参数 $context 是空数组，没法靠它判断来源；真正可用的是 $errno（错误号）和 $errfile（出错文件），再结合 $errstr（错误消息）做关键词匹配。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 用
stripos($errstr, 'fopen')或stripos($errstr, 'array_merge')快速识别常见警告源头 - 避免正则全量匹配：性能差且易误判，简单
stripos足够应对大多数场景 - 注意路径干扰：比如
$errfile是绝对路径，但警告消息里可能只写'No such file'，别指望靠路径字符串完全对齐 - 慎用
error_get_last()补漏：它只返回最近一次错误，多线程/协程环境不可靠，仅适合单次脚本兜底
捕获 E_WARNING 后还能继续执行吗
可以，而且这是 E_WARNING 的设计本意——它不中断流程。但要注意：某些内置函数（如 fopen、file_get_contents）在触发 E_WARNING 后仍会返回 false，你如果没检查返回值，后续逻辑可能因空值或类型错误崩出 E_NOTICE 或 E_ERROR。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 捕获只是第一步，关键还得配合返回值校验：比如
$fp = @fopen(...); if ($fp === false) { /* 处理失败 */ } - 不要滥用
@抑制符：它会拖慢执行，且和set_error_handler共存时行为难预测；优先用clearstatcache()+is_readable()等预检替代 - 记录日志时带上
$errline：行号比错误消息更稳定，方便定位真实出问题的那行代码，而不是警告冒泡上来的调用栈顶层
PHP 8.0+ 的 throwable 和 E_WARNING 冲突吗
不冲突。E_WARNING 是传统错误（Error 类型的父类 Throwable 并不继承它），不会被 try/catch 捕获，仍走 set_error_handler 流程。PHP 8 引入的 TypeError、ValueError 是异常，和 E_WARNING 属于两套机制。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 别试图用
catch (Error $e)拦E_WARNING：它根本不会抛出Error实例 - 混合项目里要小心：如果启用了
zend.exception_ignore_args=Off（PHP 8.2+），某些警告可能被转为WarningException，但这是 opt-in 行为，不是默认 - 线上环境建议关闭
report_zend_debug：避免调试信息泄露，同时减少无关警告干扰主错误流
真正麻烦的是警告和异常混发的边界情况——比如 json_decode($badJson, null, 512) 在超深嵌套时先报 E_WARNING，再抛 JsonException，这时候得靠时间戳或 debug_backtrace() 初步分离，不能只信错误类型。
