PHP接收表单提交的整型数据，不能直接信$_POST
PHP的 $_POST 里所有值默认都是字符串——哪怕表单里填的是 123，$_POST['age'] 的值也是字符串 "123"，不是整型 123。直接用在算术、数据库插入或类型强校验场景会出问题。
常见错误现象：
• 数据库写入失败（如字段是 INT，但传入了带空格的 " 42 "）
• if ($_POST['status'] === 1) 永远不成立（因为是 "1"）
• array_sum($_POST['ids']) 返回 0（字符串被强制转为 0）
- 用
filter_input()最稳妥：它能同时过滤、转换、验证 - 避免用
(int)或intval()粗暴转换——它们对"12abc"会返回12，对空字符串返回0，掩盖非法输入 - 如果必须用
intval()，务必配合is_numeric()或正则先判断格式，例如preg_match('/^\d+$/', $_POST['id'])
filter_input() 处理整型 POST 数据的标准写法
这是 PHP 原生推荐方式，兼顾安全、可读和健壮性。它默认拒绝空值、非数字字符，并可指定范围限制。
示例：获取用户ID，要求是正整数且不超 999999
立即学习“PHP免费学习笔记（深入）”；
$user_id = filter_input(INPUT_POST, 'user_id', FILTER_VALIDATE_INT, [
'options' => ['min_range' => 1, 'max_range' => 999999]
]);
返回值：
• 合法整数 → 返回对应整型（如 42）
• 空、非数字、超范围 → 返回 false（不是 0！）
- 必须显式检查返回值是否为
false，不能只用if ($user_id)（因为0是合法整数） - 不要省略第四个参数（
options数组），否则FILTER_VALIDATE_INT对空字符串也返回false，但无法捕获"12.5"这类浮点字符串 -
FILTER_SANITIZE_NUMBER_INT是清洗函数，不是验证函数——它会把"-12abc34"变成"-1234"，不该用于表单校验
数据库插入前，整型字段还要再确认一次
即使前端和 filter_input() 都做了处理，MySQL/PostgreSQL 在严格模式下仍可能因隐式类型转换报错，尤其当字段设为 NOT NULL 且没默认值时。
- 插入前加一层防御：用
is_int($user_id) && $user_id > 0再确认类型和业务逻辑 - PDO 插入时，用
PDO::PARAM_INT绑定参数，比拼接字符串更可靠：$stmt->bindValue(':id', $user_id, PDO::PARAM_INT) - 如果框架用了 Eloquent 或 Doctrine，它们内部通常已做类型转换，但依然建议在
Request层用filter_input()或validate()提前拦截
注意表单本身对整型输入的误导性支持
HTML 的 <input type="number"> 看似能限制输入，但它只影响浏览器 UI，完全不阻止用户用开发者工具改 DOM、或用 curl 提交任意字符串（如 "NaN"、"null"、"1e5"）。
-
type="number"允许输入"1.5"、"-2"、甚至空格开头的" 3 "，这些都会进$_POST并需后端校验 - 不要依赖
required或min/max属性做最终验证——它们可被绕过 - 如果业务只要非负整数，建议用
<input type="text" pattern="\d*">+ JS 提示，但后端校验仍是唯一可信防线
整型处理最易被忽略的点：把“看起来像数字”当成“就是整数”。PHP 不自动类型提升，也不替你做业务规则判断——"007" 是字符串，"123.0" 是无效整型，"" 和 null 都得单独应对。
