用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免费学习笔记（深入）”；
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 初始化时，所有 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 并打印行号，不然后面查半天都不知道为啥少了一半词。
