Java泛型类型推断在嵌套集合中需右侧写全泛型、变量名承载业务语义、避免var滥用；右侧缺泛型会退化为原始类型，多层嵌套时new HashMap<>()也不可靠，流式collect可用var但需确保Collectors明确类型。
Java 中泛型类型推断在复杂集合嵌套中正确使用的要点，不是为了少写几个字，而是让代码意图更清晰、维护更安全。关键在于：右侧初始化表达式必须完整携带泛型信息，变量名要承载业务语义，且避免在推断结果模糊时强行用 var。
右侧必须写全泛型参数，不能省略
编译器靠右侧构造器的泛型签名做推断，左侧用 var 时，右侧若缺泛型，就会退化为原始类型或错误上界。
- ✅ 正确：
var userRoles = new HashMap<Long, List<String>>();→ 推断为HashMap<Long, List<String>> - ❌ 错误：
var userRoles = new HashMap();→ 推断为原始HashMap，失去类型安全，IDE 无法提示 - ⚠️ 注意：
new HashMap<>()在var场景下也不推荐，因构造器本身未显式声明嵌套结构，推断可能不准确（尤其多层嵌套如Map<String, Set<List<Integer>>>）
变量名必须体现嵌套结构和业务含义
var 不提供类型文档，名字就是唯一上下文。越深的嵌套，越需要名字说明“装什么”“为什么装”。
- 避免：
var data = new ConcurrentHashMap<String, Map<Integer, Boolean>>();（data毫无信息量） - 推荐：
var featureFlagsByEnvironment = new ConcurrentHashMap<String, Map<Integer, Boolean>>(); - 再强化：
var pendingEmailsPerBatchId = new LinkedHashMap<Long, List<EmailRequest>>();（含顺序语义 + 业务动作）
流式操作后优先用 var，但 collect 必须明确
Stream 管线的终点由 Collectors 决定类型，此时显式写出目标类型反而干扰阅读。
立即学习“Java免费学习笔记（深入）”；
- ✅ 清晰：
var activeUserGroups = users.stream().filter(User::isActive).collect(Collectors.groupingBy(User::getDepartment));→ IDE 悬停即见Map<String, List<User>> - ⚠️ 风险：
var result = service.fetchAll();→ 方法签名不暴露返回结构，var后完全不可知嵌套层级 - ? 提示：若 collect 使用自定义 collector 或泛型较隐晦（如
toConcurrentMap），建议显式声明类型或加注释
警惕三类不该用 var 的嵌套场景
有些嵌套看似冗长，但去掉类型会掩盖关键约束，导致后期 bug 难定位。
-
需精确控制通配符边界时：如
List<? extends Number>不能用var numbers = Arrays.asList(1, 2.0);（推断为List<Serializable>），应写List<Number> numbers = Arrays.<Number>asList(1, 2.0); -
资源类参与 try-with-resources 时：如
var reader = new BufferedReader(...);无法保证AutoCloseable具体实现是否支持所需关闭逻辑，应显式声明BufferedReader reader = ... -
空初始化或延迟赋值时：如
var cache;编译失败；var cache; cache = new HashMap<>();仍失败 ——var要求声明即初始化，且右侧可推断
