正则过滤不能单独防御SQL注入，真正有效的是字段级白名单加参数化查询；正则易被多编码、上下文无关性及解码层级问题绕过，仅宜作白名单兜底或日志清洗。
正则过滤不能单独防御SQL注入，它只能作为白名单的辅助手段；真正起效的是字段级白名单 + 参数化查询双保险。
为什么正则过滤在API层容易失效
正则本质是字符串模式匹配，而SQL注入的绕过方式远超字符层面。比如admin%00' OR 1=1（含空字节）、admin（HTML实体编码）、或用注释符/* */包裹关键字，都能轻松绕过^[a-zA-Z0-9_]+$这类基础正则。
更关键的是：正则无法区分“合法业务输入”和“恶意上下文”。例如搜索词OR本身可能是用户真实需求（如查“Windows OR Linux”），但拼进WHERE title LIKE '%{input}%'就危险——问题不在输入本身，而在它被使用的上下文。
- 正则只做表面校验，不理解SQL语法结构
- 多编码、多层解码场景下，正则位置难确定（前端、网关、后端哪层校验？）
- 过度依赖正则会让人误以为“已防护”，反而忽略参数化等根本措施
白名单必须按字段定义，不能全局一刀切
白名单不是写一个ALLOWED_CHARS常量完事，而是针对每个API字段明确“允许什么、长度多少、是否可为空”。比如：
class UserSearchRequest {
// ✅ 白名单：仅允许字母数字+空格，4–30字符，且必须存在
[RegularExpression(@"^[a-zA-Z0-9\s]{4,30}$")]
public string Keyword { get; set; }
<p>// ✅ 白名单：严格限定为预设排序字段，不可来自请求
[AllowedValues("name", "created_at", "score")]
public string SortBy { get; set; }</p><p>// ✅ 白名单：页码必须是1–1000之间的整数
[Range(1, 1000)]
public int Page { get; set; }
}这种白名单直接绑定到模型验证层，在反序列化后、业务逻辑前就拦截非法值，比手动写正则更可靠、更易维护。
- 排序字段、分组字段、表名/列名类动态SQL元素，必须用枚举或配置项硬编码，禁止任何用户输入参与
- 搜索关键词类开放字段，白名单要兼顾业务合理性（如允许中文、emoji）而非一味收紧
- 所有白名单规则需配合
MaxLength、MinLength、Range等边界约束，防住超长payload试探
正则只该用在白名单兜底或日志清洗环节
正则唯一稳妥的用法，是作为白名单验证后的补充动作，或用于非核心路径的日志脱敏：
- 在审计日志中用
Regex.Replace(sql, @"(password|token|key)=\w+", "$1=***")隐藏敏感参数值 - 对富文本字段（如评论）做粗筛：
^[^\x00-\x08\x0b\x0c\x0e-\x1f\x7f-\x9f]*$排除控制字符，防底层协议异常 - 网关层用正则快速拒绝明显恶意特征（如
UNION\s+SELECT、EXEC\s+\(），但必须配合WAF签名库，不替代应用层防护
注意：所有正则都应使用RegexOptions.Compiled（.NET）或预编译实例（Java/Python），避免每次调用都重新解析，否则性能损耗显著。
最易被忽略的一点：白名单规则本身必须走配置中心或代码常量管理，不能藏在某段if里；一旦字段语义变化（比如“用户名”开始支持邮箱格式），白名单没同步更新，就会变成新的攻击面。
