java中sql注入防护不能依赖if判断关键词，必须使用preparedstatement参数化查询实现代码与数据分离，并辅以输入白名单、业务校验和基于行为的异常监控。
Java 中不能靠 if 逻辑直接拦截 SQL 注入，这是根本性误区。单纯用 if 判断关键词（如 "or"、"union"、"--"）不仅无效，反而危险——它既漏报（绕过检测的变体极多），又误报（正常业务字段含 "or" 就被拦），还容易被大小写、编码、注释、空格等手法轻松绕过。
真正有效的拦截方式：预编译参数化查询
SQL 注入的本质是“代码与数据混淆”，防御核心是严格分离 SQL 结构和用户输入。Java 的标准解法是使用 PreparedStatement，由数据库驱动完成变量绑定，彻底杜绝拼接风险：
- 所有用户输入都通过
setString()、setInt()等方法传入，不参与 SQL 字符串拼接 - 即使输入为
"1' OR '1'='1"，也会被当作纯字符串值处理，不会改变 SQL 语义 - 无需手动过滤关键词，也不依赖正则或
if判断
补充防护层：输入白名单 + 业务校验
在参数化基础上，对输入做合理约束可进一步提升安全性：
- 对 ID、状态码等字段，用枚举或正则限定合法值（如
"^[a-zA-Z0-9_]{3,20}$"） - 对搜索关键词等模糊场景，若必须拼接（极少数例外），仅允许 ASCII 字母、数字、常见符号，并统一转义（如
StringEscapeUtils.escapeSql()，但注意该工具已废弃，慎用） - 拒绝明显异常输入：超长字符串、全空格、纯控制字符等，记录日志但不拦截——它们更可能是扫描试探
告警不是靠 if 拦截，而是基于行为分析
真正的攻击识别应基于上下文，而非单点关键词：
- 记录高频失败查询（如连续 5 次语法错误）、同一 IP 短时大量不同结构 SQL 请求
- 监控 JDBC 异常日志（
SQLException中含 "syntax error"、"unexpected token" 等特征） - 用 AOP 或过滤器收集请求参数，在日志中打标可疑模式（如参数含
%27即 URL 编码单引号），供 SIEM 系统聚合分析
为什么不要写 if (sql.contains("union")) {...}
这类代码看似“有防护”，实则制造虚假安全感：
-
UNION/**/SELECT、un%69on、U\N\I\O\N均可绕过 - 正常业务中用户昵称叫 "Union Bank" 或地址含 "OR-123" 就会误杀
- 维护成本高：新攻击手法出现就得加新 if，永远追不上
- 分散安全责任，让开发误以为“加了 if 就安全”，忽视参数化等根本措施
不复杂但容易忽略：把所有 SQL 查询重构为 PreparedStatement，配合严格的输入长度与格式校验，再辅以异常日志监控，就是最扎实的防护。告警系统应聚焦异常行为，而非字符串匹配。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
