最致命错误是将 null 传给 foreach() 导致崩溃，根源在于跳过判空；常见于查询无结果、表单未提交、JSON 解码失败等场景，正确做法是 is_array() 显式校验或使用 ?array 类型声明并配合判空处理。
foreach() 遇到 null 直接崩溃：Invalid argument supplied for foreach()
这是最常被忽略却最致命的错误之一：把 null 当成数组传给 foreach()，PHP 会立刻抛出 Invalid argument supplied for foreach()（PHP 7.0+）或 foreach() argument must be of type array|object, null given（PHP 8.0+）。根本原因不是“没数据”，而是你跳过了判空这一步。
常见场景包括：
- 数据库查询用
first()或find()没命中，返回null，后续直接foreach($result as ...) - 表单复选框未勾选，
$_POST['tags']不存在 → 访问即为null→foreach($_POST['tags'] as ...)崩溃 - JSON 解码失败：
json_decode($str, true)在无效 JSON 时返回null，没检查就遍历
正确做法不是加 @ 抑制，而是显式校验：
if (is_array($data)) {
foreach ($data as $item) { ... }
} else {
$data = []; // 或 throw/log
}
更推荐类型声明层面防御：函数返回类型写成 ?array，强迫调用方意识到它可能为空。
立即学习“PHP免费学习笔记（深入）”；
访问 $obj->field 或 $arr['key'] 前不判空：Trying to access ... on null
这个错误在 PHP 7.4+ 中升级为 Fatal Error，比如 Trying to access array offset on value of type null 或 Call to a member function xyz() on null。它暴露的是一个更上游的问题：某个本该是对象/数组的变量，实际是 null。
典型来源：
- Eloquent 查询无结果：
$user = User::find(99999)返回null，但代码接着写$user->name或$user['name'] - API 返回结构不稳定，
$resp['data']['items']的某一层是null，却直接取$resp['data']['items'][0] - 配置项缺失，
$config['cache']['ttl']中$config或$config['cache']是null
安全写法分两步：先确认容器非 null，再确认键存在且可用：
if ($user !== null && isset($user->email)) {
sendEmail($user->email);
}
PHP 8.0+ 可用空安全操作符简化属性访问：$user?->email，但它只防止调用崩，不替代业务逻辑判断 —— 如果 $user 是 null，$user?->email 返回 null，后续若没处理仍可能出错。
bindParam() 绑定时变量为 null：SQL 插入字段意外变空
这不是语法错误，而是逻辑漏洞导致的数据污染。当 PDOStatement::bindParam() 绑定的变量值为 null，对应字段就会插入 SQL NULL —— 即使你本意是留空字符串或默认值。
常见诱因：
- 表单字段名与
$_POST键不一致（如 HTML 写name="user_name"，PHP 却读$_POST['username']→ 返回null） - 前端未传必填字段，后端没做默认值兜底，
$status = $_POST['status'] ?? 'pending'漏掉这句 - 变量名拼写错误：
$problem_Type和$problem_type不一致，绑定时传入未定义变量 →null
关键原则：绑定前必须确保变量已赋值，且值符合字段约束。不要依赖数据库的默认值来“救火”。
推荐写法：
$stmt = $pdo->prepare("INSERT INTO logs (staff_name, email) VALUES (?, ?)");
$staffName = $_POST['staff_name'] ?? '';
$email = filter_var($_POST['email'] ?? '', FILTER_SANITIZE_EMAIL);
$stmt->execute([$staffName, $email]);
联合类型中 null 的语义混淆：string|null ≠ ?string
PHP 8.0+ 支持 string|null 和 ?string 两种写法，它们等价，但混用容易引发理解偏差。真正麻烦的是开发者误以为写了 ?array 就万事大吉，却在函数体内直接 foreach($arr as ...) —— 类型声明只管输入输出，不管运行时行为。
例如：
function getItems(): ?array {
return rand(0,1) ? [['id'=>1]] : null;
}
$items = getItems();
foreach ($items as $i) { ... } // ❌ 运行时仍崩！
这里 ?array 只告诉调用方“我可能返回 null”，并不自动帮你判空。你依然要写 if (is_array($items)) { ... }。
更隐蔽的坑：
- 把
array|null当作array传给另一个要求array参数的函数，触发 TypeError - 用
?? []补默认值时，左侧是string|null类型，??会静默转成字符串，造成类型不匹配
复杂点在于：null 不是“没有值”，而是“有值，值就是 null”。所有对它的使用，都得回答一个问题：这个 null 是合法状态（比如“用户没填邮箱”），还是异常信号（比如“数据库连接失败导致查不到用户”）？前者靠 ?? 或 ?-> 安全降级，后者必须记录日志、抛异常或走 fallback 流程。
