PHP除数为零错误处理及isset与三元运算符详解

PHP浮点除零得INF/NAN不报错，整数除零抛DivisionByZeroError；防除零须显式判零而非isset()；推荐filter_input过滤+判零，或空合并操作符??配合类型转换。

PHP除数为零不会报错，但结果是INF或Warning

PHP默认不中断执行，1 / 0 得到 INF，0 / 0 是 NAN，而整数除法（如 intdiv(5, 0)）会直接抛出 DivisionByZeroError 异常。关键区别在于：浮点除法静默失效，整数除法强制报错。

常见错误现象：var_dump(10 / 0); 输出 float(INF)，后续用它做比较（如 === 0）或传给 intval() 会得到意外结果；线上计算订单均价、分页总数时突然变成 INF，前端显示“INF”或触发JS NaN 错误。

• 检查除数是否为零必须显式写，PHP不自动拦截浮点除法
• 用 intdiv() 替代 / 可提前暴露问题，但仅限整数场景
• 生产环境建议开启 error_reporting(E_ALL & ~E_WARNING) 并捕获 E_WARNING，因为除零警告属于 warning 级别，不会被 try/catch 捕获

isset() 不是用来判断“不为零”的

isset() 只检测变量是否已声明且不为 null，对 0、false、'' 都返回 true。很多人误用它来防除零，比如 if (isset($divisor)) { $result = $a / $divisor; } —— 这完全没用，$divisor = 0 时照样执行除法。

正确做法是单独判断值是否为零或空值：

• 安全除法推荐写成：if ($divisor != 0) { $result = $a / $divisor; }
• 若需兼容字符串数字（如表单提交的 "0"），用 !empty($divisor) 不可靠（empty("0") 为 true），应转为数字再判：if ((float)$divisor !== 0.0)
• isset($divisor) && $divisor 也不行——$divisor = 0 时整个表达式为 false，看似“防住了”，但掩盖了本应允许的 0.0 或 "0.0" 场景

三元运算符里嵌套 isset() 容易逻辑翻车

像 $val = isset($arr['key']) ? $arr['key'] : 0; 看似稳妥，但如果 $arr['key'] 是 0、false 或 ''，这个三元表达式仍会走 else 分支，导致本该用的 0 被替换成默认值。

真正需要的是“键存在且非 null”，而不是“键存在且为真值”：

• 严格判断存在性 + 非空值，用 array_key_exists('key', $arr) && $arr['key'] !== ''（按需调整 !== 的右边）
• PHP 7+ 推荐用空合并操作符：$val = $arr['key'] ?? 0; —— 它只在键不存在或为 null 时生效，0、false 都原样保留
• 如果变量可能未定义又想避免 notice，先用 ?? 再参与运算，比如：$result = ($divisor ?? 0) == 0 ? 0 : $a / $divisor;

除零和空值检查混在一起时，顺序和类型最易出错

真实接口里经常要处理用户传来的 $_GET['limit']、$_POST['page']，它们可能是字符串 "0"、空字符串、甚至根本没传。这时候一行判断很难兼顾所有边界。

最稳妥的组合是：先确保变量存在且是数字类型，再判零：

• 用 filter_input(INPUT_GET, 'limit', FILTER_VALIDATE_INT) 直接过滤并转整型，失败返回 false，比手动 (int) 更安全
• 若必须用三元，拆成两步：$limit = filter_input(INPUT_GET, 'limit', FILTER_VALIDATE_INT) ?: 10;，再 if ($limit <= 0) { $limit = 10; }
• 记住：== 会类型转换（"0" == 0 为 true），=== 才严格（"0" === 0 为 false）。除零判断必须用 === 或明确类型转换

类型模糊、判断链过长、把 isset() 当万能开关——这三点加在一起，就是线上除零 bug 最常藏身的地方。