${}与#{}的区别全解析

目前golang学习网上已经有很多关于文章的文章了，自己在初次阅读这些文章中，也见识到了很多学习思路；那么本文《#{} 与 ${} 的区别详解》，也希望能帮助到大家，如果阅读完后真的对你学习文章有帮助，欢迎动动手指，评论留言并分享~

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

#{} 和 ${} 在 MyBatis 中处理 SQL 参数的方式截然不同，核心区别在于 #{} 会进行预编译和参数绑定，从而有效防止 SQL 注入，而 ${} 则是直接的字符串替换，存在潜在的安全风险，但对于某些动态 SQL 结构又是不可或缺的。

解决方案

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

举个例子，如果你写：

SELECT * FROM users WHERE id = #{userId}

当 userId 的值为 123 时，实际发送给数据库的可能是一个预编译语句，类似 SELECT * FROM users WHERE id = ?，然后将 123 作为参数绑定到 ? 上。如果 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' 永远为真，这个查询就会返回所有用户的数据，绕过了密码验证。这简直是灾难。

但如果使用 #{}：

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。
• 避免直接拼接用户输入：永远不要让用户直接控制 ${} 中的内容。

这其实是个两难，你为了实现动态性而牺牲了安全性，所以在使用 ${} 的地方，务必加倍小心，将其视为潜在的安全热点，并进行额外的安全审查。

性能与可维护性考量：除了安全，还有什么不同？

除了最显著的安全差异，#{} 和 ${} 在性能和代码可维护性方面也存在不小的区别，这些都是我们在实际开发中需要深思熟虑的。

从性能上看，#{} 通常会带来更好的表现。由于它使用 PreparedStatement，数据库可以对预编译的 SQL 语句进行缓存。当相同的 SQL 模板被多次执行，只是参数不同时，数据库可以直接使用缓存的执行计划，省去了每次解析、编译 SQL 的开销。这对于高并发、频繁执行的查询来说，性能提升是相当可观的。而 ${} 每次都会生成一个全新的 SQL 字符串，数据库每次都需要重新解析和编译，这意味着每次执行都是一次“全新”的查询，无法享受到预编译带来的性能红利。

再聊聊可维护性。使用 #{} 的 SQL 语句通常更清晰、更易读。参数的占位符清晰地表明了哪些部分是动态数据，哪些是固定的 SQL 结构。这让其他开发者（包括未来的你）在阅读代码时，能一眼看出 SQL 的意图，也更容易进行调试。

反观 ${}，如果使用不当，或者动态拼接的逻辑过于复杂，生成的 SQL 语句可能会变得非常难以理解和调试。想象一下，一个复杂的条件查询，里面混杂了多个 ${}，再加上各种字符串拼接，最终生成的 SQL 语句可能面目全非，一旦出现问题，排查起来简直是噩梦。而且，#{} 还会自动处理参数的类型转换，你不需要担心字符串、数字、日期之间的转换问题；而 ${} 则需要你手动确保拼接进去的值是数据库能够接受的正确格式，否则很容易出现类型不匹配的错误。

所以，在选择使用哪种方式时，我们不仅要考虑眼前的功能实现，更要着眼于项目的长期健康发展，包括安全性、性能和未来的维护成本。在我看来，#{} 是默认且推荐的姿势，而 ${} 则是需要谨慎对待的“高级技巧”，用得好能解决特定问题，用不好则会埋下巨大的隐患。

到这里，我们也就讲完了《${}与#{}的区别全解析》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！