addslashes() 单独使用不安全，宽字节注入可绕过；应配对设置正确字符集（如 SET NAMES utf8mb4）或改用 mysqli_real_escape_string()；intval() 仅适用于整型字段，不可用于字符串；htmlspecialchars() 对 SQL 注入无效。
addslashes() 不能单独用，必须配对数据库字符集
直接调用 addslashes() 并不安全，它只做简单转义，而宽字节注入（如 GBK）会让转义失效。比如输入 %df%27，在 GBK 下会被解析为一个汉字 + 单引号，addslashes() 插入的反斜杠被吞掉，单引号重新“活过来”。
实操建议：
- 若必须用
addslashes()，先确认连接层字符集与表字段一致，例如 MySQL 连接时执行SET NAMES utf8mb4（不是utf8） - 优先改用
mysqli_real_escape_string()，它会读取当前连接的实际字符集并做适配转义 - 永远不要在
addslashes()后再拼接进 SQL——哪怕你“觉得”已经安全了
intval() 只适用于明确是数字的字段
intval() 是最干净的防御之一，但仅限整型场景。它把任何非数字开头的字符串全转成 0，比如 intval("123abc") → 123，而 intval("abc123") → 0。
常见错误现象：
- 用
intval()处理用户昵称、邮箱、搜索关键词等字符串字段 → 直接变空或0，功能崩溃 - 没校验返回值是否为有效正数，导致查询
WHERE id = 0返回意外数据 - 和
is_numeric()混用：is_numeric("123.45")返回true，但intval("123.45")截断为123，语义已偏移
htmlspecialchars() 对 SQL 注入完全无效
htmlspecialchars() 只处理 HTML 输出上下文，把 变成 <code><，防止 XSS。它对 SQL 解析器来说毫无意义——数据库根本不会去解析 HTML 实体。
典型误用场景：
- 在拼接 SQL 前对用户名调用
htmlspecialchars()，以为“转义了就安全”，结果' OR 1=1 --照样进库执行 - 把多个过滤函数堆叠使用：
htmlspecialchars(addslashes($input))→ 多余且误导，输出层和数据层职责混淆 - 用它替代白名单校验动态表名/列名 → 完全绕过，攻击者输
users%00或大小写混写照样穿透
正则黑名单过滤是幻觉，别写也别信
用 preg_replace() 删 SELECT、UNION、OR 1=1 这类规则，上线即失效。攻击者有几十种绕过方式：URL 编码、注释符包裹、大小写混写、空格替换为 /**/、甚至用函数嵌套如 SEL/*foo*/ECT。
真实影响：
- 正常用户输 “I love UNION JACK” 被截成 “I love JACK”，语义破坏
- 增加 CPU 开销，每个请求都跑十几条正则，性能下降明显
- 掩盖真正问题——开发者误以为“加了过滤就安全”，反而忽略参数化查询等根本方案
关键点在于：过滤函数只是补丁，不是盾牌。真正可靠的防护只有两条路——对数据用参数化查询，对结构（表名、排序字段等）用白名单硬编码。任何试图“清洗恶意输入”的思路，在 SQL 注入场景下，本质上都是在和攻击者玩猫鼠游戏，而且你大概率输。
