var精简泛型的核心是聚焦用途而非类型，需右侧完整泛型参数、语义化变量名及明确推断上下文，避免隐性类型丢失与设计意图模糊。
用 var 精简冗长泛型声明，核心不是删类型，而是把注意力从“它是什么类型”转向“它用来做什么”。只要右侧初始化表达式足够明确，var 就能有效压低类型噪音，让代码更轻、意图更清。
只在右侧类型清晰且冗长时启用 var
泛型嵌套越深，左侧重复书写越干扰阅读。比如 Map<string list>>></string> 在声明和构造中各出现一次，纯属冗余。
- ✅ 推荐：
var userRolesByDepartment = new HashMap<string list>>>();</string> - ❌ 避免：
var cache = new HashMap();（泛型丢失，推断为原始类型，IDE 无法提示，编译器也失去检查能力） - ⚠️ 关键：右侧必须保留完整泛型参数——这是编译器推断的唯一依据，也是 IDE 提供准确补全的前提
用变量名补足语义，代替类型说明
var 不带类型信息，名字就得扛起表达职责。越复杂的泛型，越需要名字直指业务含义。
- ❌ 模糊：
var data = new ConcurrentHashMap<long list>>();</long>（data 是缓存？队列？临时结果？） - ✅ 清晰：
var pendingNotificationsByUserId = new ConcurrentHashMap<long list>>();</long>（线程安全 + 业务实体 + 键值含义全到位） - ? 小技巧：名字中可自然融入泛型关键特征，如
ByUserId、WithRetry、ForExport，比注释更可靠
流操作与链式调用中优先使用 var
一串 .stream().filter().map().collect() 后，目标类型往往由 Collectors 明确决定，显式写全类型反而打断逻辑流。
- ✅ 自然流畅：
var activeUsersById = users.stream().filter(User::isActive).collect(Collectors.toMap(User::getId, Function.identity())); - ✅ IDE 悬停即见
Map<long user></long>，无需中断阅读去确认类型 - ❌ 避免：
var result = service.fetchData();（方法返回类型不直观，推断结果对读者完全不可见）
警惕“省类型”换来的隐性代价
有些泛型看似啰嗦，实则承载关键约束。盲目用 var 可能掩盖设计意图，甚至埋下运行时隐患。
- ❌ 危险：
var numbers = Arrays.asList(1, 2, 3);→ 推断为List<integer></integer>，但后续若需add(null)或混入Long，问题延后暴露 - ✅ 更稳：
List<number> numbers = Arrays.<number>asList(1, 2L, 3.14);</number></number>（显式上界，约束更准） - ❌ try-with-resources 中勿省略资源类型：
var fis = new FileInputStream("x.txt");→ 关闭行为依赖具体类，类型模糊影响资源管理语义
