【MyBatis】参数占位符 #{} 和 ${}

假如现在我们有一个需求是根据用户的id来查询用户的详细信息。

Controller 实现代码如下:

Service层的实现类代码如下:

mapper层接口和XML文件如下:

 代码中使用到的#{}实际上就是对SQL语句进行预编译处理,会将#{}替换为?号,使用PreparedStatement的set方法来赋值。select * from userinfo where id=#{id} 也可以用select * from userinfo where id=${id}来代替,他们都可以完成现在的需求。

问题来了既然他们这么相似、那为什么还要有这两个东西??两者之间肯定是有区别的。

主要区别

先直接将他们之间的核心区别,然后通过例子演示。

1. #{} 解析为一个 JDBC 预编译语句(prepared statement)的参数标记符,一个 #{ } 被解析为一个参数占位符(?);而${}仅仅为一个纯碎的字符替换是MyBatis 在处理 ${} 时,就是把 ${} 替换成变量的值。

2. #{} 很大程度上可以防止SQL注入(SQL注入是发生在编译的过程中,因为恶意注入了某些特殊字符,最后被编译成了恶意的执行操作);而${} 主要用于SQL拼接的时候,有很大的SQL注入隐患。

3.在某些特殊场合下只能用${},不能用#{}。例如:在使用排序时ORDER BY ${id},如果使用#{id},则会被解析成ORDER BY “id”,这显然是一种错误的写法。这也对应了第二点的说法,排序功能, 表名, 字段名作为参数时, 这些情况需要使⽤${}

4.模糊查询虽然${}可以完成, 但因为存在SQL注⼊的问题,所以通常使⽤mysql内置函数concat来完成

1.1 SQL注入

SQL注⼊:是通过操作输⼊的数据来修改事先定义好的SQL语句,以达到执⾏代码对服务器进⾏攻击的方法。
比如现在有一个登录的需求。实现的代码如下:

控制层:

服务层:

 DAO层:( 使用${ } )

 List<User> queryUserByPassword(@Param("username") String username, @Param("password") String password);
}

数据库现有数据:

 知道账号密码 登录 张三账号:

 现在我们即使不输正确的密码也可以登录!!!!下图中可以看到,后端返回的结果是true!

 这是因为,通过拼接后最终执行的代码是:

 如果我们使用#{}:

再看一下执行结果:此时后端返回的就是false,这就是他们的第一个和第二个区别的展示。

 1.2 排序功能

从上⾯的例⼦中, 可以得出结论: ${} 会有SQL注⼊的⻛险, 所以我们尽量使⽤#{}完成查询 既然如此, 是不是 ${} 就没有存在的必要性了呢?
当然不是.
如果我们想要对查询的结果按照某个字段排序呢?我么知道排序通过 ORDER BY 关键字按照一个或多个列的值对结果集进行升序(ASC)或降序(DESC)排列。我们在传入的EDSC是字符串啊!
当使⽤ #{sort} 查询时,如果传递的值为 String 则会加单引号,就会导致 sql 错误。

这时候就需要使用${}:

1.3 模糊查询

比如我们对用户信息进行查询,并且要求实现模糊查询功能。由于我们使用模糊查询的时候需要使用到'%#{username}%这也是字符串啊!!如果我们使用#{}的话:
 

 <select id="findUserByName2" resultType="com.example.demo.entity.User">
 select * from userinfo where username like '%#{username}%';
 </select>
相当于: select * from userinfo where username like '%'username'%'; 可见这肯定是一段不可以成功执行的SQL查询语句。
这时候就有需要使用到${}了:
<select id="likeSelect" resultType="com.example.demo.entity.User">
    select * from userinfo where username like '%${username}%'
</select>

但是,一般还是推荐使用下面的方式来实现模糊查询:使⽤ mysql 的内置函数 concat()  + #{}来处理,实现代码如下:

<select id="findUserByName3" resultType="com.example.demo.entity.User">
 select * from userinfo where username like concat('%',#{username},'%');
</select>

 contat将传入的参数和%拼接在一起,这样就是一个nice的sql语句了。这种方式可以有效地防止SQL注入,也是推荐使用的方式。


总结

1. #{} 解析为一个 JDBC 预编译语句(prepared statement)的参数标记符,一个 #{ } 被解析为一个参数占位符(?);而${}仅仅为一个纯碎的字符替换是MyBatis 在处理 ${} 时,就是把 ${} 替换成变量的值。

2. #{} 很大程度上可以防止SQL注入(SQL注入是发生在编译的过程中,因为恶意注入了某些特殊字符,最后被编译成了恶意的执行操作);而${} 主要用于SQL拼接的时候,有很大的SQL注入隐患。

3.在某些特殊场合下只能用${},不能用#{}。例如:在使用排序时ORDER BY ${id},如果使用#{id},则会被解析成ORDER BY “id”,这显然是一种错误的写法。这也对应了第二点的说法,排序功能, 表名, 字段名作为参数时, 这些情况需要使⽤${}

4.模糊查询虽然${}可以完成, 但因为存在SQL注⼊的问题,所以通常使⽤mysql内置函数concat来完成

### MyBatis 中 `#` `$` 占位符的区别 #### 1. 工作原理差异 在 MyBatis 中,`#` `$` 都是用来在 SQL 语句中插入参数占位符,但两者的工作原理不同。 对于 `#` 占位符而言,它会将传入的数据都当成字符串来处理,并自动加上单引号。这种方式可以有效防止 SQL 注入攻击[^1]。例如: ```sql SELECT * FROM users WHERE id = #{userId} ``` 而 `$` 占位符则不会对数据做任何特殊处理,而是直接将其作为原生字符串拼接到 SQL 语句中。这意味着如果输入未经严格校验,则可能存在安全风险[^3]。比如: ```sql SELECT * FROM users WHERE username LIKE &#39;%${username}%&#39; ``` #### 2. 应用场景对比 由于上述特性上的差别,这两种占位符适用于不同的场合。 当需要确保安全性并希望让 JDBC 自动处理类型转换时,应该优先考虑使用 `#` 占位符。这通常是在构建查询条件、更新操作等情况下非常适用的选择[^2]。 相反,若确实有必要动态地改变表名或列名等情况(尽管这种情况较为少见),那么此时可以选择使用 `$` 来实现更灵活的功能需求[^4]。不过需要注意的是,在这种情形下务必谨慎对待用户输入的内容,以免引发潜在的安全隐患。 #### 3. 实际应用案例展示 下面通过具体的例子进一步说明两者的区别及其应用场景: ##### 使用 `#` 的情况 假设有一个简单的查询请求,目的是获取指定 ID 的用户信息: ```xml <select id="getUserById" parameterType="int" resultType="User"> SELECT * FROM users WHERE id = #{id}; </select> ``` 这里采用 `#` 方式传递参数,既简单又安全可靠。 ##### 使用 `$` 的情况 再来看另一个复杂一点的例子——分页查询功能实现: ```xml <select id="getUsersByPage" parameterType="map" resultType="User"> SELECT * FROM users LIMIT ${offset},${limit}; </select> ``` 在这个场景里选择了 `${}` 形式的变量替换是因为 MySQL 的 `LIMIT` 子句不允许使用预编译参数形式(`?`)来进行偏移量数量设置;因此只能借助于 `${}` 进行动态注入。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

小小小小关同学

你的支持就是我的动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值