Java面试之MyBatis中#{}和${}的区别-Java面试题-PHP中文网

{}能防SQL注入因其触发PreparedStatement预编译，参数安全绑定；${}是字符串拼接，直接替换导致注入。仅当动态SQL结构（如表名、排序字段）必须用${}，须白名单校验或正则过滤。

java面试之mybatis中#{}和${}的区别

为什么#{}能防SQL注入而${}不能

根本原因在于 MyBatis 对两者的处理时机和方式完全不同：#{} 触发预编译（PreparedStatement），参数被当作占位符传入，数据库驱动自动做类型转换和转义；${} 是纯字符串替换，MyBatis 在 SQL 解析阶段就直接把变量值拼进 SQL 字符串里，不经过 JDBC 预编译流程。

比如传入用户名 "admin' OR '1'='1"：

WHERE username = #{username} → 最终执行的是 WHERE username = ?，参数以安全方式绑定，不会改变 SQL 结构
WHERE username = '${username}' → 直接变成 WHERE username = 'admin' OR '1'='1'，语句逻辑已被篡改

什么场景必须用${}，以及怎么降低风险

${} 唯一合理用途是动态拼接 **SQL 结构部分**，比如表名、字段名、ORDER BY 子句、UNION 查询等——这些无法用 #{} 替代，因为 PreparedStatement 不允许对表名或关键字做参数化。

使用时必须严格校验输入，常见做法：

只接受白名单枚举值，例如排序字段限定为 "id"、"create_time"、"status"
用正则过滤：仅允许字母、数字、下划线，且长度限制在 32 字以内
避免从用户请求中直接取值，优先通过接口参数映射到内部枚举或配置项

错误示例：

SELECT * FROM ${tableName} WHERE id = #{id}

—— 若 tableName 来自 HTTP 参数且未校验，可导致库表遍历攻击。

ORDER BY 中用${}的典型写法与陷阱

这是最常踩坑的地方。很多人写成：ORDER BY ${sortField} ${sortOrder}，但若 sortOrder 是用户传的 "ASC; DROP TABLE user;"，就可能触发多语句执行（取决于数据库是否开启 allowMultiQueries）。

JavaScript 测试模式

使用 Jest、Vitest 和 Testing Library 实施全面的测试策略，包括单元测试、集成测试和端到端测试，涵盖模拟、测试夹具和测试驱动开发。在编

下载

安全做法是分别约束两个变量：

sortField：匹配 ^[a-zA-Z_][a-zA-Z0-9_]{0,31}$
sortOrder：只允许 "ASC" 或 "DESC"（建议转大写后比对）

推荐写法：

<if test="sortField != null and sortField != ''">
  ORDER BY ${sortField}
  <choose><when test="sortOrder == 'DESC'">DESC</when><otherwise>ASC</otherwise></choose></if>

性能与日志表现差异

虽然不影响功能，但会影响排查效率：#{} 在 MyBatis 日志中显示为带问号的 SQL（如 SELECT * FROM user WHERE id = ?），真实参数单独打印；${} 则直接显示拼接后的完整 SQL（如 SELECT * FROM user_log WHERE type = 'login'）。

这意味着：