MyBatis 的 foreach 标签本身不防注入，真正防注入的是坚持使用 #{item} 而非 ${item}；空集合或 null 必须用 <if> 包裹，collection 值需严格匹配参数命名与包装方式。
foreach 本身不防注入，防注入靠的是 #{}
MyBatis 的 foreach 标签本身不是“防注入工具”，它只是一个动态 SQL 遍历语法糖。真正防止 SQL 注入的，是你在 foreach 内部是否坚持用 #{item}——而不是 ${item} 或字符串拼接。
常见错误是以为用了 foreach 就安全了，结果写成：<foreach collection="ids" item="id">#{id} OR id = ${id}</foreach>，后半句 ${id} 直接把用户输入拼进 SQL，立刻引入注入风险。
-
foreach只负责把集合展开成多个#{}占位符，底层仍是 PreparedStatement 批量绑定 - 一旦混用
${}，哪怕只在一个#{}旁边加一个${item}，整条 SQL 就失去防护 - 传入的集合元素如果是用户可控字符串（比如前端传来的
String[] keywords），必须确保每个元素都走#{}，不能“信任”集合内容已清洗
collection 和 item 配错会导致 SQL 错误，但不等于注入
配错 collection 或 item 名，最常表现为 BindingException: Parameter 'xxx' not found 或生成空的 IN ()，这类问题会报错或查不到数据，但不会导致注入——因为根本没生成有效 SQL，更谈不上执行恶意语句。
典型翻车点：
- 接口方法参数是
@Param("userIds") List<Long> ids，XML 却写collection="list"→ 找不到list，foreach不执行 -
item="uid"，但内部写#{userId}→ OGNL 找不到属性，抛BindingException - 传入
List<String>，却在#{uid.name}访问属性 → 运行时报ognl.MethodFailedException
空集合或 null 必须用 <if> 包裹，否则语法出错
foreach 遇到 null 或空集合时，什么也不输出。这会导致 SQL 语法断裂，比如 WHERE id IN 后面直接接 AND status = 1，数据库报错 SQLSyntaxErrorException。这不是注入，但会让查询崩掉。
正确写法是用 <if> 显式兜底：
<where>
<if test="ids != null and !ids.isEmpty()">
id IN <foreach collection="ids" item="id" open="(" separator="," close=")">#{id}</foreach>
</if>
<if test="status != null">AND status = #{status}</if>
</where>
- 不要依赖
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<Long>参数，没加@Param→collection="list" - 单个
Long[]参数，没加@Param→collection="array" -
@Param("ids") List<Long> ids→collection="ids" - 传入 Map：
map.put("orderIds", list)→collection="orderIds" - 传入对象
UserQuery query，其中query.getIds()返回List<Long>→collection="ids"（取 getter 名，去掉get和首字母小写）
最容易被忽略的是：泛型擦除后，MyBatis 看不到 List<String> 和 List<Long> 的区别，全靠你传参时类型一致、XML 里 #{} 用对——否则运行时报 OGNL 异常，不是编译期错误。
