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() 可能抛出 NPE
• 如果业务允许空集合时查询全表，需要额外增加 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 异常，而非编译期被捕获。因此，测试阶段必须覆盖各种边界情况。