lambdaquerywrapper更安全的根本在于字段引用方式：用user::getusername等方法引用替代字符串字段名，实现编译期类型校验与运行时反射提取，天然规避字段名拼错及结构注入风险。
LambdaQueryWrapper 本身不防注入，安全来自用法——不用字符串字段名、不拼 SQL、不滥用 apply，才真正避开硬编码陷阱。
为什么 LambdaQueryWrapper 比 QueryWrapper 更安全
根本区别在于字段引用方式：QueryWrapper 用字符串写字段名（如 "username"），一旦拼错或被前端传入恶意字段，就可能触发结构注入；LambdaQueryWrapper 用方法引用（如 User::getUsername），编译期校验类型，运行时字段名由反射提取，不经过字符串解析，天然绕过字段名拼接风险。
常见错误场景：
- 前端传
sort=update_time; DROP TABLE user，后端直接wrapper.orderByAsc(sortParam)→ 拼进 SQL 成ORDER BY update_time; DROP TABLE user -
QueryWrapper中写wrapper.eq("status", input)，input 是"1' OR '1'='1"→ 虽然值安全，但字段名"status"若来自不可信源（比如配置项或用户选择），就失去控制权
而 LambdaQueryWrapper 的写法：wrapper.eq(User::getStatus, input)，字段来源锁定在编译期确定的类结构里，无法被外部篡改。
apply 在 LambdaQueryWrapper 里照样危险
apply 方法不管用的是 QueryWrapper 还是 LambdaQueryWrapper，只要用了字符串拼接，就等于亲手打开注入口。它不关心你前面用了多少个 User::getXXX，只看你传进去的 SQL 片段是否干净。
安全写法必须用占位符：
- ✅
wrapper.apply("status = {0}", statusValue)→ 参数走PreparedStatement绑定 - ❌
wrapper.apply("status = '" + statusValue + "'")→ 直接拼接，statusValue是"1'; TRUNCATE user; --"就完蛋 - ⚠️
wrapper.apply("ORDER BY {0}", sortField)→ 报错或被忽略，{0}只对值生效，不支持结构动态化
如果真要动态排序字段，必须白名单校验后再转成方法引用：if ("price".equals(sortField)) wrapper.orderByAsc(User::getPrice);
like 查询里的 % 不是注入点，但可能破坏语义
like 方法本身走参数绑定，值不会导致注入，但手动拼 % 容易踩两个坑：
- 用户输入含
%或_，没设 escape 规则 → 查询结果超出预期（比如搜 “admin%” 却匹配到所有以 “admin” 开头的记录） - 前端传
keyword=100\%，后端写"%" + keyword + "%"→ 实际查的是%100\%%，数据库可能按转义逻辑处理，也可能不处理，行为不一致
推荐做法：
- ✅ 直接用
wrapper.like("name", keyword)，让 MyBatis-Plus 自动加前后% - ✅ 如需自定义通配位置，用
wrapper.likeRight("name", keyword)或wrapper.likeLeft("name", keyword) - ✅ 真要手动拼，确保
keyword已过滤或转义，且数据库配置了统一 escape 字符（如 MySQL 的ESCAPE '\'）
最常被忽略的一点：LambdaQueryWrapper 只保字段名安全，不保业务逻辑安全。比如把用户传的 role 值直接塞进 eq(User::getRole, roleParam)，虽然没注入，但若没做权限校验，照样能越权查管理员数据。安全不是单点防御，而是字段、值、结构、上下文全链路约束。
