mybatis-plus的querywrapper和lambdaquerywrapper本身不自动防sql注入，安全取决于正确使用：禁用字符串拼接和${}，apply()须用{0}占位符，字段名/排序字段需白名单校验，优先使用lambdaquerywrapper避免字符串硬编码。
MyBatis-Plus 的 QueryWrapper 和 LambdaQueryWrapper 本身不自动防注入，安全完全取决于你是否用对了方法——只要不用字符串拼接、不滥用 ${}、不把用户输入直接塞进 SQL 结构部分，就基本不会中招。
别碰 apply() 的裸字符串拼接
apply() 是 Wrapper 里唯一能主动引入 SQL 注入的入口。它允许插入任意 SQL 片段，但必须配合占位符使用。
- ❌ 危险写法：
queryWrapper.apply("status = '" + userInput + "'")—— 用户输"1'; DROP TABLE user; --"就直接执行删库语句 - ✅ 安全写法：
queryWrapper.apply("status = {0}", userInput)——{0}触发 JDBC 参数绑定，等价于?，值被转义后传入 - ⚠️ 注意：
{0}只保护参数值，不能用于字段名、表名、排序方向（如ORDER BY {0}会报错或被忽略）
字段名和排序字段必须白名单校验
像 orderByAsc(sortField) 或 groupBy("user_id") 这类方法，sortField 或字符串字段名是直接拼进 SQL 的，不走参数绑定，毫无防护。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 前端传
sort=update_time; DROP TABLE user→ 生成ORDER BY update_time; DROP TABLE user - 必须显式校验：
if (!List.of("price", "create_time", "sales").contains(sortField)) { throw new IllegalArgumentException(); } - 更稳妥：改用
LambdaQueryWrapper，例如lambdaWrapper.orderByAsc(User::getCreateTime)，彻底避开字符串字段名
所有内置条件方法（eq、like、in 等）默认安全
这些方法底层全部走 PreparedStatement 参数绑定，和 MyBatis 的 #{} 本质一致，值不会参与 SQL 解析。
-
queryWrapper.like("name", userInput)是安全的，哪怕userInput是"admin' OR '1'='1"，也只会查一个叫这个名字的用户 - 但注意模糊通配符陷阱：
queryWrapper.like("name", "%" + keyword + "%")如果keyword含%或_，可能破坏查询语义；推荐让框架自己加通配符：queryWrapper.like("name", keyword) - 动态条件判断要带布尔开关：
queryWrapper.eq(name != null, "name", name)，避免空值导致条件误加
优先用 LambdaQueryWrapper 而不是 QueryWrapper
二者功能几乎一样，但 LambdaQueryWrapper 用方法引用代替字符串字段名，既防拼写错误，也杜绝字段名被污染的风险。
-
new QueryWrapper<user>().eq("user_name", "tom")</user>—— 字段名硬编码，重构时易出错，且无法校验合法性 -
new LambdaQueryWrapper<user>().eq(User::getUserName, "tom")</user>—— 编译期检查，字段名变更时立即报错，字段名永远来自实体定义 - 字段名动态化需求极少，一旦出现（比如多租户字段），仍需白名单兜底，不能依赖 Lambda
最常被忽略的一点：安全不是 Wrapper 自动给的，而是你每次调用 apply、orderByAsc、groupBy 时，都要问一句——这个字符串是不是用户可控？如果是，就必须校验或换用 Lambda。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
