PHP用户输入需分四阶段过滤：接收验证、存储清理、输出转义、入库隔离；filter_input()可安全取值并验证类型与范围；htmlspecialchars()必须在HTML输出时显式指定ENT_QUOTES和UTF-8编码防XSS。
PHP过滤用户输入不是选一个函数就完事，而是按数据流向分阶段处理：接收时验证类型、存储前清理内容、输出前转义字符、入库时隔离语句。漏掉任一环节都可能被绕过。
filter_input() 获取并验证GET/POST参数更安全
直接读 $_POST['email'] 没做任何校验，等于把解析权交给攻击者。用 filter_input() 一步完成“取值 + 验证”：
-
filter_input(INPUT_POST, 'age', FILTER_VALIDATE_INT)返回整数或false，不会返回字符串"18abc" -
filter_input(INPUT_GET, 'page', FILTER_VALIDATE_INT, ['options' => ['min_range' => 1]])可带范围检查，避免传入负数或超大值 - 注意
FILTER_SANITIZE_STRING在 PHP 8.1+ 已废弃，别再用；改用filter_var($input, FILTER_SANITIZE_SPECIAL_CHARS)或明确组合trim()+htmlspecialchars()
htmlspecialchars() 必须在输出到HTML时调用
哪怕输入已用 filter_var() 验证过邮箱，只要它最终要 echo 到页面里，就必须过一遍 htmlspecialchars()。XSS 不发生在输入时，而发生在渲染时。
- 必须显式指定第三参数编码：
htmlspecialchars($str, ENT_QUOTES, 'UTF-8')，否则旧版 PHP 可能因默认编码不一致导致单引号绕过 -
ENT_QUOTES要带上，否则属性内插值如<input value="<?=$name?>">仍可能被" onclick=alert(1)注入 - 不要依赖模板引擎自动转义——确认你用的引擎版本是否默认开启，以及是否覆盖了所有变量输出点
PDO预处理语句是防SQL注入的唯一可靠方式
别信 addslashes()、mysql_real_escape_string()（已废弃）或任何手动拼接加转义的方案。只有预处理能从根本上切断 SQL 结构与数据的耦合。
立即学习“PHP免费学习笔记（深入）”；
- 占位符必须是
?或:name，不能把变量拼进 SQL 字符串里，例如"WHERE id = " . $_POST['id']是高危写法 - 连接需设错误模式：
new PDO($dsn, $user, $pass, [PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION])，否则绑定失败可能静默忽略 - 数值型参数不用额外转 int，
$stmt->execute([$_POST['id']])中的字符串"123"会被数据库当作数值处理，前提是字段类型匹配
白名单正则过滤只用于强格式约束场景
当业务要求用户名只能是字母数字下划线、手机号必须11位纯数字时，filter_var() 不够用，得上 preg_match() 白名单。
- 用
^和$锚定首尾：preg_match('/^[a-zA-Z0-9_]{3,20}$/', $username)，否则"admin<script>"</script>也能部分匹配成功 - 清理优先用
preg_replace()删除非法字符，而不是preg_match()后丢弃整个字段——除非业务规则严格禁止模糊容忍 - 别用黑词表（如屏蔽
"script"），攻击者可轻松变形绕过，白名单才是唯一可信路径
最常被忽略的是：同一份用户输入，在不同上下文要走不同过滤链。比如一个昵称字段，入库前用 trim() + 白名单正则，存进数据库；查出来后显示在页面要过 htmlspecialchars()；若还要放进 JS 变量，则得用 json_encode() 包裹。没有“一次过滤，到处适用”的银弹。
