正则表达式无法彻底防止SQL注入，因其变体极多（如大小写混用、URL编码、双写绕过、注释符变形、空格替换等），难以全覆盖；易误杀正常数据（如O'Reilly），且绕过正则后恶意语句仍可拼接执行；唯一合理用途是非SQL上下文的轻量校验，真正防护必须依赖PDO预处理并禁用模拟、正确设字符集与错误模式。
不能。正则表达式无法彻底防止SQL注入，它最多只能作为辅助过滤层，且容易被绕过。
为什么正则匹配对SQL注入是无效防御
SQL注入的变体极多：大小写混用（SeLeCt）、URL编码（%27）、双写绕过（selselectect）、注释符变形（/**/、#、--%20）、空格替换为制表符或换行符等。正则很难覆盖所有路径，而攻击者只需找到一个漏网变体就能突破。
常见错误现象包括：
- 用户昵称含单引号（如
O'Reilly）被误杀，导致正常数据提交失败 - JSON字段、Base64内容、富文本中的SQL关键词被误判拦截
- 绕过正则后仍拼接到查询中，最终执行恶意语句
哪些正则写法看似“防注入”实则危险
这类代码在老项目里很常见，但本质上是虚假安全感：
立即学习“PHP免费学习笔记（深入）”；
-
preg_replace('/(union|select|insert|drop|;|--|#)/i', '', $input)—— 关键词可被注释包裹、大小写混淆、或用函数绕过（如extractvalue()） -
str_replace(["'", '"', ';'], '', $input)—— 完全忽略无引号上下文（如ORDER BY 1 ASC后直接接UNION SELECT） - 只对
$_GET或$_POST做过滤，却忽略$_COOKIE、$_SERVER['HTTP_REFERER']等其他输入源
PDO预处理必须配合的关键配置
即使用了 prepare() 和 bindValue()，如果PDO连接配置不当，仍可能退化为模拟预处理，失去防护能力：
- 必须显式关闭模拟预处理：
$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false) - 必须指定字符集（如
charset=utf8mb4），否则宽字节注入可能绕过（如%df%27） - 错误模式应设为异常：
$pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION)，避免静默失败掩盖问题 - 占位符类型要匹配实际用途：
PDO::PARAM_INT用于数字ID，PDO::PARAM_STR用于字符串，不能全用PARAM_STR
正则唯一合理的使用位置
它只应在**非SQL上下文**中做轻量校验，比如：
- 验证用户名是否只含字母数字和下划线：
preg_match('/^[a-zA-Z0-9_]{3,20}$/', $username) - 检查手机号格式：
filter_var($phone, FILTER_SANITIZE_NUMBER_INT)配合strlen() - 从日志或监控字段中提取可疑模式用于告警，而非阻断请求
真正进入数据库操作前，所有动态值必须走参数绑定——这是不可妥协的边界。任何试图用正则“清洗SQL”的思路，都等于在数据库门口装个门帘，却把锁拆了。
