深度学习检测SQL注入需先解析URL并拆分参数，还原编码后单独分析value；提取sqlparse语法树的结构异常信号（如括号深度、子查询数、关键字偏移）作为核心特征；输入应为多模态组合，避免纯字符级padding；监控特征漂移比准确率更关键。
直接用原始 URL 或拼接后的 query string 喂给深度学习模型，90% 以上会学偏——它识别的不是 SQL 注入，而是 URL 编码风格或常见参数名分布。
别跳过协议解析和参数切分这一步
真实攻击载荷藏在某个 value 里，比如 email=user%40domain.com%27%20UNION%20SELECT%20password，而不是整条 GET /login?email=...&pwd=...。模型若没看到“上下文边界”，就无法区分 UNION 是攻击还是字段名（如 union_member_id）。
- 必须用
urllib.parse.parse_qs()或requests.utils.requote_uri()先还原编码，再按key=value拆开 - 每个
value单独走后续流程；key名保留为上下文特征（例如id字段突然含;比comment字段更可疑） - 过滤掉明显白名单内容：匹配
^\d{11}$的手机号、^[a-z0-9._%+-]+@[a-z0-9.-]+\.[a-z]{2,}$的邮箱、ISO 格式日期等，避免污染训练信号
sqlparse 提取的不是布尔结果，而是结构异常信号
sqlparse.parse() 返回的是语法树对象，不是 True/False。真正有用的不是“能不能 parse”，而是 parse 出来的东西反不反常——比如括号嵌套到 5 层、子查询数量突增、关键字位置严重偏移。
- 记录
parse_error标志，但别直接当标签：ORM 自动生成的WHERE id IN (?)也会报错 - 统计括号嵌套最大深度：正常查询通常 ≤ 2，盲注常用
(SELECT (SELECT (SELECT ...)))达到 5+ 层 - 提取子查询数量：单层
SELECT是常态，嵌套 2 层以上是强风险信号 - 检查关键字位置：比如
FROM出现在第 20 个 token 而非前 5 个，说明前面塞了大量干扰字符（如注释、空格、编码绕过）
Keras 模型输入必须对齐语义粒度，不能只做字符级 padding
把整个 value 当字符串转成 int 序列再 pad_sequences，等于放弃所有结构信息。你喂进去的是“字符序列”，模型却要判断“SQL 逻辑是否异常”——中间缺了一层语义对齐。
- 推荐组合输入：
[ngram_vector, syntax_features, context_flags]，其中syntax_features包含括号深度、子查询数、parse_error、关键字偏移等标量 - 字符级 embedding 只用于辅助（如
Embedding层接LSTM），主干应依赖结构化特征，否则泛化差 -
loss='mse'在二分类任务中效果远不如'binary_crossentropy'；optimizer=SGD收敛慢，换成Adam更稳 - 别用固定
maxlen=15：实际 payload 长度波动大，建议按 P95 截断 + 动态 padding，或改用 attention-based pooling
上线后第一个崩点永远是特征漂移，不是准确率下降
业务接口一改格式（比如 id=123 → id={"type":"user","val":123}），sqlparse 对 JSON 字符串直接报错，parse_error 率一夜翻倍，模型误判暴增——这时看 AUC 还是 0.98，毫无意义。
- 必须监控：周同比
parse_error变化 >15%、括号深度中位数突降、子查询数量 95 分位骤升 - 这些指标比模型准确率早 3–5 天暴露问题；不设告警，模型两周内失效
- 别依赖全量人工标注：优先让模型对
parse_error=True但keyword_count=0的样本发起复核，这类 case 最易漏检变种
