MyBatis中井号大括号和美元大括号哪个更能有效预防SQL注入风险

✅ #{ } 是唯一能防 SQL 注入的写法：它通过 JDBC PreparedStatement 将参数作为独立数据绑定，数据库仅将其视为字符串值；❌ ${ } 是纯字符串拼接，无任何防护，直接将用户输入嵌入 SQL，极易引发注入攻击。

#{ } 是唯一能防 SQL 注入的写法

MyBatis 中只有 #{} 能真正防御 SQL 注入，${} 本身不提供任何防护机制——它就是字符串拼接，传什么就拼什么。数据库看到的不是参数，而是你拼出来的完整 SQL 文本。哪怕只漏校验一个字段，攻击者就能用 ' OR '1'='1 或 ; DROP TABLE user; -- 直接执行任意语句。

为什么 #{ } 能拦住恶意输入？

因为 #{} 触发的是 JDBC 的 PreparedStatement 流程：

• MyBatis 把 #{id} 替换成 ? 占位符，SQL 发给数据库时是固定结构，比如 SELECT * FROM user WHERE id = ?
• 参数值通过 setLong(1, id) 或 setString(1, value) 单独绑定，数据库只把它当「数据」处理，不会解析为语法
• 即使传入 "1; DROP TABLE user; --"，最终执行的也只是 WHERE id = '1; DROP TABLE user; --' —— 一条查不到结果的普通查询

哪些地方非得用 ${ }？

${} 不是“可以不用”，而是 JDBC 层面不允许用 #{} 的硬性场景：

• 表名：SELECT * FROM ${tableName} —— #{tableName} 会加单引号变成 FROM 'user'，直接报错
• 列名或排序字段：ORDER BY ${column} ${orderType} —— #{orderType} 会变成 ORDER BY name 'ASC'，语法错误
• GROUP BY、LIMIT 偏移量等无法加引号的语法位置

这些地方用 ${} 不是图省事，是没得选。

用 ${ } 时最容易忽略的安全动作

很多人以为“加个正则”或“限制长度”就够了，其实远远不够：

• 白名单必须硬编码：比如排序字段只允许 Set.of("id", "name", "created_at")，前端传 sort=user_name，后端映射成真实列名 "name"
• 表名需双重校验：先匹配正则 ^[a-zA-Z][a-zA-Z0-9_]{2,31}$，再查数据库元信息确认该表真实存在
• 绝对禁止用户直传字段名/表名：所有动态片段都应来自配置或枚举，而不是前端 raw input

没走这几步，${column} 和裸写 Statement 没本质区别。