用string作key最省事安全；需大小写不敏感时统一tolowercase()存取；复合key须重写hashcode/equals且字段final；查不到返回null符合原生语义。
HashMap 存词典数据时，key 用 String 还是自定义对象？
直接用 String 做 key 最省事，也最安全。除非你真需要按“词性+拼写”联合查（比如同形异义词），否则别自己写 WordEntry 当 key —— 容易漏掉 hashCode() 和 equals() 的同步实现，一加进 HashMap 就查不到。
常见错误现象：map.get(new WordEntry("apple", "noun")) 返回 null，但明明刚 put 过；原因就是没重写 hashCode()，导致哈希桶位置错乱。
- 查单个英文词 →
Map<string string></string>足够，value 存中文释义 - 要支持多义项 → value 改成
List<string></string>或封装成Definition类，但 key 仍保持String - 如果真要用复合 key，必须确保
hashCode()和equals()逻辑一致，且字段不可变（final）
查词时大小写不敏感，但又不想全转小写存？
别在 get() 前手动调 toLowerCase() 再查——这会破坏原始拼写（比如专有名词 “Java” 查成 “java” 就不对）。正确做法是建 map 时统一规范 key 的大小写形式，查的时候也走同一路径。
使用场景：用户输入 “HELLO”、“Hello”、“hello” 都应命中同一个词条。
立即学习“Java免费学习笔记（深入）”；
- 初始化时，所有 key 都用
word.toLowerCase()存入HashMap - 查询时，同样用
input.toLowerCase()去get() - 返回结果时，从 value 里带出原始标准拼写（比如存
"hello" → new Entry("Hello", "你好")） - 不要用
TreeMap配String.CASE_INSENSITIVE_ORDER，它不加速，反而慢，且不解决 key 归一化问题
HashMap 查词很快，但加载词典文件后内存暴涨？
不是 HashMap 本身的问题，而是读文件时每行都新建 String、反复拼接、没控制缓冲区，导致大量临时对象堆积。JVM GC 压力大，看起来像 map 吃内存。
性能影响：10 万词条，若每词额外生成 3 个中间 String，可能多占 20–30MB 堆空间。
- 用
BufferedReader逐行读，避免Files.readAllLines() - 解析时用
line.strip()而非line.trim()（Java 11+，更准） - 拆分字段优先用
line.indexOf(':')+substring()，比split(":")少创建数组和正则对象 - 确认词典文件编码是 UTF-8，否则中文 value 会变
???，后续 toString() 又触发更多异常字符串
查不到词时，该抛异常还是返回 null 或空集合？
返回 null 是最轻量、最符合 HashMap 原生语义的做法。用户代码自己判断就行，不用强制 try-catch。
容易踩的坑：有人封装一层 lookup(String word) 方法，内部发现没找到就 throw IllegalArgumentException —— 这会让调用方被迫处理本可忽略的“查无此词”情况，违背词典的查询本质。
- 对外暴露的查询方法，返回类型用
String或List<string></string>，查不到就是null或空集合 - 如果业务要求必须返回默认值（比如“未收录”），用
map.getOrDefault(key, "未收录")，别改 map 行为 - 日志记录缺失词可用，但别让日志级别设成 ERROR，查生词不是错误，是常态
真正麻烦的是词典数据本身有重复 key 或格式错乱，这时 HashMap 会静默覆盖——得在加载阶段加一行校验：遇到重复 key 就 warn 并打印行号，不然后面查半天都不知道为啥少了一半词。
