jOOQ在Spring Boot 3中天然防SQL注入，因其编译期强制使用类型安全的DSL（如USERS.EMAIL.eq(email)），所有用户输入均经PreparedStatement.setObject()绑定，杜绝字符串拼接；禁用DSL.sql()、动态表名拼接及field("str")等绕过类型检查的操作。
为什么jOOQ在Spring Boot 3里天然防SQL注入
jOOQ不是靠“写对规则”来防注入，而是靠编译期类型约束和运行时自动参数绑定双保险。只要你用生成的TableField（比如USERS.EMAIL）而不是字符串"email"去构造条件，所有用户输入值都会被强制走PreparedStatement.setObject()路径——哪怕你传的是"admin' OR 1=1 --"，它也只会作为字符串字面量绑定，不会进入SQL解析阶段。
关键前提是：必须用jOOQ DSL API构建查询，不能退化到字符串拼接。下面这些写法都安全：
dsl.select().from(USERS).where(USERS.EMAIL.eq(email))dsl.select().from(USERS).where(USERS.STATUS.in(statusList))dsl.select().from(USERS).where(USERS.CREATED_AT.between(start, end))
而一旦出现"WHERE email = '" + email + "'"或DSL.sql("SELECT * FROM " + tableName)，防护就彻底失效。
动态WHERE条件该怎么加才不破防
真实业务里常要根据前端参数决定是否加某个过滤条件，比如“只在传了status时才加status = ?”。jOOQ原生支持链式条件累积，不用拼SQL字符串：
var query = dsl.select().from(USERS);if (status != null) query = query.where(USERS.STATUS.eq(status));if (minAge > 0) query = query.where(USERS.AGE.gt(minAge));List<userrecord> result = query.fetch();</userrecord>
注意两点：
- 每个
where()调用都是追加逻辑AND，无需手动拼" AND " - 所有字段引用必须来自代码生成类（如
USERS.STATUS），不能是"status"这种字符串 - 如果要用OR，必须显式调用
DSL.or()，比如USERS.STATUS.eq("A").or(USERS.STATUS.eq("B"))
IN列表、LIKE模糊匹配怎么安全传参
IN和LIKE是高频高危点，但jOOQ处理得很干净：
-
IN列表直接传List：USERS.ID.in(idList)→ 自动生成id IN (?, ?, ?)并绑定全部值 -
LIKE必须用DSL.concat()或DSL.inline()包裹通配符：USERS.NAME.like(DSL.concat("%", DSL.val(name), "%"))，这样name仍走参数绑定，不会变成"%' OR 1=1 --%" - 禁止用
USERS.NAME.like("%" + name + "%")——这是字符串拼接，直接破防
另外，DSL.val()和DSL.inline()有本质区别：val()进参数绑定，inline()会直接渲染进SQL字符串（相当于白名单内联值），慎用。
哪些操作会悄悄绕过jOOQ防护
最危险的不是不会用，而是误以为用了就安全。这几个坑踩中一个，防护形同虚设：
- 手写
DSL.sql("SELECT * FROM " + tableName)：表名/列名无法参数化，必须白名单校验后才能拼接 - 用
DSL.field("user_name")代替USERS.USER_NAME：绕过了类型检查，字段名拼错编译不报错，运行时报错或查错数据 - 在
@Query(nativeQuery = true)里混用jOOQ：jOOQ不接管这类注解，它只管自己DSL构建的SQL - 把jOOQ当字符串工具用，比如
String sql = dsl.select().from(USERS).getSQL()再拿去JdbcTemplate执行：此时参数绑定已丢失，必须用query.bind()重新绑定
真正安全的边界很清晰：只要整条SQL从dsl.select()...开始，到.fetch()或.execute()结束，中间没穿插字符串拼接、没调用DSL.sql()、没混用其他框架的原生SQL接口，那它就是安全的。
