正则表达式无法彻底防御SQL注入，因其仅匹配字符串模式，无法应对大小写混写、多重编码、上下文组合、二阶注入、函数嵌套等绕过手段，且规则易引发回溯爆炸；根本防线是参数化查询。
正则表达式无法完全过滤恶意 SQL 注入语句，因为它根本不是为解决语法注入问题而设计的工具——它只能匹配字符串模式，而 SQL 注入的本质是让数据库引擎把用户输入当作可执行的语法结构来解析。
正则匹配不到大小写混写和编码变形
数据库不关心大小写，但正则若只写 /select/i，就拦不住 SeLeCt；更麻烦的是，URL 编码（如 %55NION）、Unicode 编码（如 \u0055\u004e\u0049\u004f\u004e）、宽字节（如 %A1%AA）等，都在数据库解码后才参与 SQL 解析，而正则通常在解码前运行。你写的规则永远追不上编码层的组合爆炸。
正则无法识别上下文合法但组合危险的片段
单个词本身无害，但拼在一起就构成攻击：
-
order单独出现没问题，by也无害，但ORDER BY price若被拼进动态子句，就可能被利用 -
O'Reilly是合法昵称，但正则若粗暴匹配单引号，就会误杀 -
1 AND SLEEP(1)不含任何黑名单关键词，却已是典型盲注载荷
正则看不到字段用途、拼接位置、SQL 层级，只能孤立地扫词，等于在语法树外绕圈。
正则对二阶注入和函数嵌套完全失效
二阶注入：第一次输入存入数据库（如昵称字段填 admin'--），第二次读出后拼进新查询才触发——正则在入库时没匹配，执行时早已晚了。
函数嵌套绕过更常见：EXTRACTVALUE(1,CONCAT(0x7e,(SELECT user()))) 里没有一个词在 SELECT|UNION|DROP 黑名单中，但数据库照常执行子查询。
这类载荷依赖数据库的函数解析能力，而非关键字显式存在。
正则规则越补越脆弱，且易引发回溯爆炸
想覆盖更多绕过，就得加分支、预查、否定逻辑，比如：
/(\bselect\b|\bun[i1]on\b|\/\*.*?\*\/|;|--|#)/is
这种正则不仅难写难测，还容易因贪婪匹配（如 .*?）在超长输入下触发 PREG_BACKTRACK_LIMIT_ERROR，拖慢整个请求。更关键的是，每发现一条新 payload，就得改规则、重测、上线——攻击者发一个新变体，你得人工响应一次，节奏永远落后。
真正不可替代的防线，是让恶意输入根本没机会变成 SQL 语句：用 mysqli::prepare、PDO::prepare 或 cursor.execute(sql, params) 把数据与结构彻底隔离。正则唯一合理的位置，是日志审计或前端提示，而不是请求拦截点。
