为何mysqli_query()返回null？如何排查该异常问题？

我碰到过类似的诡异场景，结合你提到的源码里zend_parse_method_parameters失败会直接返回null的细节，给你几个切实可行的排查方向：

• 先锁定参数传递的合法性
  既然参数解析失败是返回null的明确原因，先确认生产环境中调用mysqli_query()时的参数是否符合要求：

  • 第一个参数：虽然你说链接对象存在，但可以用gettype($link)或者$link instanceof mysqli确认它确实是有效的mysqli实例，有没有被意外覆盖、或者在调用前被部分销毁（比如某些框架的资源回收机制）；
  • 第二个参数：SQL语句是不是空字符串、非字符串类型（比如不小心传了数组、null），或者包含了某些特殊字符导致参数解析异常？
  • 第三个可选的结果模式参数：如果有传，是不是MYSQLI_STORE_RESULT/MYSQLI_USE_RESULT这类合法常量，有没有传错数值？

• 在生产环境添加临时调试日志
  既然本地复现不了，只能在问题发生的环境里加日志留痕，建议记录这些关键信息：

  // 调用前记录参数和链接状态
  error_log("mysqli_query call: link type=" . gettype($link) . ", is mysqli=" . ($link instanceof mysqli) . ", sql=" . $sql . ", mode=" . (isset($mode) ? $mode : 'undefined'));
  error_log("mysqli pre-call status: ping=" . $link->ping() . ", error=" . $link->error . ", errno=" . $link->errno);
  
  // 执行并记录结果
  $result = mysqli_query($link, $sql, isset($mode) ? $mode : null);
  error_log("mysqli_query result: type=" . gettype($result) . ", value=" . var_export($result, true));
  

  当问题再次出现时，通过日志就能看到当时的参数是否异常，链接是否真的可用。

• 模拟参数解析失败的场景，验证返回逻辑
  你可以在本地故意构造参数错误的调用，确认是否会返回null，比如：

  • 传入非mysqli对象作为第一个参数：mysqli_query('invalid-link', 'SELECT 1');
  • 传入过多的参数：mysqli_query($link, 'SELECT 1', MYSQLI_STORE_RESULT, 'extra-arg');
  • 传入非法的结果模式值：mysqli_query($link, 'SELECT 1', 999);
    这些场景如果返回null，就坐实了参数解析失败是问题根源，接下来就盯着生产环境的参数传递就行。

• 检查PHP版本的已知bug
  既然PHP5和7都存在这个问题，可以查一下对应版本的mysqli扩展bug记录，看看有没有边缘场景下参数解析失败的案例，比如特定编码的SQL字符串、链接对象在特殊状态下的解析异常等。

• 换用面向对象调用方式测试
  尝试把 procedural 风格的调用换成OOP方式：$result = $link->query($sql);，有时候两种调用的参数解析逻辑有细微差别，能帮你快速定位是不是调用方式导致的问题。

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