Java中HashMap键值对反转需确保原value非null且正确实现equals()/hashCode()，重复value导致覆盖或抛异常，null值引发NPE，类型不匹配易ClassCastException，应按实际需求选择合适数据结构而非盲目反转。
Java里用HashMap反转键值对，必须确保原value可作新key
直接遍历原Map，把entry.getValue()当新key、entry.getKey()当新value放进新HashMap就行。但前提是原Map的所有value都非null且实现了equals()/hashCode()——比如String、Integer没问题，而自定义对象若没重写这两个方法，反转后可能查不到、甚至覆盖。
- 原Map含重复value？反转后只会保留最后一个映射，前面的被悄悄覆盖
- 原Map有
nullvalue？放进新Map会抛NullPointerException（除非用LinkedHashMap或ConcurrentHashMap等允许null value的实现，但key仍不能为null） - 想保留插入顺序？用
LinkedHashMap构造新Map，别用默认HashMap
遇到ClassCastException：检查泛型擦除和实际类型
声明是Map<string integer></string>，但运行时value其实是Long，反转时强转成String就会崩。泛型只在编译期校验，运行期全靠自己兜底。
- 反转前用
instanceof判断value类型，尤其处理JSON解析或反射得来的Map - 别依赖IDE自动补全的泛型推断，
map.entrySet().stream().collect(...)这种链式写法容易掩盖类型不匹配 - 如果value是数字但类型混用（
Integer和Long），反转后当key会视为不同对象——哪怕数值相等
用Stream一行反转，但要注意Collectors.toMap的异常场景
map.entrySet().stream().collect(Collectors.toMap(Map.Entry::getValue, Map.Entry::getKey))看着简洁，实际暗坑不少。
- 原Map有重复value？抛
IllegalStateException: Duplicate key，不是静默覆盖 - 需要覆盖逻辑？得传第三个参数
(oldVal, newVal) -> newVal，否则默认不处理重复 - value为
null？toMap内部调用Objects.requireNonNull，直接NPE - 并发环境下别用这个写法，
toMap不保证线程安全
反转后value变多：说明原Map的value本身是集合或复合结构
常见于DTO转换或配置扁平化场景——比如原Map是Map<string list>></string>，直接反转会把整个List当key，既低效又难查。这时候“反转”本质是展开操作。
立即学习“Java免费学习笔记（深入）”；
- 真要按元素级反转？得嵌套遍历value集合，每个元素生成一个新键值对
- key冲突风险陡增：多个原key对应同一个value元素，得决定用哪个原key保留
- 考虑用
MultiValueMap（Spring）或ArrayListMultimap（Guava）替代单值Map，避免强行反转
最麻烦的不是语法怎么写，而是想清楚“反转”到底要解决什么问题——是为快速反查？还是为适配下游接口？目的模糊时，硬套反转逻辑反而让数据关系更乱。
