禁用不受信的 Native Query 是最直接有效的防线，因其不免疫 SQL 注入；动态表名、列名等须白名单校验；IN 子句需固定占位符绑定；复杂动态查询应改用 JdbcTemplate + 白名单 + PreparedStatement。
禁用不受信的 Native Query 是最直接有效的防线，因为 @Query(nativeQuery = true) 本身不免疫 SQL 注入——它只是把 SQL 交给了 JDBC PreparedStatement，但前提是 SQL 字符串里没混入用户输入。
nativeQuery 为什么看起来“安全”实则危险
很多人误以为加了 nativeQuery = true 就自动防注入，其实它只保证命名参数（如 :name）走预编译绑定，但整个 SQL 字符串仍由开发者拼出来。一旦你在字符串里拼接用户输入，比如 "SELECT * FROM " + tableName + " WHERE id = :id"，JPA 根本不拦你，PreparedStatement 也救不了——因为表名根本不是参数上下文。
- 错误示例：
@Query(value = "SELECT * FROM user WHERE name = '#{#name}'", nativeQuery = true)——#{}是 SpEL 表达式，运行时直接字符串替换，等同于拼接 - 更隐蔽的坑：
"SELECT * FROM user WHERE status IN (" + String.join(",", ids) + ")"—— 即使ids是数字列表，未经校验的字符串拼接仍可能被注入1,2,3) OR (1=1 - PostgreSQL 的
quote_ident()在 JPA 中无效：JPA 不解析函数语义，:table传进去仍是纯字符串，不会触发数据库端转义
哪些 nativeQuery 场景必须人工白名单校验
动态表名、列名、排序方向（ASC/DESC）、GROUP BY 字段、UNION 分支，这些都属于 SQL 结构部分，不能靠参数化。JPA 规范明确禁止运行时解析它们。
- 表名/列名：必须从预设集合中匹配，例如
Set.of("user", "order", "product")，不匹配就抛IllegalArgumentException - 排序字段：只允许
"created_at","updated_at","score"等硬编码值，禁止接收request.getParameter("sort")直接进 SQL - IN 子句：别写
WHERE id IN :ids（JPA 不支持数组展开），改用构建固定长度占位符，如WHERE id IN (?, ?, ?)，再用PreparedStatement.setLong(i, id)逐个绑定
替代方案：什么时候该放弃 @Query(nativeQuery = true)
当你的查询需要真正动态的结构（比如多租户分表、按业务类型切换主表、实时字段聚合），@Query 已经不是合适工具。继续硬塞只会让校验逻辑越来越重、出错概率越来越高。
- 改用
JdbcTemplate+ 白名单 +PreparedStatement：你能完全控制 SQL 拼接时机和校验点，比如先validateTableName(inputTable)再query("SELECT * FROM " + safeTable + " WHERE ...", stmt -> { ... }) - 复杂条件组合优先走
Specification：它生成的是 JPQL，底层由 Hibernate 转成安全的预编译 SQL，连 LIKE 通配符都建议写死在语句里（LIKE %:name%），而非由 Java 拼"%" + name + "%" - 真要执行不可控 SQL（如后台 DBA 工具）：必须限制数据库账号权限（只读、禁用
DROP/EXECUTE）、记录完整执行日志、设置超时阈值
最麻烦的不是写不出安全代码，而是有人在 Service 层偷偷用 String.format 拼完 SQL 再扔给 JdbcTemplate，还自以为“没用 @Query 就没事”。这种绕过框架约束的手动拼接，才是生产环境里最常被漏掉的注入入口。
