#{} 和 ${} 在 MyBatis 中有什么区别？-java教程-PHP中文网

#{} 和 ${} 在 MyBatis 中有什么区别？

夜晨

发布： 2025-09-03 15:09:01

原创

925人浏览过

答案：#{}通过预编译防止SQL注入，安全且性能好，应优先使用；${}为字符串替换，存在注入风险，仅用于动态表名列名等必要场景。

#{} 和 ${} 在 mybatis 中有什么区别？

#{}

登录后复制

和

${}

登录后复制

在 MyBatis 中处理 SQL 参数的方式截然不同，核心区别在于

#{}

登录后复制

会进行预编译和参数绑定，从而有效防止 SQL 注入，而

${}

登录后复制

则是直接的字符串替换，存在潜在的安全风险，但对于某些动态 SQL 结构又是不可或缺的。

解决方案

在 MyBatis 中，

#{}

登录后复制

语法用于将参数值作为 JDBC

PreparedStatement

登录后复制

的参数进行设置。这意味着 MyBatis 会在执行 SQL 语句前，先将 SQL 模板发送到数据库进行编译，然后将参数值安全地绑定到预留的位置上。这个过程会自动处理参数的类型转换和转义，极大地增强了安全性，有效杜绝了 SQL 注入攻击。

举个例子，如果你写：

SELECT * FROM users WHERE id = #{userId}

登录后复制

当

userId

登录后复制

的值为

登录后复制

时，实际发送给数据库的可能是一个预编译语句，类似

SELECT * FROM users WHERE id = ?

登录后复制

，然后将

登录后复制

作为参数绑定到

登录后复制

上。如果

userId

登录后复制

的值为

1 OR 1=1

登录后复制

，它也会被当作一个普通的字符串值来处理，而不是作为 SQL 逻辑的一部分。

而

${}

登录后复制

语法则是将参数值直接拼接到 SQL 字符串中。它不会进行预编译和参数绑定，而是简单地将变量的值替换到 SQL 语句中。这意味着，如果参数值包含恶意 SQL 代码，这些代码就会直接成为最终执行的 SQL 语句的一部分，从而引发 SQL 注入漏洞。

例如，如果你写：

SELECT * FROM users ORDER BY ${columnName}

登录后复制

当

columnName

登录后复制

的值为

user_name

登录后复制

时，最终执行的 SQL 是

SELECT * FROM users ORDER BY user_name

登录后复制

。但如果

columnName

登录后复制

的值是

user_name; DROP TABLE users;

登录后复制

，那么整个 SQL 语句就会变成

SELECT * FROM users ORDER BY user_name; DROP TABLE users;

登录后复制

，后果不堪设想。

因此，我的个人建议是，除非你非常清楚自己在做什么，并且已经采取了严格的输入验证和白名单机制，否则，在任何需要传递用户输入数据的地方，都应该优先使用

#{}

登录后复制

。

${}

登录后复制

的使用场景非常有限，通常只在需要动态拼接表名、列名或者

ORDER BY

登录后复制

子句等 SQL 结构本身时才考虑。

SQL 注入的风险与防范：为什么选择 #{}？

在我看来，SQL 注入是后端开发中最常见的，也是最危险的安全漏洞之一。它就像是数据库的大门，如果你不加防范，攻击者就能通过这个漏洞，像开锁一样，随意进出你的数据宝库，轻则数据泄露，重则数据被篡改甚至删除。选择

#{}

登录后复制

，很大程度上就是为了关上这扇门。

#{}

登录后复制

之所以能防范 SQL 注入，关键在于它的工作机制。当 MyBatis 遇到

#{}

登录后复制

占位符时，它会告诉 JDBC 驱动：“嘿，这里有个参数，别把它当成 SQL 语句的一部分，把它当作一个普通的值来处理。” 数据库接收到这样的指令后，就会严格区分 SQL 语句的结构和参数数据。哪怕你的参数值里包含了

OR 1=1

登录后复制

这样的 SQL 关键字，数据库也只会把它当作一个普通的字符串，而不是额外的条件或命令。

想象一下，你有一个登录接口，用户输入用户名和密码。如果你的 SQL 是这样写的：

SELECT * FROM users WHERE username = '${username}' AND password = '${password}'

登录后复制

一个恶意用户在用户名输入框里填入

' OR '1'='1

登录后复制

，密码随便填。那么最终的 SQL 就会变成：

SELECT * FROM users WHERE username = '' OR '1'='1' AND password = '随便填'

登录后复制

因为

OR '1'='1'

登录后复制

永远为真，这个查询就会返回所有用户的数据，绕过了密码验证。这简直是灾难。

但如果使用

#{}

登录后复制

：

稿定AI社区

在线AI创意灵感社区

查看详情

SELECT * FROM users WHERE username = #{username} AND password = #{password}

登录后复制

即使恶意用户输入同样的内容，数据库也会将其视为字面量字符串，比如

username = '' OR '1'='1'

登录后复制

会被当成一个整体的用户名字符串去匹配，自然找不到对应用户，从而避免了注入。所以，从安全角度出发，

#{}

登录后复制

几乎是默认且必须的选择。

何时必须使用 ${}：动态SQL的边界与挑战

编程世界里哪有绝对的非黑即白呢？虽然

#{}

登录后复制

是安全的首选，但总有些场景是它力所不能及的，这时候

${}

登录后复制

就不得不登场了。这些场景通常涉及到 SQL 语句的结构本身需要动态变化，而不是仅仅参数值变化。

最典型的例子就是动态的表名、列名，以及

ORDER BY

登录后复制

子句。比如说，你的系统可能需要根据不同的业务场景查询不同的日志表（

log_2023

登录后复制

、

log_2024

登录后复制

），或者用户可以自定义报表显示的列和排序方式。

假设你需要根据用户选择的列进行排序：

<!-- 错误且危险的写法，但演示了需求 -->
SELECT * FROM products ORDER BY ${sortByColumn} ${sortOrder}

登录后复制

这里

sortByColumn

登录后复制

可能是

price

登录后复制

或

name

登录后复制

，

sortOrder

登录后复制

可能是

ASC

登录后复制

或

DESC

登录后复制

。

#{}

登录后复制

无法直接替换 SQL 关键字或标识符，因为它们是 SQL 结构的一部分，而不是数据。如果你尝试用

#{}

登录后复制

来替换

columnName

登录后复制

，MyBatis 会把

columnName

登录后复制

当成一个字符串值，并在其两边加上引号，导致 SQL 语法错误，比如

ORDER BY 'price'

登录后复制

，这显然不是我们想要的。

所以，在这种情况下，使用

${}

登录后复制

是唯一的选择。但这也带来了巨大的挑战：你必须自己承担起参数的验证和过滤责任。这意味着，你不能直接把用户输入的任何字符串扔进

${}

登录后复制

。你需要在代码层面，对

sortByColumn

登录后复制

和

sortOrder

登录后复制

进行严格的校验，比如：

白名单机制：只允许预定义的一组安全值通过。例如，
```
sortByColumn
```
登录后复制
只能是
```
id
```
登录后复制
,
```
name
```
登录后复制
,
```
price
```
登录后复制
中的一个；
```
sortOrder
```
登录后复制
只能是
```
ASC
```
登录后复制
或
```
DESC
```
登录后复制
。
避免直接拼接用户输入：永远不要让用户直接控制
```
${}
```
登录后复制
中的内容。