正则无法有效防御SQL注入，因其仅做文本扫描而无法理解SQL语义；绕过方式多样（大小写、编码、嵌套函数等），清洗易破坏数据，真正安全依赖参数化绑定与上下文白名单校验。
正则匹配的是字符串，不是SQL语法结构
正则表达式在输入到达数据库前只做一次文本扫描，而SQL注入的生效依赖数据库解析器对语义的完整还原。比如 UNI/**/ON 被正则当作两个无关片段放过，但 MySQL 在词法分析阶段会先剥离注释、归一化空格，最终合成合法的 UNION 操作符。同样，%27（URL编码单引号）在 PHP 中若未提前解码，正则根本看不到原始引号；等 urldecode() 在后续环节执行时，恶意字符早已进入拼接流程。
绕过方式远超正则覆盖能力
攻击者不需要写出完整、规范的 SQL 就能触发注入。常见绕过包括：
- 大小写混用：
SeLeCt、uNiOn—— 即使加i修饰符也难保所有 Unicode 变体 - 空白符替换：
%09（Tab）、%0a（换行）、\s匹配 - 函数嵌套：
EXTRACTVALUE(1,CONCAT(0x7e,(SELECT user())))中无关键词，却可回显数据 - 盲注载荷：
AND SLEEP(1)、OR (SELECT COUNT(*) FROM users)=1—— 全由基础符号和数字构成，正则无法标记为“危险”
清洗行为本身就会破坏业务逻辑
用 preg_replace 删除匹配内容看似“安全”，实则引入新问题：
- 用户昵称
Jack O'Reilly被删掉单引号后变成Jack OReilly，数据失真 - 搜索关键词
order by price若正则误判order和by为关键字，清洗后查询失效 - 删除分号或
--后，原本合法的存储过程调用或注释可能被截断，导致 MySQL strict mode 报错 - 过度使用
.*类贪婪匹配易触发PREG_BACKTRACK_LIMIT_ERROR，尤其在长文本字段中
真正起作用的边界不在正则，而在参数绑定点
是否被注入，取决于用户输入**最终如何进入 SQL 执行流**：
- 如果走
PDO::prepare("SELECT * FROM users WHERE id = ?")+execute([$id])，哪怕$id = "1 OR 1=1"，数据库也只当它是字符串值，不会解析为逻辑表达式 - 如果走
"SELECT * FROM users WHERE id = " . $id，无论你用多少层正则过滤，只要拼接发生，风险就存在 - ORM 的
.where("status = '" . $_GET['s'] . "'")写法，和裸写 PDO 拼接一样危险 —— 框架不能掩盖错误用法
最常被忽略的一点：正则永远不知道某个输入是进 WHERE 条件、ORDER BY 字段，还是表名。而这些位置的安全要求完全不同 —— 前者可用参数化，后者必须靠白名单校验。
