Java中泛型与HashSet协同依靠编译期类型检查和运行时结构约束，确保类型统一；泛型在声明时锁定类型，编译器拒绝非法添加并支持无强制转型遍历；HashSet底层基于HashMap，泛型擦除但校验前置；自定义类需重写hashCode和equals以保障去重逻辑；应避免裸用原始类型以防类型安全失效。
Java 中泛型与 HashSet 协同工作，靠的是**编译期类型检查 + 运行时结构约束**，两者配合确保集合内元素类型统一，既安全又高效。
泛型在声明时锁定类型
当你写 HashSet<string></string>，泛型参数 <string></string> 就像给集合贴了一个“只收字符串”的标签。编译器会：
- 拒绝往里面
add(123)或add(new Date())—— 编译直接报错，不生成字节码 - 允许
for (String s : set)遍历时直接用s当字符串用，无需强制转型 - 让
iterator().next()的返回类型自动推为String，而不是笼统的Object
HashSet 底层不破坏泛型约定
HashSet 内部用 HashMap 存储（键存元素，值固定为 PRESSENT），而 HashMap 的 key 类型也受泛型约束。关键点在于：
Java注释规范Skills
下载
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- 泛型是“擦除式”的：运行时
HashSet<string></string>和HashSet<integer></integer>都变成原始类型HashSet，但擦除前的校验已经完成 - HashSet 本身不提供
get(int index)或下标访问，避免绕过类型约束；所有增删查操作都走泛型方法签名（如add(E e)） - 即使通过反射强行塞入非法类型，后续取出来时仍会因类型不匹配在使用处抛出异常（此时问题已暴露，但根源在绕过编译检查）
自定义类要配合重写 hashCode 和 equals
如果存的是自定义对象（比如 Person），仅靠泛型还不够——泛型管“类型”，而 HashSet 的“去重”靠的是 hashCode() 和 equals()：
- 泛型保证你只能 add
Person实例，但无法判断两个Person是否逻辑重复 - 必须重写
hashCode()和equals()，且保持一致：相等的对象必须有相同哈希值 - 例如，把姓名+年龄作为判断依据，那么两个同名同龄的
Person就算同一个元素，第二次 add 会失败
不推荐裸用原始类型
写成 HashSet set = new HashSet(); 虽然能编译，但会失去全部泛型保护：
- 可以混存
"abc"、123、new Date()，编译器不管 - 遍历时必须手动强转：
String s = (String) it.next();，容易触发ClassCastException - IDE 和静态分析工具无法帮你发现类型误用
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
