过多PHP警告会导致脚本未抛致命错误即中止吗？如何捕获排查

以下排查方向按出现概率从高到低排序：

• 优先排查系统级强杀场景，这类场景下PHP完全没有机会执行用户态代码，是shutdown函数不触发的最常见原因：
  • 查系统OOM Killer记录：执行dmesg -T | grep -i 'killed process'，或查看/var/log/syslog、/var/log/messages对应故障时间点的日志，确认PHP进程是不是被系统因为整机内存不足直接发送SIGKILL信号杀掉。你之前遇到的PHP层面内存超限能触发shutdown，是因为内存命中了PHP自身的memory_limit限制，走PHP内部错误流程；如果是进程总内存超过系统/容器阈值被内核强杀，不会走任何PHP内部逻辑。如果是Docker/K8s部署，容器内看不到这类记录，需要去宿主机查dmesg或编排层的事件日志，确认是不是容器被runtime因OOM终止。
  • 查超时强杀规则：如果是php-fpm模式，检查request_terminate_timeout配置，该参数超时后fpm会直接给进程发SIGKILL，不会触发shutdown；如果是CLI模式，检查supervisor、systemd、crontab相关配置，确认是不是守护进程在达到超时阈值后强杀了进程，同时排查有没有运维侧的负载保护脚本在故障时间点自动杀过高资源占用的进程。
  • 查进程段错误：C扩展层面的崩溃会触发段错误直接退出进程，同样走不到shutdown流程。可以打开系统coredump配置，故障发生后检查有没有生成对应进程的coredump文件，用gdb定位崩溃位置；重点排查环境中安装的非官方扩展、存在已知bug的扩展版本（比如特定版本的redis、opcache、xdebug都曾出现过随机段错误的问题）。
• 排查shutdown函数自身的逻辑缺陷：
  • 补全错误类型判定：你当前的逻辑只判定$last_error['type'] === E_ERROR，但PHP中能导致脚本终止的错误类型不止E_ERROR，运行时动态加载文件的E_PARSE、E_COMPILE_ERROR、E_CORE_ERROR，以及PHP7+版本中未捕获的Error（比如类型不匹配、调用不存在的方法）对应的错误类型都不是E_ERROR，这些场景下你的判定逻辑不会命中，自然不会写日志发告警。可以临时修改shutdown函数，在函数入口无条件写一条带时间戳的固定标识日志，先确认故障发生时shutdown函数到底有没有被执行，再调整错误判定规则覆盖所有致命错误类型。
  • 检查shutdown执行链的完整性：确认代码其他位置有没有注册过其他shutdown函数，且这些函数内部存在exit/die逻辑会中断后续shutdown函数执行；同时排查有没有在shutdown函数执行过程中触发新的致命错误，导致后续逻辑中断。
• 排查警告关联的异常场景：
  • 检查自定义错误处理器逻辑：如果代码中通过set_error_handler注册了自定义警告处理函数，排查该函数有没有递归调用、内存泄漏问题——比如处理警告的逻辑本身又触发新警告，嵌套层数过深打满调用栈导致进程崩溃，这类崩溃也不会触发shutdown。
  • 排查扩展层内存泄漏：如果警告触发的逻辑涉及C扩展操作，部分扩展会绕过PHP内存管理自行申请内存，这类内存增长不会被PHP的memory_limit检测到，直到内存占满被系统强杀，过程中不会触发PHP层面的内存错误。
• 排查IO类故障：
  检查故障时间点的磁盘使用率、inode使用率，查看dmesg中有没有块设备IO错误、网络存储断连记录，磁盘满、IO卡死、远程存储挂载失效都可能导致进程被系统终止，无法执行shutdown逻辑。
• 快速定位的实操方案：
  • 用strace跟踪进程运行：测试环境复现时执行strace -p <目标进程PID> -tt -T -o strace.log跟踪进程所有系统调用，进程退出后看日志末尾的记录，就能直接确认进程是收到信号退出、触发段错误还是卡在IO操作上，精准定位退出前的最后操作。
  • 做阶梯式埋点：不用全量梳理10万行代码，给核心逻辑段加序号标记，每执行完一段就打一条带当前内存占用、时间戳的日志，快速缩小故障发生的代码范围。
  • 临时调整PHP错误配置：把error_reporting设为E_ALL，打开log_errors、display_startup_errors，确认有没有被原有配置过滤掉的关键错误信息。

内容的提问来源于stack exchange，提问作者Bing