正则表达式无法保证SQL注入防护安全，因其仅做字符串匹配、不理解SQL语法结构，无法应对大小写混写、编码变形、二阶注入、盲注探测及动态SQL元素，且易造成误杀或漏判；真正安全需全程使用参数化查询并辅以白名单校验。
正则表达式只做字符串匹配，不理解SQL语法结构
正则匹配的是字符序列，而SQL注入攻击利用的是数据库解析器对语句的语法解释。比如用户输入 O'Reilly，正则若匹配单引号就会误杀；但输入 admin' --，正则可能只看到单引号和空格，却识别不出它会注释掉后续条件。更典型的是 UNI/**/ON SELECT 或 %55%4e%49%4f%4e（URL编码的UNION），正则要么漏掉，要么得写一堆分支来覆盖，还容易回溯爆炸。
参数化查询在数据库引擎层完成数据与结构隔离
使用 PDO::prepare() 或 mysqli_prepare() 时，SQL模板在服务端预编译，占位符（如 ? 或 :name）被标记为纯数据槽位。后续传入的值不会参与词法分析——哪怕传入 ' OR 1=1 --，数据库也只把它当一个字符串字面量，不会触发逻辑分支或注释行为。
这依赖两个关键事实：
- 数据库连接必须显式设置字符集（如
charset=utf8mb4），否则宽字节场景下仍可能绕过 - 所有用户输入都必须走绑定接口（
bind_param()、setString()等），不能混用拼接
正则无法处理动态SQL元素，而参数化有明确边界
表名、列名、排序方向（ORDER BY ?）、分组字段、LIMIT 偏移量——这些位置 MySQL 和 PostgreSQL 明确不支持参数化。正则既不能安全地“清洗”它们（比如把 created_at ASC 替换成 created_at 会破坏语义），也无法判断哪个输入属于合法字段名。
正确做法是白名单校验：
in_array($input, ['name', 'email', 'created_at'], true)- 对
LIMIT偏移量强制转整型并限范围：max(0, min((int)$offset, 1000)) - 绝不允许用户输入直接出现在
FROM或GROUP BY后面
正则容易被当成“已防护”的心理安慰
很多团队上线了 preg_replace('/(union|select|drop)/i', '', $input) 就以为万事大吉。但真实攻击链里，二阶注入（数据先入库再拼进新查询）、盲注探测（' AND SLEEP(1)--）、内联注释（/*!50000SELECT*/）全都不含关键词。这类 payload 不触发正则，却能成功打穿系统。
真正容易被忽略的点是：参数化查询不是“用了就安全”，而是“所有路径都必须用”。ORM 中调用 whereRaw()、text() 或手写 CONCAT() 拼接，等于主动退出安全区——这时候正则再密，也救不了那行裸字符串。
