MyBatis #{}与${}的区别：预编译原理、SQL注入风险与动态SQL实战-北京尧图网络

面试场景里有一个问题出现频率很高而且很多候选人答不到点上MyBatis 里#{}和${}有什么区别为什么已经有了安全的#{}还要设计一个容易被SQL注入的${}如果只回答“#{}是预编译${}是字符串拼接”面试官大概率还会追问那预编译为什么能防注入字符串拼接为什么危险动态排序、动态表名的需求到底怎么处理这种追问能快速区分“背过八股文”和“真正在项目里写过MyBatis”的人。这篇文章从JDBC预编译机制讲起用一个最小工程演示#{}和${}在同样一条SQL上的差异再分析${}在动态SQL里的真实使用场景最后给出白名单校验、日志配置、权限控制等工程建议。读完你不仅知道怎么答还能知道项目中踩到类似问题怎么排查。1. 面试官问这个问题到底想考察什么先说结论这道题考察的不是“记没记住两个符号的区别”而是三件事。第一对SQL注入原理的理解。SQL注入为什么能发生因为用户输入被拼接成了SQL语法的一部分改变了语句原本的执行语义。如果只是数据库查询结果变了那叫数据问题如果SQL结构被改变那才是安全问题。很多候选人能说出“SQL注入就是把恶意SQL拼进去”但说不清楚拼进去之后SQL引擎到底发生了什么。第二对JDBCPreparedStatement的理解。MyBatis的#{}最终会生成JDBC预编译占位符?这是安全的基本前提。如果连预编译、占位符、参数绑定这几个概念都不熟说明底层功底不足。第三对框架设计取舍的理解。MyBatis不是不知道${}危险它依然保留这个能力因为SQL里有“值”和“结构”两类内容。值可以参数化结构不能。这就是面试官想听的“设计原因”而不是简单一句“用来拼接的”。所以准备这道题时不要背答案要先建立一条完整链路用户输入 → MyBatis解析 → JDBC SQL构造 → 数据库执行。每一步都可能成为攻击面也都有对应的防御手段。2. SQL注入的本质与 #{} 的安全原理先看一个经典的登录场景。后端要校验用户名和密码SQL写成这样SELECT * FROM sys_user WHERE username admin AND password 123456如果密码是用户输入拼接出来的攻击者输入下面的字符串 OR 11 --拼接后SQL变成SELECT * FROM sys_user WHERE username admin AND password OR 11 --OR 11恒为真注释符号--把后面的SQL注释掉。这条语句在数据库里执行时实际生效的条件只剩WHERE 11等同于查询全表。这就是SQL注入的最典型例子核心在于输入内容进入了SQL语句的语法结构层而不是被当作一个普通参数值。JDBC里对应有两种写法。第一种是字符串拼接// 错误示例拼接SQL String sql SELECT * FROM sys_user WHERE username username AND password password ; Statement statement connection.createStatement(); ResultSet rs statement.executeQuery(sql);这种方式下用户输入直接嵌入SQL文本数据库会把整个字符串当作可执行SQL解析。第二种是预编译// 安全示例预编译参数绑定 String sql SELECT * FROM sys_user WHERE username ? AND password ?; PreparedStatement ps connection.prepareStatement(sql); ps.setString(1, username); ps.setString(2, password); ResultSet rs ps.executeQuery();?是占位符setString()把参数值交给数据库驱动处理。数据库先解析SQL结构再绑定参数。用户输入无论包含多少单引号、注释符、关键字都只是某个占位符的值不会改变SQL结构。MyBatis的#{}本质上就是第二种方式。下面这两条XML中的SQL效果相同select idselectUserByUsername resultTypecom.example.demo.entity.UserDO SELECT id, username, password, status FROM sys_user WHERE username #{username} AND status 1 /selectMyBatis会把#{username}替换成?然后在执行时通过PreparedStatement绑定实参。攻击者输入 OR 11 --最终传递到数据库的SQL是SELECT id, username, password, status FROM sys_user WHERE username ? AND status 1绑定参数后username的值就是那一长串字符它只会跟username字段做等值比较不会变成OR条件。有一点需要补充预编译防注入的前提是SQL语句结构在预编译阶段已经固定。如果SQL本身存在动态拼接比如后面的${}那结构就是变化的预编译机制也无法保护不可信的结构部分。#{}和${}的差异可以汇总成下表对比项#{}${}实现方式预编译占位符?字符串直接替换SQL注入风险低参数不会进入SQL语法层高输入可能改变SQL结构适用场景条件值、查询参数、插入值表名、排序字段、列名等结构部分使用方式#{param}${param}性能相同SQL可复用预编译语句每次拼接新SQL缓存收益有限调试可读性日志中显示占位符日志中显示完整SQL3. 环境准备与最小工程搭建为了直观验证#{}和${}的差异我们搭建一个Spring Boot MyBatis的最小演示工程。在进行任何SQL注入验证时务必使用本地测试数据库不要在生产环境或未授权系统上操作。假设你本机已有JDK和MySQL环境。JDK版本、Spring Boot版本、MySQL版本以你本机实际环境为准本文重点是演示通用思路不需要强绑定某个版本。首先创建一个Spring Boot项目引入MyBatis依赖。在pom.xml中加入dependency groupIdorg.mybatis.spring.boot/groupId artifactIdmybatis-spring-boot-starter/artifactId version请替换为项目实际可用版本/version /dependency dependency groupIdcom.mysql/groupId artifactIdmysql-connector-j/artifactId scoperuntime/scope /dependency如果你的项目是基于Spring Boot 3.xMyBatis官方推荐使用mybatis-spring-boot-starter的最新版本如果是Spring Boot 2.x使用对应兼容的旧版本。版本差异不影响本文核心结论。接着在src/main/resources/application.yml中配置数据源和MyBatis日志spring: datasource: url: jdbc:mysql://localhost:3306/demo_db?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: your_password driver-class-name: com.mysql.cj.jdbc.Driver mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.demo.entity configuration: map-underscore-to-camel-case: true # 开发环境打印SQL生产环境关闭避免敏感信息泄漏 log-impl: org.apache.ibatis.logging.stdout.StdOutImpl创建一张简单的用户表CREATE TABLE sys_user ( id BIGINT AUTO_INCREMENT PRIMARY KEY, username VARCHAR(50) NOT NULL, password VARCHAR(100) NOT NULL, status INT DEFAULT 1, created_at DATETIME ); INSERT INTO sys_user (username, password, status, created_at) VALUES (admin, admin123, 1, NOW()), (zhangsan, pass123, 1, NOW()), (testuser, test123, 0, NOW());新建实体类UserDO字段对应id、username、password、status、createdAt。然后创建Mapper接口和XML文件准备验证两类写法。4. 实操演示#{} 与 ${} 的注入差异先写一个Mapper接口定义两个方法一个用#{}查询用户一个用${}做模糊查询// 文件路径src/main/java/com/example/demo/mapper/UserMapper.java package com.example.demo.mapper; import com.example.demo.entity.UserDO; import org.apache.ibatis.annotations.Param; import java.util.List; public interface UserMapper { UserDO selectUserByUsername(Param(username) String username); ListUserDO searchUserByKeyword(Param(keyword) String keyword); }在src/main/resources/mapper/UserMapper.xml中写实现?xml version1.0 encodingUTF-8? !DOCTYPE mapper PUBLIC -//mybatis.org//DTD Mapper 3.0//EN http://mybatis.org/dtd/mybatis-3-mapper.dtd mapper namespacecom.example.demo.mapper.UserMapper select idselectUserByUsername resultTypecom.example.demo.entity.UserDO SELECT id, username, password, status FROM sys_user WHERE username #{username} LIMIT 1 /select select idsearchUserByKeyword resultTypecom.example.demo.entity.UserDO SELECT id, username, password, status FROM sys_user WHERE status 1 AND username LIKE %${keyword}% /select /mapper然后写一个Controller把接口暴露出来方便在本地用浏览器或curl测试// 文件路径src/main/java/com/example/demo/controller/UserController.java package com.example.demo.controller; import com.example.demo.entity.UserDO; import com.example.demo.mapper.UserMapper; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.RequestParam; import org.springframework.web.bind.annotation.RestController; import java.util.List; RestController public class UserController { private final UserMapper userMapper; public UserController(UserMapper userMapper) { this.userMapper userMapper; } GetMapping(/user/query) public UserDO query(RequestParam String username) { return userMapper.selectUserByUsername(username); } GetMapping(/user/search) public ListUserDO search(RequestParam String keyword) { return userMapper.searchUserByKeyword(keyword); } }启动项目后先访问/user/search?keywordzhang控制台会打印出最终执行的SQL。${}方式下日志里能看到SELECT id, username, password, status FROM sys_user WHERE status 1 AND username LIKE %zhang%此时如果传入一个恶意关键字比如http://localhost:8080/user/search?keyword%27%20OR%20%271%27%3D%271%27%20--URL解码后等价于 OR 11 --拼接后的SQL会变成SELECT id, username, password, status FROM sys_user WHERE status 1 AND username LIKE % OR 11 --%这条SQL执行时AND username LIKE %先判断一次然后OR 11恒为真--后面内容被注释掉最终返回所有status 1的用户。这说明${}把外部输入直接变成了SQL语法的一部分确实存在注入风险。现在再用/user/query?username%27%20OR%20%271%27%3D%271%27%20--测试#{}接口。观察日志MyBatis最终生成的SQL是SELECT id, username, password, status FROM sys_user WHERE username ? AND status 1传给username参数的是完整字符串 OR 11 --数据库只把它当作一个普通值去匹配查询结果为null。这就是预编译带来的效果同样一段用户输入在#{}里是参数在${}里是SQL代码。有一点需要提醒日志中看到“带占位符的SQL”和“绑定参数后的SQL”可能不是同一个形式。MyBatis的StdOutImpl会打印带?的preparing语句和设置参数的日志要结合两行一起看才能判断最终执行内容。很多人在排查注入问题时只盯着第一行忽略了参数绑定部分容易误判。5. 有 #{} 为什么还要设计 ${}动态SQL的真实场景既然${}存在注入风险为什么MyBatis还要保留它原因在于SQL语句中有一部分内容不是“值”而是“结构”结构无法用占位符替代。在JDBC的PreparedStatement中?只能替换值不能替换表名、列名、排序字段、GROUP BY字段这一类结构性内容。你可以试写这样一条SQLSELECT * FROM ? WHERE ? ?数据库根本无法预编译因为FROM后面需要的是表名不是字符串值。表名属于SQL语法结构的一部分。实际开发中常见的${}场景有三个。第一个场景动态排序字段。列表页常见的“按创建时间倒序”“按用户名排序”如果把排序字段直接传给#{}生成的SQL会变成ORDER BY created_at DESC数据库不会报错但排序不会生效因为这种写法比较的是常量字符串而不是字段名。这种情况下只能把字段名拼进SQL也就是用${}。select idselectUserOrderBy resultTypecom.example.demo.entity.UserDO SELECT id, username, password, status, created_at FROM sys_user WHERE status 1 ORDER BY ${orderColumn} ${orderDir} /select第二个场景动态表名。分库分表或多租户场景下同一个接口可能需要查询order_202401、order_202402这类物理表。表名无法作为参数占位只能拼接到SQL里select idselectFromTable resultTypecom.example.demo.entity.OrderDO SELECT * FROM ${tableName} WHERE user_id #{userId} AND order_status #{orderStatus} /select第三个场景某些模糊查询或自定义SQL片段。虽然模糊查询可以用CONCAT(%, #{keyword}, %)安全实现但遇到非常复杂的动态SQL片段需要拼进WHERE条件时开发者容易图省事直接用${}。从安全角度看这类需求多数能用if标签和#{}完成不应该成为使用${}的理由。关键问题来了上面这些场景必须使用${}但${}又不安全项目里应该怎么处理答案很简单对${}的入参做白名单校验。任何外部输入在进入${}之前都必须在代码层校验字符串合法性。以排序字段为例可以定义一个Map白名单// 文件路径src/main/java/com/example/demo/common/SqlGuard.java package com.example.demo.common; import java.util.HashMap; import java.util.Map; public class SqlGuard { private static final MapString, String SORT_COLUMN_MAP new HashMap(); static { SORT_COLUMN_MAP.put(id, id); SORT_COLUMN_MAP.put(username, username); SORT_COLUMN_MAP.put(createdAt, created_at); } public static String resolveSortColumn(String input) { String column SORT_COLUMN_MAP.get(input); if (column null) { throw new IllegalArgumentException(非法排序字段: input); } return column; } }然后在Service层调用Mapper之前做转换String safeColumn SqlGuard.resolveSortColumn(request.getSortColumn()); userMapper.selectUserOrderBy(safeColumn, safeDir);对于表名同理维护一张“允许访问的表清单”只有命中的表名才能进入${}。这样既保留了动态SQL的灵活性又把注入风险限制在可控范围内。从框架设计角度看MyBatis把${}开放出来本质是给开发者一个选择权。它默认开发者知道自己拼的是什么。一旦外部输入能影响${}的内容安全责任就从框架转移到了应用层代码。责任边界清晰但风险也集中。6. MyBatis与MyBatis-Plus这个问题有什么不同讨论MyBatis的#{}和${}时经常会被问到MyBatis-Plus。MyBatis-Plus是MyBatis的增强工具封装了通用CRUD、条件构造器、分页插件等能力。它并没有改变#{}和${}的底层机制只是在多数简单场景下开发者不再需要手写Mapper XML。MyBatis-Plus的条件构造器QueryWrapper可以这样用QueryWrapperUserDO wrapper new QueryWrapper(); wrapper.eq(username, username) .like(keyword, keyword);它会自动生成参数化的SQL底层还是预编译安全性和手写#{param}一致。但在涉及排序时orderByAsc、orderByDesc方法接收的是字符串字段名这些字段名最终也会进入SQL结构wrapper.orderByAsc(sortColumn);如果sortColumn来自前端不做白名单校验一样存在SQL注入风险。所以MyBatis-Plus不是安全免死金牌它只是把常见CRUD封装得更方便遇到结构型SQL片段时开发者仍然要遵循同样的防护原则。另外一个常见区别是手写MyBatis的XML更适合复杂查询和SQL调优MyBatis-Plus的Wrapper更适合单表简单查询。面试时如果被问到“MyBatis和MyBatis-Plus的区别”可以从封装程度、CRUD便捷性、XML控制力、代码侵入性等角度展开但要记住两者在#{}和${}的安全机制上是一致的。7. 常见问题与排查思路实际开发中跟#{}、${}相关的报错和安全问题并不少。下面整理几个高频问题。问题现象可能原因排查方式解决方案使用#{}传排序字段排序不生效字段名被当作字符串常量不是列名查看MyBatis日志中的SQL是否出现单引号改用${}并做白名单校验使用${}传表名传入后SQL报错表名中混入了特殊字符或SQL片段打印完整SQL检查表名部分表名白名单校验禁止外部直接传表名模糊查询用${}后出现注入且结果异常用户输入中含有OR、--等SQL关键字检查方法入参和日志中拼接后的SQL改用CONCAT(%, #{keyword}, %)MyBatis控制台不打印SQLlog-impl未配置或日志级别不匹配检查application.yml的log-impl配置开发环境配置stdout.StdOutImpl生产环境关闭参数中包含单引号${}方式直接报错拼接后的SQL引号不成对查看异常栈中的SQL片段优先使用#{}避免字符串拼接相同SQL在#{}下性能不如${}每次生成不同SQL文本预编译缓存失效观察数据库预处理语句缓存命中和执行计划尽量固定SQL文本结构部分通过白名单限制在少量常量内在这些问题里真正影响安全性的是“是否把外部参数直接拼进了SQL结构”。排查时第一步不是看代码逻辑而是先定位最终执行的SQL长什么样。MyBatis日志、PreparedStatement的参数绑定日志、MySQL慢查询日志都能帮你还原问题现场。需要补充一个容易踩的坑有人说“我用了${}但没出现注入因为我对参数做了转义”。这种思路不可靠。转义是黑名单思维SQL注入绕过手段很多比如内联注释、编码转换、数据库函数拼接等。更稳妥的做法是白名单校验或避免使用${}而不是试图把所有攻击Payload都挡在字符串过滤外面。8. 最佳实践与工程建议写MyBatis项目时建议直接把下面几条规则纳入团队开发规范。第一条能用#{}就不用${}。值类型参数全部走#{}无论是查询条件、插入值还是更新值。SQL注释里也可以注明“此处禁止使用${}”减少误用。第二条必须用${}时入参必须通过白名单校验。排序字段、表名、列名分别维护一张白名单表不在名单内的输入直接拒绝。校验逻辑放在Service层不要放在Mapper接口里这样接口调用方无法绕过。第三条数据库账号遵循最小权限原则。应用连接数据库的账号只给SELECT、INSERT、UPDATE、DELETE权限不给DROP、ALTER、CREATE等DDL权限。即使SQL被注入攻击者能做的事也会被限制在DML层面。权限设计是纵深防御的一部分不应该依赖SQL写法兜底。第四条MyBatis打印SQL只允许出现在开发环境。生产环境配置log-impl为空或使用日志框架且级别设为WARN避免SQL参数中的敏感信息写进日志文件。很多数据泄露事件不是数据库被攻破而是日志文件被拖走里面躺着完整SQL和用户参数。第五条代码评审时重点审查包含${}的XML文件。可以通过脚本或静态扫描工具搜索项目中的${}逐个确认入参来源和校验逻辑。建议把白名单校验方法统一放在工具类里例如SqlGuard减少散落各处的重复逻辑。第六条涉及多数据源或分库分表时动态表名场景要格外谨慎。分表规则一般在代码层算好再把计算后的表名传入Mapper不要在SQL里根据用户输入拼表名。如果分表插件已经支持自动路由优先用插件能力不要手写动态表名。第七条定期检查数据库预处理语句缓存。大量使用${}会产生不同SQL文本降低预编译语句的缓存命中率。当SQL文本量增长明显时优先审视是否有字段误用了${}而不是盲目调大数据库缓存。除了这些规则还建议把防注入知识做成团队内部分享。面试里问#{}和${}不是目的真正要的是候选人对安全边界有感知。工程上的安全不是靠单个API实现而是靠使用习惯、权限隔离、日志管控、评审机制共同组成的。9. 总结面试这样回答更有深度如果面试官问你“有#{}为什么还要设计${}”可以按这个思路回答。先讲机制#{}会编译为JDBC预编译占位符?参数由数据库驱动绑定不会改变SQL语句结构${}是纯字符串替换等同于把外部输入直接拼进SQL文本存在SQL注入风险。再讲设计原因预编译占位符只能替换“值”不能替换“结构”。动态SQL里的排序字段、表名、列名属于SQL结构部分无法用?占位所以MyBatis提供了${}来满足这类需求。但框架不能判断传入的结构是否可信只能由开发者通过白名单校验、代码评审等方式保证安全。最后讲实践项目里默认用#{}遇到结构型参数才用${}并且所有${}入参必须经过白名单校验。数据库账号最小权限、生产环境关闭SQL日志、代码评审关注XML中的${}这些是配套的纵深防御措施。这套回答既有底层原理又有框架设计动机还有工程实践明显比“#{}安全、${}不安全”这种一句话回答更能体现水平。面试之外的现实问题其实更值得注意能不能把规则落地到团队里。如果你下次看到同事在动态排序代码里直接拼接前端传来的字段名建议把本文的白名单方案发给他这比简单说一句“别用${}”要有说服力得多。

MyBatis #{}与${}的区别：预编译原理、SQL注入风险与动态SQL实战

相关推荐

FFmpeg高清视频批量处理：从格式转换到硬件加速实战

上下文窗口再长，Agent为什么还是接不上项目？

AI从记住数据到理解世界：大模型距离AGI还有多远的技术拆解

更多资讯

零基础搞定CATIA二次开发：CAA、RADE与VS环境搭建全攻略

32位Office与64位ACE引擎安装冲突：根因分析与MSI修改解决方案

32位Office与64位ACE引擎共存：7-Zip拆包+ORCA改MSI实战

UiPath下载安装与社区版配置：许可证、Profile与包源避坑

UiPath社区版安装全流程：环境对表、注册激活与避坑验收

会议纪要哪个软件总结精准？智在记录、通义听悟、飞书妙记、Otter.ai 横评实测

今日更新

Agent-Reach：打通大模型触达外部系统的最后一公里

深度学习图像隐写分析实战：从CNN原理到毕设源码全解析

AI赋能知识产权供需匹配：专利评估、需求挖掘与多路召回工程实践

本周精选

防幻觉智能体架构：电源硬件设计中的大模型编排与工具化实践

OpenGL面试核心考点：渲染管线、矩阵变换与性能排查全解析

全国计算机二级C语言真题PDF高效刷题指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？