SQL 注入防护必须使用参数化查询，正则仅适用于前端校验或日志筛查；禁用大小写忽略、避免贪婪匹配、不依赖关键字过滤；应统一使用 prepare 语句、输入过滤和权限最小化。
SQL 注入防护不能只靠正则
正则表达式根本拦不住真正的 SQL 注入，preg_replace 或 str_replace 过滤几个关键字（比如 SELECT、UNION）反而会制造虚假安全感。攻击者早就不写大写关键字了，用注释绕过、大小写混写、URL 编码、双写变形（SELESELECTCT）都能轻松绕过。真正有效的防护只有参数化查询——这是数据库驱动层的事，不是字符串处理层能解决的。
哪些场景下正则“勉强可用”
正则唯一合理用途，是做前端快速校验或日志关键词筛查，比如拦截明显恶意输入（' OR 1=1 --）、过滤掉全角单引号、删除连续空格和换行等格式干扰。它不能替代后端防护，只能当第一道粗筛。
- 只用于表单提交前的 JS 提示，不作为服务端判断依据
- 匹配目标限定为：显式注释符号（
--、/*）、裸露单 / 双引号、分号结尾（;）、括号嵌套超深（如(((((） - 避免使用
/i忽略大小写——这会让selECT漏掉；不如直接禁用整个字段 - 别写
/union|select|insert/i这类规则——un//ion就能绕过
常见正则误用与报错现象
开发者常写的 preg_replace('/(union|select|drop)/i', '', $input) 会导致两种典型问题：一是破坏正常语义（用户昵称含 union 被删成 in），二是触发 MySQL 的 strict mode 报错（比如删掉 WHERE 后面的空格导致语法错误）。更糟的是，有些正则引擎在处理超长输入时会爆栈（PREG_BACKTRACK_LIMIT_ERROR）。
- 用
preg_match判断比用preg_replace删除更安全——匹配到就拒收，不改原始数据 - 避免贪婪匹配
.*，尤其在日志清洗中容易吃掉整行 - PHP 中注意 PCRE 的
u修饰符必须加，否则中文字符可能截断出错 - Node.js 的
RegExp不支持p{L}，但 PHP 8+ 支持，跨语言别直接复制粘贴
真正该做的三件事
把精力从“怎么写正则”转移到这三个动作上，防护效果提升一个数量级：
- 所有数据库操作统一走
mysqli::prepare或PDO::prepare，变量全部用?占位符 - 用户输入进 SQL 前，先过
filter_var($input, FILTER_SANITIZE_STRING)（PHP 7.4+ 已弃用，改用htmlspecialchars+ 明确字符集） - 数据库账号权限最小化——应用账号只给
SELECT、INSERT，绝不要FILE或EXECUTE
正则能帮你发现异常输入，但永远没法定义“合法 SQL”。越想用它堵漏洞，越容易漏掉边界 case——比如 JSON 字段里嵌了 SQL 片段，或者 GraphQL 查询体里混了原生 SQL。这事得交给数据库协议本身来管。
