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 时照样执行除法。
正确做法是单独判断值是否为零或空值：
立即学习“PHP免费学习笔记（深入）”；
- 安全除法推荐写成：
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" == 0为true），===才严格（"0" === 0为false）。除零判断必须用===或明确类型转换
类型模糊、判断链过长、把 isset() 当万能开关——这三点加在一起，就是线上除零 bug 最常藏身的地方。
