应显式声明泛型并用接口类型引用实例，如Map<String, User> userMap = new HashMap<>();避免原始类型和具体实现类声明，禁用Object等宽泛类型，慎用通配符，null值宜用Optional包装，优先用containsKey判断存在性。
规范键和值的类型，核心是**显式声明泛型参数，并用接口类型引用实例**。不写泛型或用原始类型（如 HashMap）虽能编译，但会失去编译期类型检查，容易在运行时因类型擦除引发 ClassCastException，尤其在取值后强制转型时。
用 Map 接口声明，而非 HashMap 类名
声明变量时优先使用 Map<K, V> 接口类型，而不是具体实现类：
- ✅ 推荐：
Map<String, User> userMap = new HashMap<>(); - ❌ 避免：
HashMap<String, User> userMap = new HashMap<>();或更糟的HashMap userMap = new HashMap();
这样做的好处：后续可无缝切换为 LinkedHashMap、ConcurrentHashMap 等，无需修改调用方代码；也符合面向接口编程原则。
键和值类型要具体、不可太宽泛
避免用 Object、Serializable 或泛型通配符（如 ?）作为实际类型参数，除非有明确设计意图：
立即学习“Java免费学习笔记（深入）”；
- ✅ 合理：
Map<Long, List<Order>> ordersByUserId（键是用户 ID，值是订单列表） - ⚠️ 慎用：
Map<Object, Object>—— 完全失去类型约束，等于退化为 Java 1.4 时代写法 - ? 若需灵活性，可用受限通配符，如
Map<String, ? extends Product>（仅用于只读场景）
null 键/值需配合类型设计做语义澄清
HashMap 允许一个 null 键和任意数量 null 值，但 get(key) 返回 null 无法区分“键不存在”和“键存在但值为 null”。规范做法是：
- 业务上尽量避免存
null值；若必须支持，用Optional<V>包装返回值（如Optional<User> getUser(String id)） - 判断键是否存在，始终用
containsKey(key)，不要依赖get(key) == null - 若键本身可能为
null（极少见），需额外注释说明其业务含义，例如 “null表示匿名会话”
初始化容量与泛型无关，但影响类型安全实践
泛型声明本身不参与运行时逻辑，但初始化时预设合理容量（如 new HashMap<>(32)）可减少扩容带来的哈希重散列，间接提升类型稳定场景下的性能一致性。注意：容量参数不影响泛型类型，只是构造参数。
