为什么利用正则表达式过滤SQL关键字无法保证百分百安全？

正则表达式过滤SQL关键字不能保证安全，因其仅做字符串扫描而无法应对大小写混写、编码变形、语义组合、二阶注入、盲注探测等绕过方式，且性能与维护成本高；应使用参数化查询实现数据与结构隔离。

正则表达式过滤 SQL 关键字不能保证安全，因为它本质上是在做「字符串扫描」，而 SQL 注入是「语法注入」——攻击者绕过正则的方式远比你写的规则多。

正则匹配不到大小写混写和编码变形

正则 b(select|union)b 会漏掉 SeLeCt、%55NION、/**/UNION/**/SELECT 这类常见绕过。即使加了 i 标志，也无法覆盖 URL 编码、Unicode 编码（如 union）、宽字节编码（如 %A1%AA）等变体。数据库解析器在执行前会先解码，而正则通常只对原始输入做一次匹配。

无法识别语义合法但上下文危险的片段

比如用户昵称填 O'Reilly，正则若匹配单引号就会误杀；又比如搜索关键词含 order by price，order 和 by 单独出现本无害，但组合后可能被拼进动态 ORDER BY 子句里。正则看不到字段用途、拼接位置、SQL 结构层级，只能孤立地看词。

完全挡不住二阶注入和盲注探测

• 二阶注入：第一次输入存入数据库（如昵称 admin'--），第二次读出后拼进新查询，正则在入库时没触发，执行时才生效
• 盲注探测：' AND SLEEP(1)-- 或 ' AND (SELECT COUNT(*) FROM users) > 0-- 不含典型关键字，靠行为而非词法触发，正则基本无效

性能与维护成本随规则膨胀急剧上升

想覆盖更多绕过，就得加更多分支、预查、否定逻辑，比如：/(bselectb|bun[i1]onb|/*.*?*/|;|--|#)/is。这种正则不仅难写难测，还会因回溯爆炸拖慢请求；更麻烦的是，每发现一条新 payload，就得改规则、重测、上线，永远追不上攻击者节奏。

真正要防住 SQL 注入，得让恶意输入根本没机会变成 SQL 语句——用 PreparedStatement、pg_query_params、cursor.execute(sql, params) 这类机制把数据和结构彻底隔离。正则最多当个日志审计辅助，别让它站在第一道防线的位置。