PHP没有空指针错误，“连接报空指针”实为mysqli_connect()或PDO构造失败返回null后未校验就直接调用方法，导致Fatal error；根本原因是未检查连接结果有效性，而非连接本身出错。
PHP 里没有空指针错误，所谓“连接报空指针”其实是 mysqli_connect() 或 PDO::__construct() 失败后返回 null，你却直接当对象用了——比如调用 ->query() 或访问 ->error。
mysqli_connect() 返回 null 时继续调用方法
这是最常被误读为“空指针”的场景：连接失败（如密码错、端口关、DNS 不通），mysqli_connect() 返回 null，但代码没检查就直接写 $conn->query("SELECT ...")，触发 Fatal error: Uncaught Error: Call to a member function query() on null。
- 根本原因不是“连接出错”，而是“没校验返回值就当对象用”
-
mysqli_connect()在失败时不抛异常，只返回null（除非开启mysqli.report） - 别用
@$conn = mysqli_connect(...)抑制警告——它掩盖了连接失败本身，让后续null调用更难定位 - 正确做法是显式判断：
if (!$conn) { die('Connect failed: ' . mysqli_connect_error()); }
PDO 构造失败后未捕获异常
PDO 默认模式下，构造失败会抛 PDOException，但很多人没包 try/catch，或关了 PDO::ATTR_ERRMODE，导致构造返回 null 或静默失败，后续 $pdo->prepare() 就崩了。
- 默认行为：
new PDO($dsn, $u, $p)失败 → 抛PDOException（可被捕获） - 危险配置：
$pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_SILENT)→ 失败不报错，后续所有操作返回false或null，极易漏判 - 推荐初始化写法：
try { $pdo = new PDO($dsn, $user, $pass, [ PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION, PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_ASSOC ]); } catch (PDOException $e) { error_log('DB connect failed: ' . $e->getMessage()); throw new RuntimeException('Service unavailable'); }
连接变量作用域丢失或被覆盖
看似连上了，实际执行 SQL 时提示 Call to a member function ... on null，往往是因为连接变量在函数/作用域中不可见，或被意外重置。
立即学习“PHP免费学习笔记（深入）”；
- 常见于封装函数中忘了
return $conn，或用了全局变量但没声明global $conn - 在类中：构造函数里赋了
$this->conn，但方法里写成$conn->query()（少了个$this->） - 多环境配置遗漏：测试环境连得上，生产环境因配置未加载导致
$conn仍是未定义或null - 检查手段：在调用前加
var_dump($conn); exit;，确认它确实是mysqli或PDO实例，而不是null、false或字符串
长连接复用时连接已断开但未检测
用 PDO::ATTR_PERSISTENT => true 或 mysqli_options(MYSQLI_OPT_CONNECT_TIMEOUT) 后，连接可能在空闲期被 MySQL 服务端断开（wait_timeout），下次再用时 $pdo->query() 会失败，但错误信息未必明确指向“连接已失效”。
- 现象：偶发性报错，且不是每次请求都发生；错误可能是
SQLSTATE[HY000] [2006] MySQL server has gone away，但也可能表现为对null的调用（尤其在封装层做了错误转换） - 解决思路不是“防空指针”，而是“保活或重连”：在执行前加简单探测，例如
$pdo->getAttribute(PDO::ATTR_SERVER_VERSION)或执行SELECT 1 - 更稳妥的做法是捕获
PDOException并判断错误码：if ($e->getCode() === 'HY000' && strpos($e->getMessage(), 'gone away') !== false)，然后重建连接
真正麻烦的从来不是那句 on null 的报错，而是没人去翻日志看第一行——为什么 mysqli_connect() 返回了 null？是配置写错了，还是防火墙拦了端口？防御性编码救不了上游逻辑漏洞。
