hashmap最适合快递柜格口与取件码映射：键为string取件码，值为string格口编号，需校验6位纯数字、避免前导零丢失、预设容量、取件后置"taken"标记或删除键，并统一用nextline().trim()处理输入。
用 HashMap 存快递柜格口和取件码最直接
Java 里没有“快递柜专用数据结构”，但 HashMap<string string></string> 足够覆盖核心需求：用取件码（String）查格口编号（String 或 Integer），或反过来用格口查码。别用 TreeMap，除非你真需要按取件码字典序遍历——实际业务里几乎不需要。
常见错误是把格口编号当 int 存、取件码当 int 存，结果遇到 "00123" 这种带前导零的码直接变 123，取件时对不上。必须统一用 String。
-
HashMap<string string></string>：键 = 取件码，值 = 格口编号（如"A05"） - 存入前校验取件码长度是否为 6 位、是否全数字（可选，但建议）
- 避免用
new HashMap()后不设初始容量——如果预估要存 100 个格口，直接写new HashMap(128)，省得扩容搬数据
取件时怎么防重复提取和过期
纯 HashMap 不带时间戳和状态标记，所以不能只靠它判断“是否已取”。得加一层逻辑：取件成功后，要么删掉这个键值对，要么把值改成 "TAKEN" 这类标记字符串。
删键最简单，但没法查历史；留标记能查，但得在每次 get() 后手动判断值是不是 "TAKEN"。别用布尔值做值类型——会和格口编号类型不一致，强制转型容易崩。
立即学习“Java免费学习笔记（深入）”；
- 取件流程：先
map.get(inputCode)→ 拿到格口 → 再map.put(inputCode, "TAKEN") - 如果格口被占（比如别人刚取走），
get()返回null或"TAKEN"，就该提示“取件码无效或已领取” - 不建议在
HashMap里塞LocalDateTime做超时——没定时清理机制，超时判断得靠取件时比对当前时间，逻辑得写在业务层
控制台交互别卡死，输入要清空缓冲区
用 Scanner 读取取件码时，如果之前用过 nextInt() 或 nextLine() 混用，很容易漏掉第一行输入——因为换行符留在缓冲区里，nextLine() 直接读到空串。
所有输入统一用 scanner.nextLine()，哪怕你要的是数字，也先读成 String，再用 Integer.parseInt() 转。这样稳。
- 输入取件码后，立刻用
trim()去首尾空格：scanner.nextLine().trim() - 用户输错三次，别直接退出，用
continue回到主循环开头，保持控制台活着 - 别在循环里反复
new Scanner(System.in)——资源没关，还可能出异常
测试时最容易忘的边界情况
本地跑通不代表能上线。真实场景下，用户会输空串、输字母、输超长数字、连续按回车——这些都会让 HashMap.get() 返回 null，但你的提示语如果只写“取件失败”，根本看不出是输错了还是系统崩了。
真正该打日志的地方不是“成功取出”，而是“收到空输入”“收到非6位数字”“查不到该取件码”。控制台程序没日志框架，至少用 System.err.println() 输出这类问题。
- 取件码长度不是 6 → 提示“请输入6位取件码”
-
map.get()返回null→ 提示“取件码不存在或已过期”（别暴露内部细节，比如“HashMap里没这个key”） - 格口编号返回
"TAKEN"→ 提示“该快件已被领取”
格口编号和取件码本质都是业务标识符，别在代码里写死 "A01" 或 "123456" 当测试值——抽成常量或配置，不然改一个地方漏十个地方。
