filter_input()比直接读$_POST更安全，因其一步完成取值、类型校验与范围限制，天然规避空键、空白字符串及类型混淆；而$_POST返回原始未验证数据，易引发XSS或SQL注入。
filter_input() 为什么比直接读 $_POST 更安全
因为 filter_input() 一步完成取值 + 类型校验 + 范围限制，天然规避空键、空白字符串、类型混淆问题。直接读 $_POST['email'] 可能返回 null、'' 或 "123abc"，而 filter_input(INPUT_POST, 'email', FILTER_VALIDATE_EMAIL) 只返回合法邮箱字符串或 false。
常见错误是先取值再判断：isset($_POST['age']) && is_numeric($_POST['age']) —— 这会放过 "18.5"、"18e2" 或 "18abc"；而 filter_input(INPUT_POST, 'age', FILTER_VALIDATE_INT) 对这些全部返回 false。
- 必须显式传
options数组才能做范围检查：filter_input(INPUT_POST, 'age', FILTER_VALIDATE_INT, ['options' => ['min_range' => 1, 'max_range' => 120]])，漏掉数组包装会静默返回原始字符串 -
FILTER_SANITIZE_EMAIL不等于验证：它把"test@@domain.com"变成"test@domain.com"，但你仍需用filter_var($cleaned, FILTER_VALIDATE_EMAIL)单独校验 - PHP 8.1+ 已彻底移除
FILTER_SANITIZE_STRING，改用FILTER_SANITIZE_FULL_SPECIAL_CHARS或组合trim()+htmlspecialchars()
filter_var() 验证失败时怎么判断才靠谱
不同过滤器返回值行为不一致：FILTER_VALIDATE_* 系列统一返回 false 表示失败，FILTER_SANITIZE_* 系列可能返回空字符串 "" 或净化后的字符串，绝不能用 !$result 判断。
例如 filter_var("12.3", FILTER_VALIDATE_INT) 返回 false，但 filter_var("12.3", FILTER_SANITIZE_NUMBER_INT) 返回 "123"；又如 filter_var("", FILTER_VALIDATE_EMAIL) 也返回 false，但 filter_var(" ", FILTER_SANITIZE_EMAIL) 返回 ""。
立即学习“PHP免费学习笔记（深入）”；
- 验证类过滤器（
FILTER_VALIDATE_*）一律用=== false判断失败 - 清理类过滤器（
FILTER_SANITIZE_*）结果可能是""，需结合业务逻辑判断是否允许空值 - 永远别依赖
null—— 文档未承诺返回null，不同 PHP 版本行为可能变化 - 对邮箱等字段，务必先
trim()再验证，否则" user@example.com "会被FILTER_VALIDATE_EMAIL拒绝
为什么 filter_input() 验证通过后还必须用 PDO 预处理
因为 filter_input() 只管“看起来像”，不管“实际是不是”。"admin@example.com'; DROP TABLE users; -- " 会被 FILTER_VALIDATE_EMAIL 放行，但拼进 SQL 就是灾难。
预处理不是“多此一举”，而是唯一能切断 SQL 结构与数据耦合的方式。手动拼接、addslashes()、旧版 mysql_real_escape_string() 全部失效且易被绕过。
- 占位符只能是
?或:name，严禁把变量拼进 SQL 字符串："WHERE id = " . $_POST['id']是高危写法 - PDO 连接必须设
PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION，否则绑定失败可能静默忽略 - 数值型参数不用手动转
int：$stmt->execute([$_POST['id']])中的字符串"123"会被数据库当作数值处理（前提是字段类型匹配）
htmlspecialchars() 为什么输出时不能省略
XSS 发生在渲染时，不是输入时。哪怕邮箱已用 filter_var() 验证过，只要它最终要 echo 到 HTML 里，就必须过 htmlspecialchars() —— 这不是重复劳动，是分层防御的刚性要求。
漏掉 ENT_QUOTES 会导致属性内插值被绕过，比如 <input value="<?=$name?>"> 中的 " onclick=alert(1) 会直接执行。
- 必须显式指定第三参数编码：
htmlspecialchars($str, ENT_QUOTES, 'UTF-8')，否则旧版 PHP 默认编码可能不一致，引发单引号绕过 - 别信模板引擎自动转义——确认你用的引擎版本是否默认开启，以及是否覆盖了所有变量输出点
- 对富文本内容，
htmlspecialchars()会破坏格式，此时应换用HTMLPurifier白名单净化，而非关闭转义
验证和清理是两件事，输出转义和数据库隔离也是两件事。每个环节都不可替代，少一个就等于在墙上凿了个洞。
