Spring Data JPA 默认防 SQL 注入，前提是不用 @Query(nativeQuery = true)、不拼字符串、不手动构造 SQL；派生方法、命名参数 @Query、JpaRepository 自带方法等均通过 PreparedStatement 安全执行。
Spring Data JPA 默认就防 SQL 注入，但前提是别碰 @Query(nativeQuery = true)、别拼字符串、别手动构造 SQL 结构——这三件事里只要做错一件，防线就彻底失效。
哪些 JPA 查询方式天然免疫 SQL 注入
这些写法由 Hibernate 在运行时生成 PreparedStatement，参数全程走绑定，不拼字符串，所以安全：
-
findByUsername(String username)、findByStatusAndRole(String status, String role)等派生方法：参数自动转为?占位符 -
@Query("SELECT u FROM User u WHERE u.email = :email")+@Param("email")：命名参数被 Hibernate 解析为预编译占位符 -
@Query("SELECT u FROM User u WHERE u.id IN :ids")+@Param("ids") List：Hibernate 会把集合展开成等长的?, ?, ? - 所有
JpaRepository自带方法（save()、findById()、findAll(Specification)）：底层调用标准 JPA API，不暴露 SQL 构造逻辑
@Query(nativeQuery = true) 是高危操作
原生 SQL 绕过 Hibernate 的解析层，直接交给 JDBC 执行。一旦你用字符串拼接变量，等于主动开门放攻击者进来。
- 错误示范：
@Query(value = "SELECT * FROM user WHERE name = '" + name + "'", nativeQuery = true)—— 直接触发注入 - 正确做法：必须用
?1、?2或:name占位符，且只通过@Param或位置传参 - 注意：
IN子句不支持动态长度绑定（WHERE id IN :ids会报错），得手动写固定个数占位符，比如IN (?2, ?3, ?4)，再配对应参数
动态条件不能靠 StringBuilder 拼 SQL
@Query 是编译期固定的，没法运行时改结构。所谓“动态拼 SQL”，本质是外部字符串拼接，一拼就破防。
- 典型翻车点：在 service 层用
StringBuilder拼出完整 SQL 字符串，再塞进@Query—— 这根本不是 JPA 的用法，是自建漏洞 - 替代方案一：
JpaSpecificationExecutor+Specification：用 Java 代码构建类型安全的条件树，最终仍生成 PreparedStatement - 替代方案二：
JdbcTemplate+PreparedStatementCreator：手动控制预编译流程，适合复杂原生查询场景
ORDER BY 和模糊查询的特殊处理
这两类操作无法用参数占位符，因为字段名和通配符位置属于 SQL 结构的一部分，不是值。
-
ORDER BY字段：不能写成ORDER BY :sortField，Hibernate 不认；需白名单校验后硬编码，或用Sort对象（如PageRequest.of(0, 10, Sort.by("username").ascending())） -
LIKE模糊查询：参数本身要带%，比如repository.findByNameContaining("%" + input + "%")，但注意input必须先过滤掉%、_等通配符，或改用ESCAPE机制 - 更稳妥的做法：用
CriteriaBuilder构建like()表达式，由 Hibernate 处理转义
真正容易被忽略的是：防御不是加一层“过滤器”或“校验工具类”就能解决的；它取决于你每一行持久层代码是否让参数脱离了 SQL 结构上下文。哪怕只在一个角落用了 StringBuilder.append(request.getParameter("order"))，整个应用的 SQL 安全假设就崩了。
