var 在增强 for 中依据集合表达式静态类型推断循环变量，如 map.entryset() 推出 map.entry，但原始类型会导致裸类型陷阱；类型推断单向且不反向，集合泛型不明确时应显式声明类型。
直接用 var 替代循环变量的显式类型声明，能显著减少泛型嵌套带来的视觉噪音，但必须确保右侧集合类型足够明确，否则推断结果可能偏离预期。
增强 for 循环中 var 的类型推断规则
编译器不看循环体，只看 : map.entrySet() 或 : list 这类表达式的静态返回类型。比如 map.entrySet() 返回的是 Set<map.entry v>></map.entry>，所以 for (var e : map.entrySet()) 中的 e 类型就是 Map.Entry<k v></k> —— 注意：这里的 K 和 V 是真实泛型参数，不是 Object。
- 如果
map声明为Map<string integer></string>，那么e就是Map.Entry<string integer></string>，e.getKey()返回String，e.getValue()返回Integer - 如果
map是原始类型（如new HashMap()），e会被推断为Map.Entry（裸类型），此时e.getKey()返回Object，后续需强转 -
for (var item : list)同理：依赖list的实际泛型，而非item后续怎么用
常见错误：泛型擦除导致的 Object 陷阱
最常踩的坑是以为「用了 var 就能自动适配业务语义」，结果在 map.entrySet() 场景下，因 map 自身泛型缺失，导致循环变量退化为裸类型。
- 错误写法：
Map map = new HashMap(); for (var e : map.entrySet()) { e.getKey().toString(); }→e.getKey()是Object，IDE 可能不报错，但类型安全已丢失 - 正确写法：
Map<string user> userMap = new HashMap(); for (var e : userMap.entrySet()) { String key = e.getKey(); User u = e.getValue(); }</string> - 关键点：类型推断链条是单向的——从集合推变量，不会反向从
e.getKey()的使用倒推e的类型
什么时候不该用 var 在增强 for 中
当循环变量的类型无法从集合表达式一眼确认时，var 会把类型契约藏起来，反而增加理解成本。
- 集合来自方法调用且返回类型模糊，例如
for (var x : getRawList())，而getRawList()返回List（无泛型）或Object - 需要频繁调用子类特有方法，比如
for (var e : list) { e.someCustomMethod(); }，但list是List extends MyInterface>，此时e推断为MyInterface，无法访问实现类方法 - 团队代码规范明确要求循环变量显式声明（尤其在金融、医疗等强类型敏感场景）
真正省事的前提，是集合本身的泛型声明干净、完整。别指望 var 能补救上游类型信息的缺失；它只是把已有的类型契约从左边挪到右边，而人眼对右边的扫描习惯，远不如左边直观。
