字符串拼接SQL等同于把枪交给攻击者，因用户输入与SQL模板在应用层合并为完整语句，数据库无法区分代码与数据；参数化（如PreparedStatement、MyBatis的#{}）将结构与参数分离，从根本上阻断SQL注入。
直接拼装 SQL 字符串（比如用 +、format()、StringBuilder 或 MyBatis 的 ${}）会让用户输入混入 SQL 语法结构，数据库无法区分“代码”和“数据”，一旦输入含 '、or 1=1、-- 等内容，就可能被当作语句执行——这是注入漏洞的根源。转用数据库驱动原生参数化接口（如 JDBC 的 PreparedStatement、MyBatis 的 #{}）能从根本上切断这种混淆。
为什么字符串拼接等同于把枪交给攻击者
拼接时，你写的 SQL 模板和用户输入在应用层就合并成一条完整字符串，再发给数据库。数据库收到的已经是“成品”，它不会重新解析哪些是字段名、哪些是值，只按语法执行。例如：
String sql = "SELECT * FROM user WHERE name = '" + userName + "'";
当 userName = "admin' --" 时，最终执行的是：
SELECT * FROM user WHERE name = 'admin' --'
注释符 -- 后的内容被忽略，登录校验逻辑直接绕过。
- 所有拼接方式（
+、String.format、StringBuilder.append、${}）本质相同，都发生在应用内存中 - 即使做了
replaceAll("'", "''")这类简单过滤，也极易被绕过（如用/**/注释、编码、大小写混用） - MySQL 5.7+ 支持多语句执行（
allowMultiQueries=true），拼接还可能触发堆叠注入
PreparedStatement 是怎么做到安全的
PreparedStatement 把 SQL 结构和参数分离：先传语句模板（带 ? 占位符）给数据库预编译，生成执行计划；再单独传参数值，由驱动按类型绑定（如 setString(1, value)）。数据库全程知道“这个 ? 是字符串值，不是字段名，更不是子查询”。
- 参数值永远不会参与语法解析，即使含
;、UNION、SELECT也仅被视为普通字符串 - 不同数据库驱动对
setXxx()方法做了底层适配（如 Oracle 绑定DATE类型会自动格式化） - MyBatis 的
#{}底层就是调用PreparedStatement.setString()等方法，不是字符串替换
哪些地方容易误用拼接而漏掉参数化
开发者常因“#{} 不好使”就退回到 ${} 或手动拼接，但多数情况其实是没理解限制条件或没找对解法。
-
表名/列名/排序方向：如
ORDER BY ${sortField} ${sortOrder}—— 这些属于 SQL 关键字，不能加引号，#{}会强制加引号导致语法错误；必须白名单校验后拼接，不可直接透传前端参数 -
IN 子句动态长度：如
WHERE id IN (#{id1}, #{id2})写死占位符不现实；应改用<foreach></foreach>标签生成多个?，或用临时表/数组参数（PostgreSQL 支持WHERE id = ANY(?)） -
JDBC 工具脚本：运维用的
DataMerge.java等脚本若仍用Statement.execute(sql)，极易引入高危路径；应统一迁至PreparedStatement+ 参数绑定
MyBatis 中 ${} 的 3 种合法场景及防护姿势
${} 不是原罪，问题在于是否可控。它只应在完全可信、不可被用户影响的上下文中使用。
-
分表名：如
user_${dateSuffix}，其中dateSuffix来自服务端计算（LocalDateTime.now().format("yyyyMM")），非请求参数 -
固定枚举字段：如排序字段限定为
"create_time"、"status"，用Enum.valueOf()转换后拼接，非法值直接抛异常 -
数据库关键字：如 MySQL 的
LOCK IN SHARE MODE，整个片段写死在 XML 中，不接受任何外部输入
只要涉及任何用户可控输入（URL 参数、Body JSON、Header 值），${} 就必须拒绝——哪怕加了正则校验，也比不上参数化来的彻底。最危险的不是不懂原理，而是以为“我过滤过了所以安全”。
