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