选型需兼顾安全性、性能与场景：需边遍历边删除时必须用显式iterator；arraylist优先普通for，linkedlist必须用iterator或增强for；增强for适合只读场景，简洁健壮；大数据量须实测验证。
选型不能只看语法顺不顺眼，得结合集合类型、操作需求和性能表现来定。核心就三点：能不能删元素、集合底层是啥结构、数据量大不大。
需要边遍历边安全删除时，必须用显式 Iterator
增强 for 循环里调用 list.remove() 会直接抛 ConcurrentModificationException——它底层就是 Iterator，但屏蔽了 remove() 接口。只有显式拿到 Iterator 实例，才能在 next() 后调用 iterator.remove()，这个操作会同步更新内部游标和修改计数（modCount），避开异常。
- 正确写法：用 iterator.hasNext() 判断，iterator.next() 取值，iterator.remove() 删除当前项
- 错误写法：在增强 for 中写 list.remove(x)，哪怕删的是前一个元素也不行
- 注意：remove() 必须紧跟在 next() 之后，且每调一次 next() 最多调一次 remove()
按集合类型选效率最优的遍历方式
ArrayList 和 LinkedList 的底层差异极大，遍历方式选错，性能可能差一个数量级。
- ArrayList（数组实现）：索引访问 O(1)，普通 for 循环最快；增强 for 和 Iterator 底层走的也是迭代器，有少量封装开销，比 for 慢 5–10%
- LinkedList（链表实现）：get(i) 是 O(n) 操作，普通 for 循环实际是 O(n²)；Iterator 和增强 for 是顺序推进，每次 next() 是 O(1)，快 10 倍以上
- HashSet / TreeSet 等非随机访问集合：没有索引概念，三种方式都走迭代器，性能基本一致；推荐增强 for，简洁不易出错
增强 for 循环适合“只读”场景，且代码更健壮
它本质是 Iterator 的语法糖，编译后字节码完全一样，但隐藏了 hasNext()/next() 细节，减少手误风险。
- 优势：语义清晰、不易漏判边界、自动 fail-fast（集合被意外并发修改时立刻报错）
- 限制：无法获取当前索引、不能中途修改集合结构（增/删）、不支持反向遍历
- 适用：日志打印、字段校验、DTO 转换等纯读取逻辑，尤其是集合类型不确定时（比如方法参数是 List>）
小数据量可忽略差异，大数据量要实测验证
万级以内元素，三种方式耗时差异通常在毫秒级，对业务影响微乎其微；但若处理十万级以上 ArrayList 或频繁遍历 LinkedList，性能差距就会明显暴露。
- 建议：在关键路径上，用 JMH 做基准测试，固定 JVM 参数、预热轮次、多轮采样
- 警惕误区：别因“Iterator 更正规”就统一用它，也别因“for 看着快”就在 LinkedList 上硬套
- 真实项目中，优先保障逻辑正确性——能安全删就用 Iterator，只读且类型明确就用增强 for，确定是 ArrayList 且热点路径才考虑普通 for
