SQL注入漏洞的核心成因，本质上是因为用户输入直接参与了SQL语句的字符串拼接，而未采用参数化绑定机制。在MyBatis中使用${}、QueryWrapper中调用apply()与last()、JPA的@Query注解进行拼接等操作，都会绕过PreparedStatement的安全防护。动态字段必须严格执行白名单校验，这是最基本的安全底线。
数据库只识别字符串本身，无法理解你的真正意图——你拼接出的那条SQL，攻击者完全可以将其改写成另一条恶意命令。事实就是这么简单。
动态拼接SQL的本质，是将用户输入当作可执行代码
Spring Boot 3本身并不生成SQL语句，但开发者一旦使用String.format()、+进行拼接，或者采用MyBatis的${}语法，就相当于把用户的输入原封不动地塞进了SQL字符串中。此时数据库收到的不是“查询用户名为XXX的用户”，而是一段等待解析的完整文本——攻击者只需让这段文本变成SELECT * FROM users WHERE username = 'admin' OR '1'='1'，查询条件就会完全失效。
- 常见错误写法：
@Select("SELECT * FROM users WHERE name = '${name}'")（MyBatis注解中使用${}） - 危险场景：模糊搜索、动态排序、多条件组合查询
- 后果不仅仅是报错，而是静默返回本不该看到的数据，甚至执行
DROP TABLE等破坏操作
MyBatis-Plus的QueryWrapper并不能自动免疫注入
许多人误以为使用QueryWrapper就绝对安全，实际上它只是封装了参数绑定的逻辑——一旦混用apply()或last()方法插入原始SQL片段，就会立刻回归到拼接模式，失去保护。
queryWrapper.eq("name", name)✅ 安全（底层走PreparedStatement）queryWrapper.apply("age > " + userAge)❌ 危险（userAge为用户传入的字符串）queryWrapper.last("ORDER BY " + sortField)❌ 危险（sortField若未做白名单校验，可填入id; DROP TABLE users--）
JPA的@Query注解同样要区分“编译期”与“运行期”
@Query默认使用命名参数（:name）是安全的；但一旦启用nativeQuery = true并在内部写上WHERE name = ?1，再配合String.valueOf()进行拼接传参，就等于绕过了框架的所有保护机制。
- 安全写法：
@Query("SELECT * FROM users WHERE name = :name") - 高危写法：
@Query(value = "SELECT * FROM users WHERE name = ?1", nativeQuery = true) + repository.findByName("' OR 1=1 --") - 更隐蔽的陷阱：
@Query中使用CONCAT('%', :keyword, '%')做模糊查询没有问题，但若写成"%"+ keyword +"%"再拼入SQL字符串，就会瞬间崩塌
真正防住注入的关键不在于“用了哪个框架”，而在于“谁在构建最终的SQL字符串”
Spring Boot 3的JDBC层、MyBatis、JPA都依赖于PreparedStatement，但它只会在参数值被单独传入时才生效。只要用户输入参与了SQL字符串的拼接过程，哪怕只拼了一个字段名、一个表名、一个ORDER BY子句，防御体系就已经被打破。
- 表名、列名、排序方向等无法参数化的部分，必须进行白名单校验（例如
sortField只允许"id"、"name"、"created_at"） - 动态
IN查询不能靠拼接?占位符的个数，而应使用Collection参数配合IN :ids的形式 - 在日志中看到
Preparing: SELECT * FROM users WHERE name = ?才代表真正进入了预编译流程；如果日志显示Preparing: SELECT * FROM users WHERE name = 'admin''--'，说明已经中招
最容易被忽略的一点：安全边界不在Controller层，而在DAO层最后一行SQL构造语句。哪怕前面做了十层校验，只要最后那一行用了+或${}，整条安全链路就会瞬间坍塌。
