HQL参数绑定能防SQL注入，因其将查询结构与用户输入严格分离，Hibernate底层通过PreparedStatement机制确保输入仅作为数据处理；错误拼接字符串（如+号连接）则直接绕过防护。
为什么HQL参数绑定能防SQL注入
HQL（Hibernate Query Language）本身不直接拼接SQL，它在解析阶段就将查询结构和参数分离。只要不用String.format或+拼接用户输入进HQL字符串，而坚持用命名参数（:param）或位置参数（?1），Hibernate 6 就会在底层通过PreparedStatement机制传递值——这意味着用户输入永远作为数据而非SQL语法执行。
常见错误是误以为“用了HQL就安全”，结果写出类似这样的代码：
String hql = "FROM User u WHERE u.name = '" + userInput + "'"; // ❌ 危险！已退化为字符串拼接
这本质上绕过了HQL的参数机制，等同于手写JDBC拼接SQL。
正确写法：命名参数 vs 位置参数
Hibernate 6 推荐优先使用命名参数，语义清晰、可读性强，且支持重复引用同一参数；位置参数在简单场景下也可用，但顺序错一位就会抛QueryParameterException。
立即学习“Java免费学习笔记（深入）”；
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 命名参数示例：
String hql = "FROM User u WHERE u.status = :status AND u.age > :minAge";<br>Query<User> query = session.createQuery(hql, User.class);<br>query.setParameter("status", "ACTIVE");<br>query.setParameter("minAge", 18); - 位置参数示例（仅限Hibernate 6.2+，旧版不支持类型安全）：
String hql = "FROM User u WHERE u.status = ?1 AND u.age > ?2";<br>Query<User> query = session.createQuery(hql, User.class);<br>query.setParameter(1, "ACTIVE");<br>query.setParameter(2, 18);
注意：setParameter() 方法会自动根据字段类型做类型转换（如把"18"转成Integer），但前提是实体映射正确；若传入null，Hibernate默认允许，不会报错。
哪些操作容易漏掉参数绑定
真正容易出问题的地方，往往不在主查询，而在动态拼装的WHERE子句、ORDER BY、IN列表或子查询中。
-
IN子句：不能直接
setParameter("ids", Arrays.asList(1,2,3))就完事——必须用setParameterList("ids", list)，否则Hibernate会把整个List当做一个参数值处理，导致SQL语法错误或全表扫描。 -
ORDER BY字段名：字段名（如
userName）属于SQL结构，不能参数化。必须白名单校验后硬编码，或用Criteria API重构。 -
LIKE模糊匹配：通配符（
%）要拼在Java变量里，不是HQL里：query.setParameter("namePattern", "%" + userInput + "%");—— HQL中仍写u.name LIKE :namePattern。 -
原生SQL混用：如果调用
session.createNativeQuery()，参数绑定规则相同，但必须确保SQL模板本身不拼接用户输入，否则防不住。
参数绑定失效的典型错误信号
遇到以下现象，基本可以判定参数绑定没生效或被绕过：
- 日志中出现类似
org.hibernate.QueryParameterException: Could not locate named parameter [xxx]—— 说明HQL写了:xxx但没调setParameter()，或名字拼错。 - 查询返回空结果，但手动把参数值代入HQL字符串再用数据库客户端执行却有结果 —— 很可能参数类型不匹配（比如数据库字段是
VARCHAR，却传了Integer）。 - 启用
hibernate.show_sql=true后，看到生成的SQL里参数位置显示为?，但值没出现（显示为null）—— 检查是否调用了setParameter()，或该参数被后续setParameter()覆盖。
最隐蔽的问题是：你在DAO里写了参数绑定，但上层Service又用字符串拼接构造了HQL再传进来——防御只做了一半，边界没守牢。
