mybatis的#{}占位符和${}拼接符的区别

没有检索到摘要

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

mybatis做为一个轻量级ORM框架在许多项目中使用,因其简单的入门受到了广大开发者的热爱。

#{}占位符:占位

使用#{}意味着使用的预编译的语句,即在使用jdbc时的preparedStatement,sql语句中如果存在参数则会使用?作占位符,我们知道这种方式可以防止sql注入,并且在使用#{}时形成的sql语句,已经带有引号,例,select * from table1 where id=#{id} 在调用这个语句时我们可以通过后台看到打印出的sql为:select * from table1 where id=‘2’ 加入传的值为2.也就是说在组成sql语句的时候把参数默认为字符串。

如果传入的是基本类型,那么#{}中的变量名称可以随意写
如果传入的参数是pojo类型,那么#{}中的变量名称必须是pojo中的属性.属性.属性…

${}拼接符:字符串原样拼接
如果传入的是基本类型,那么${}中的变量名必须是value
如果传入的参数是pojo类型,那么${}中的变量名称必须是pojo中的属性.属性.属性…
注意:使用拼接符有可能造成sql注入

使用${}时的sql不会当做字符串处理,是什么就是什么,如上边的语句:select * from table1 where id=${id} 在调用这个语句时控制台打印的为:select * from table1 where id=2 ,假设传的参数值为2

从上边的介绍可以看出这两种方式的区别,我们最好是能用#{}则用它,因为它可以防止sql注入,且是预编译的,在需要原样输出时才使用${},如,

select * from ${tableName} order by ${id} 这里需要传入表名和按照哪个列进行排序 ,加入传入table1、id 则语句为:select * from table1 order by id

如果是使用#{} 则变成了select * from ‘table1’ order by ‘id’ 我们知道这样就不对了。

另,在使用以下的配置时,必须使用#{}

<select id="selectMessageByIdI" parameterType="int" resultType="Message">
    select * from message where id=#{id};
</select>

在parameterType是int时,sql语句中必须是#{}。
<!-- 
id:sql语句唯一标识 
parameterType:指定传入参数类型
resultType:返回结果集类型
#{}占位符:起到占位作用,如果传入的是基本类型(string,long,double,int,boolean,float等),那么#{}中的变量名称可以随意写.
#{}:如果传入的是pojo类型,那么#{}中的变量名称必须是pojo中对应的属性.属性.属性.....
-->
<select id="findUserById" parameterType="int" resultType="cn.itheima.pojo.User">
       select * from user where id=#{id}
</select>
<!-- 
${}拼接符:字符串原样拼接,如果传入的参数是基本类型(string,long,double,int,boolean,float等),
那么${}中的变量名称必须是value
${}:如果传入的参数是pojo类型,那么`${}`中的变量名称必须是pojo中的属性.属性.属性...
注意:拼接符有sql注入的风险,所以慎重使用
 -->
<select id="findUserByUserName" parameterType="string" resultType="user">
    select * from user where username like '%${value}%'
</select>

<think>我们正在讨论MyBatis#{}${}的区别及使用场景。根据引用[1]、[2]、[3]、[4]、[5]的内容,可以总结如下:#{}${}都是MyBatis中用于动态传递参数的符号,但它们的工作机制安全性有本质区别:1.**处理机制不同**:-`#{}`:MyBatis会将SQL中的`#{}`替换为预编译语句中的占位符`?`,然后使用PreparedStatement的参数绑定机制来安全地设置值。这种方式会对传入的参数进行类型处理(如字符串类型会自动加单引号)并转义特殊字符,有效防止SQL注入攻击。-`${}`:MyBatis会直接将`${}`中的内容替换为参数的字符串值(不进行预编译处理)。如果参数是字符串类型,不会自动添加引号,所以需要手动添加单引号。这种方式是简单的字符串替换,存在SQL注入风险。2.**安全性差异**:-使用`#{}`时,由于参数会被预编译,因此可以防止SQL注入。例如,当传入参数为`a&#39;or&#39;1&#39;=&#39;1`时,使用`#{}`会转义单引号,变成`\&#39;`,从而避免非法查询。-使用`${}`时,如果参数值包含恶意SQL片段,会被直接拼接到SQL语句中执行,导致SQL注入风险。3.**适用场景**:-`#{}`适用于绝大多数场景,特别是作为查询条件值(WHERE子句中的值)、INSERT/UPDATE语句中的字段值等需要参数绑定的地方。-`${}`通常用于需要动态指定SQL语句非值部分的情况,例如:-动态排序字段(ORDERBY子句),如:`ORDERBY${columnName}[ASC|DESC]`(引用[1]、[2]、[4])-动态指定表名或列名(非值部分),如:`SELECT*FROM${tableName}`(引用[4])-动态SQL片段(如动态指定GROUPBY字段)4.**性能考虑**:-`#{}`生成的预编译语句可以被数据库缓存重用,提高执行效率。-`${}`每次都会生成新的SQL语句(因为内容可能变化),无法利用预编译缓存,性能略低。5.**使用细节**:-在`${}`中引用字符串类型参数时,需要在XML中手动添加单引号(如`&#39;${name}&#39;`),但这样仍然不安全(引用[5])。建议对用户输入进行严格过滤或避免使用。-在编写LIKE模糊查询时,推荐用`#{}`配合通配符处理(如`LIKECONCAT(&#39;%&#39;,#{keyword},&#39;%&#39;)`或代码中添加`%`),而不是用`${}`(引用[4])。###代码示例对比####安全用法(使用`#{}`)```xml<selectid="selectUser"resultType="User">SELECT*FROMusersWHEREname=#{name}ANDage=#{age}</select>```####动态排序(必须使用`${}`)```xml<selectid="selectUsersOrdered"resultType="User">SELECT*FROMusersORDERBY${orderColumn}${orderDirection}</select>```>⚠️注意:使用`${}`时,应确保参数值来自可信源(如后端枚举值),或进行严格校验。###总结|特性|`#{}`|`${}`||--------------|-------|------------||工作机制|预编译占位符|字符串替换||安全性|高(防注入)|低(有注入风险)||自动添加引号|是|否(需手动)||适用场景|参数值|动态SQL片段(表名/列名/排序)|因此,**在多数情况下优先使用`#{}`;仅当需要动态生成SQL关键字或标识符时(无法用预编译占位符代替),才谨慎使用`${}`**。§§相关问题§§1.如何安全地使用MyBatis动态表名?2.MyBatis中如何预防SQL注入?3.除了#{}${},MyBatis还有哪些动态SQL标签?</think> ### MyBatis中`#{}``${}`的区别及使用场景 #### 一、核心区别 | **特性** | **`#{}`** | **`${}`** | |----------------|-------------------------------------|-------------------------------------| | **处理机制** | 预编译占位符 (`?`) | 字符串直接替换 | | **安全性** | 防止SQL注入(自动转义特殊字符)[^4] | 有SQL注入风险(原样拼接)[^3][^4] | | **引号处理** | 自动添加引号(如字符串类型) | 需手动添加引号(如`&#39;${value}&#39;`) | | **性能** | 预编译语句可复用 | 每次生成新SQL | #### 二、使用场景对比 1. **`#{}` 的适用场景** - **条件值传递**(WHERE子句): ```xml SELECT * FROM user WHERE name = #{name} ``` 编译后:`SELECT * FROM user WHERE name = ?`(安全)[^2][^3] - **LIKE模糊查询**(需配合通配符): ```xml SELECT * FROM user WHERE name LIKE CONCAT(&#39;%&#39;, #{keyword}, &#39;%&#39;) ``` - **INSERT/UPDATE操作**: ```xml INSERT INTO user (name, age) VALUES (#{name}, #{age}) ``` 2. **`${}` 的适用场景** - **动态排序字段**(ORDER BY): ```xml SELECT * FROM user ORDER BY ${orderField} ASC ``` *若用`#{}`会生成`ORDER BY &#39;name&#39;`(语法错误)* [^1][^4] - **动态表名/列名**: ```xml SELECT * FROM ${tableName} ``` - **固定SQL片段**: ```xml ${"LIMIT 10"} <!-- 直接拼接SQL关键字 --> ``` #### 三、安全性对比(SQL注入示例) ```xml <!-- 危险!传入 `name = "a&#39; OR &#39;1&#39;=&#39;1"` 会导致全部数据泄露 --> SELECT * FROM user WHERE name = &#39;${name}&#39; <!-- 安全!参数会被转义为: `a\&#39; OR \&#39;1\&#39;=\&#39;1` --> SELECT * FROM user WHERE name = #{name} ``` > 💡 **结论**:`${}`需要**严格校验输入**(如只允许枚举值),否则应避免使用[^4][^5]。 #### 四、性能影响 - `#{}` 生成的预编译语句可被**数据库缓存重用**,尤其在高并发时性能更优[^3] - `${}` 每次生成**全新SQL语句**,增加数据库解析开销 ### 最佳实践总结 1. **默认优先使用`#{}`**:适用于>95%的场景(值传递) 2. **谨慎使用`${}`**:仅用于**动态表名/列名、排序字段**等非值场景[^1][^4] 3. **防御措施**: - 对`${}`参数做**白名单校验**(如只允许特定字段名) - 避免直接拼接用户输入(如`ORDER BY ${userInput}`) ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值