MyBatis 3.x中动态SQL的foreach标签防止SQL注入的实用方法与技巧

首先明确一个关键误区：MyBatis 的 foreach 标签本身并不具备防注入能力，真正起到防护作用的是你坚持使用 #{item} 而非 ${item}。此外，空集合或 null 必须通过 包裹处理，collection 的取值也需严格匹配参数的命名与包装方式——否则可能引发语法错误，或者悄无声息地导致数据遗漏。

foreach 本身不防注入，防注入靠的是 #{}

许多开发者误以为使用了 foreach 就高枕无忧，实际上它只是动态 SQL 的遍历语法糖。真正防止 SQL 注入的关键，在于 foreach 内部是否老老实实使用 #{item}——而不是图省事采用 ${item} 或手动拼接字符串。

常见错误示例：认为 foreach 自带安全光环，结果写成 #{id} OR id = ${id}。后半句 ${id} 直接把用户输入拼入 SQL，瞬间突破防线，注入风险极大。

• foreach 仅负责将集合展开为多个 #{} 占位符，底层仍依赖 PreparedStatement 批量绑定机制
• 一旦混用 ${}，哪怕只在一个 #{} 旁添加一个 ${item}，整条 SQL 的安全防线便会瞬间瓦解
• 若传入的集合元素为用户可控的字符串（如前端的 String[] keywords），必须确保每个元素均通过 #{} 绑定，切勿轻信集合内容已被清洗

collection 和 item 配错会导致 SQL 错误，但不等于注入

配错 collection 或 item 的名称时，常见表现是 BindingException: Parameter 'xxx' not found，或者生成一个空的 IN ()。这类错误会直接抛出异常或导致查询无结果，但不会引发注入——因为根本没有生成有效的 SQL，更谈不上执行恶意语句。这可谓不幸中的万幸。

典型翻车现场：

• 接口方法参数使用 @Param("userIds") List ids，XML 中却写 collection="list" → 找不到 list，foreach 直接罢工
• item="uid"，但内部用 #{userId} → OGNL 找不到属性，抛出 BindingException
• 传入 List，却在 #{uid.name} 访问属性 → 运行时报 ognl.MethodFailedException

空集合或 null 必须用 包裹，否则语法出错

foreach 遇到 null 或空集合时，不会输出任何内容。这会导致 SQL 语法断裂——例如 WHERE id IN 后面直接跟着 AND status = 1，数据库立刻报 SQLSyntaxErrorException。这虽然不是注入问题，但会让查询直接崩溃。

正确做法是显式使用 兜底：

  
    id IN #{id}
  
  AND status = #{status}

• 切勿认为 foreach 具备空判断逻辑——它完全没有
• test="ids != null and !ids.isEmpty()" 中的 !ids.isEmpty() 不能简写为 ids.size() > 0，MyBatis 的 OGNL 对空集合调用 size() 可能抛出 NullPointerException
• 若业务允许空集合查询全表，需额外添加 OR 1=1 分支，但务必谨慎评估权限与性能影响

数组、Map、对象列表的 collection 值怎么写才不翻车

collection 的值并非凭借经验猜测，它严格对应 Java 方法的签名和参数的包装方式。写错了就会找不到集合，foreach 彻底失效。

• 单个 List 参数，未加 @Param → collection="list"
• 单个 Long[] 参数，未加 @Param → collection="array"
• @Param("ids") List ids → collection="ids"
• 传入 Map：map.put("orderIds", list) → collection="orderIds"
• 传入对象 UserQuery query，其中 query.getIds() 返回 List → collection="ids"（取 getter 名，去掉 get 并首字母小写）

最易被忽视的是：泛型擦除后，MyBatis 无法区分 List 和 List，全靠传参时类型一致以及 XML 中 #{} 正确使用——否则运行时会抛出 OGNL 异常，而非编译期发现。因此测试阶段务必覆盖各种边界情况。