php中未定义变量直接转整型会触发e_notice错误，需先用isset()或空合并操作符??确保变量存在，再校验类型；is_int()仅判整型，filter_var($val, filter_validate_int)才是安全整型校验方案。
PHP中$var未定义却当整型用，直接报Notice: Undefined variable
PHP默认开启E_NOTICE级别错误，只要读取一个没声明过的变量（比如$id），哪怕后面想把它转成int，也会立刻抛出Notice: Undefined variable。这不是类型问题，是变量生命周期问题——你还没“生出来”，就急着“当整型用”。
常见场景：表单提交后直接写$uid = (int)$_POST['uid'];，但用户没传uid字段；或函数参数漏传，内部直接用$limit做intval($limit)。
- 别先
(int)再判断，要先确保变量存在——用isset()或array_key_exists()检查来源 - 更稳妥的做法是用
$_POST['uid'] ?? 0（PHP 7.0+）或($_POST['uid'] ?? null) !== null ? (int)$_POST['uid'] : 0 - 注意：
empty()不能替代isset()，因为empty(0)为true，会误判合法整型值
is_int()和is_numeric()混用导致逻辑翻车
想判断一个变量“是不是整数”，很多人第一反应是is_int()，但它只认type === integer——也就是说is_int('123')返回false，is_int(123.0)也返回false（因为它是float）。而is_numeric('123')或is_numeric('123.0')都返回true，但它连'1e4'、' 012 '都放行，根本不是“整型”校验。
- 真要确认“值可安全转为整型且无精度丢失”，用
filter_var($val, FILTER_VALIDATE_INT) !== false - 如果只是防错兜底（比如数据库ID必须是正整数），优先用
ctype_digit((string)$val)，它只接受纯数字字符串，且不接受负号、空格、前导零 - 别在
if里嵌套(int)强转再比对，比如if ((int)$x == $x)——$x = '123abc'时也会通过，因为(int)'123abc'是123
函数参数默认值设0，但调用时传null或空字符串仍出错
写函数时习惯设function get_user($id = 0)，本意是“没给ID就查默认用户”，但调用方传了get_user($_GET['id'] ?? null)，结果$id变成null，进函数后(int)null是0，看似没问题——可如果业务上0是非法ID（比如数据库主键从1开始），这就埋了雷。
立即学习“PHP免费学习笔记（深入）”；
- 参数默认值不如用
null占位，函数内部再明确处理：function get_user($id = null) { $id = filter_var($id, FILTER_VALIDATE_INT) ?: 0; } - PHP 8+ 可用联合类型：
function get_user(int|null $id = null)，这时传字符串会直接TypeError，反而更早暴露问题 - 别依赖
??兜底所有情况，比如$_GET['page'] ?? 1遇上?page=（空字符串）时，??不触发，结果(int)''是0，分页炸了
JSON接口返回int字段，前端却收到string，PHP里一比较就失效
前端发来的JSON里{"status": 200}，PHP用json_decode()默认得到对象，$data->status确实是int；但如果用了json_decode($json, true)转成数组，$data['status']仍是int。真正容易翻车的是：前端传了{"id": "123"}（字符串型ID），PHP解析后是string，你却直接拿去查数据库WHERE id = ?，PDO可能不报错但查不到——尤其MySQL开启严格模式时，隐式转换会被拒绝。
- 接API参数时，别信“看起来像数字”，统一用
filter_var($input, FILTER_VALIDATE_INT)校验并转换 - 数据库查询前，对关键整型字段强制
(int)或intval()，但记得先is_scalar()防null或数组 - 调试时用
var_dump(gettype($x), $x)而不是echo $x，避免类型混淆
最常被忽略的点：错误抑制符@挡不住Undefined variable，它只屏蔽运行时警告；而变量是否存在，是PHP解析执行阶段就决定的。该检查就得检查，绕不开。
