最新网站开发技术,如何写网站开发的分析,软件开发工作,js做网站登录框验证码在 MyBatis 中#xff0c;${} 和 #{} 是两种处理 SQL 参数的占位符#xff0c;它们在实现机制、安全性、使用场景上存在显著差异。以下是详细对比#xff1a;
核心区别对比
特性#{}${}底层机制预编译占位符#xff08;PreparedStatement#xff09;字符串直接替换安全性…在 MyBatis 中${} 和 #{} 是两种处理 SQL 参数的占位符它们在实现机制、安全性、使用场景上存在显著差异。以下是详细对比
核心区别对比
特性#{}${}底层机制预编译占位符PreparedStatement字符串直接替换安全性✅ 防止 SQL 注入❌ 存在 SQL 注入风险参数处理自动添加引号字符串/日期类型需手动添加引号否则语法错误性能较低预编译开销较高直接拼接 SQL适用场景动态参数值如 WHERE id ?动态 SQL 片段如表名、排序字段
机制详解 #{}预编译占位符 MyBatis 会将其解析为 JDBC 的?占位符通过PreparedStatement预编译 SQL。 参数值会被安全转义例如 SELECT * FROM users WHERE name #{name} -- 转换为SELECT * FROM users WHERE name ? 若name John实际执行时参数值会被安全绑定为John。 ${}字符串替换 直接替换为参数值的字面量无预编译或转义。 例如 SELECT * FROM users WHERE id ${id} -- 若 id1替换为SELECT * FROM users WHERE id 1 若id 1 OR 11则 SQL 会变为 SELECT * FROM users WHERE id 1 OR 11 -- 查询所有数据存在 SQL 注入风险[1,5](ref)
安全性问题 #{}天然防 SQL 注入适用于用户输入或外部参数。 ${}高风险仅适用于完全可控的静态值如内部生成的表名、列名。 错误示例模糊查询 SELECT * FROM products WHERE name LIKE %${keyword}% -- 若 keyword OR 11 --导致数据泄露
使用场景对比
✅ #{} 的适用场景 普通条件查询值动态传递 SELECT * FROM orders WHERE user_id #{userId} [1,4](ref) 日期/字符串参数自动添加引号 INSERT INTO logs (content) VALUES (#{logContent}) -- 自动转为 xxx [7,8](ref) 模糊查询安全写法 SELECT * FROM products WHERE name LIKE CONCAT(%, #{keyword}, %) [2,3](ref)
⚠️ ${} 的适用场景 动态表名/列名SQL 片段不可预编译 SELECT * FROM ${tableName} WHERE ${column} 1 [3,5,7](ref) 排序字段如ORDER BY ${sortField} SELECT * FROM users ORDER BY ${orderBy} DESC [3,7](ref) 批量操作如IN子句 DELETE FROM cart WHERE id IN (${ids}) -- ids1,2,3 [7](ref)
最佳实践与避坑指南 默认使用 #{}除非必须动态拼接 SQL 片段否则一律用#{}确保安全。 ${} 的防御措施 仅允许传入白名单值如预定义表名列表。 手动过滤危险字符如空格、分号。 模糊查询的替代方案 用CONCAT函数推荐 SELECT * FROM table WHERE name LIKE CONCAT(%, #{text}, %) 程序层拼接Java 中生成%text%再传入。 总结 #{} 安全优先处理动态值用户输入、条件参数预编译防注入。 ${} 谨慎使用处理动态 SQL 片段表名、排序需严格校验输入。 关键口诀**“值用井号#结构用刀$”——值动态用 #{}SQL 结构动态用 ${}。实际开发中95% 的场景应使用#{}仅在必要时如分表谨慎使用${}。
