安全处理需分层拦截：接收时验证类型、存库前分离逻辑、输出前转义字符；filter_var() 验证失败仅返回 false 而不报错，须显式判断；整数验证须加范围选项；FILTER_SANITIZE_EMAIL 仅清理不验证，需拆两步；PDO 预处理防注入但字段名等须白名单校验；htmlspecialchars() 必须指定 UTF-8 编码及 ENT_QUOTES 选项，JS 中应使用 json_encode()；filter_input() 返回 null 表示键缺失，需区分 null 与 false；FILTER_SANITIZE_STRING 已废弃；同一输入在不同上下文（HTML/JS/CSV）需不同处理。
直接拼接用户输入进 SQL 或 HTML，99% 会出事。安全处理不是选一个函数凑合用，而是按数据流向分层拦截：接收时验证类型、存库前分离逻辑、输出前转义字符。
filter_var() 验证邮箱/整数时为什么返回 false 却不报错
因为 filter_var() 对验证失败只返回 false，不抛异常，容易被忽略导致空值或布尔值误入后续流程。
- 必须显式判断返回值是否为
false，不能只用if ($email)—— 空字符串、"0"、0都是 falsy，但只有false表示验证失败 - 整数验证要加范围选项：
filter_var($_POST['age'], FILTER_VALIDATE_INT, ["options" => ["min_range" => 1, "max_range" => 120]])，否则"123abc"会被截成123通过验证 -
FILTER_SANITIZE_EMAIL只删非法字符，不校验格式；想同时做清理+验证，得拆成两步：$email = filter_var($_POST['email'], FILTER_SANITIZE_EMAIL); if (!filter_var($email, FILTER_VALIDATE_EMAIL)) { /* 拒绝 */ }
PDO 预处理语句绑定参数后仍被注入的常见原因
预处理本身防注入，但绑定方式写错就等于没防——比如把变量名当字符串字面量传进去，或者在 SQL 字符串里拼接字段名。
- 占位符只能用于**值**，不能用于表名、列名、排序方向（
ORDER BY ?是错的），这些必须走白名单校验后硬编码 - 用
bindValue()时别漏掉第三个参数类型，比如整数不加PDO::PARAM_INT，PHP 可能传成字符串，触发隐式类型转换漏洞 - 别混用命名参数和问号参数：
prepare("WHERE id = :id AND status = ?")在部分 PDO 驱动下行为未定义，统一用一种
htmlspecialchars() 输出时为什么还有 XSS 漏洞
漏设编码或上下文错配是主因。它只对 HTML 文本内容有效，放错位置或缺参数等于白干。
立即学习“PHP免费学习笔记（深入）”；
- 必须显式传入第三个参数
'UTF-8'，否则 PHP 5.4+ 默认用ini_get('default_charset')，若配置为空或错配，可能导致双字节截断绕过 - 在 HTML 属性里输出时，要用
ENT_QUOTES（如echo htmlspecialchars($val, ENT_QUOTES, 'UTF-8');），否则单引号属性（title='xxx'）里的'不转义，可闭合标签注入 JS - 绝对不要在 JavaScript 字符串里直接插
htmlspecialchars()结果，<script>var x = "<?php echo htmlspecialchars($user_js, ENT_QUOTES, 'UTF-8'); ?>";</script>依然危险，应改用json_encode($str, JSON_HEX_TAG | JSON_HEX_AMP | JSON_HEX_APOS | JSON_HEX_QUOT)
filter_input() 替代 $_POST 直接访问时的兼容陷阱
filter_input() 看似更安全，但它默认对缺失键返回 null，而 $_POST['key'] 是 undefined index 警告（E_NOTICE），开发环境可能关了警告，导致空值静默穿透。
- 调用时必须检查返回值是否为
null：$id = filter_input(INPUT_POST, 'id', FILTER_VALIDATE_INT); if ($id === null) { /* 键不存在 */ } elseif ($id === false) { /* 验证失败 */ } -
FILTER_SANITIZE_STRING在 PHP 8.1+ 已彻底移除，代码里还用会 fatal error；替代方案是trim()+htmlspecialchars()+ 白名单preg_replace()，按需组合 - 它不支持嵌套数组（如
$_POST['user']['name']），遇到这种结构得手动递归调用或改用filter_var_array()
最易被跳过的其实是上下文切换：同一段用户输入，入库前是数据，输出到 HTML 是文本，放进 JS 是字符串，塞进 CSV 是字段——每个场景的过滤/转义规则都不同，靠一个函数打天下，迟早翻车。
