Java列表与映射实现通讯录管理

偷偷努力，悄无声息地变强，然后惊艳所有人！哈哈，小伙伴们又来学习啦~今天我将给大家介绍《Java用List和Map实现联系人管理》，这篇文章主要会讲到等等知识点，不知道大家对其都有多少了解，下面我们就一起来看一吧！当然，非常希望大家能多多评论，给出合理的建议，我们一起学习，一起进步！

ArrayList比LinkedList更适合联系人管理，因其支持O(1)随机访问，适合遍历、分页和索引查询；高频头插删场景除外。

用 ArrayList 存联系人对象比用 LinkedList 更合适

联系人管理中增删操作不频繁，但遍历、按索引查（如分页展示第5~10个）和随机访问多。ArrayList 的数组结构支持 O(1) 随机访问，而 LinkedList 查第n个元素要 O(n) 遍历指针。
除非你确定会高频在列表头部插入/删除（比如实时消息队列），否则别为了“听起来更高级”选 LinkedList。
实操建议：
• 直接声明为 List 接口类型，方便后期替换实现类
• 初始化时预估容量（如 new ArrayList(100)），避免多次扩容复制数组
• 不要存 null 联系人，统一用 Optional 或判空逻辑处理

用 HashMap 做手机号快速查找

用户常按手机号查联系人，这是典型的 key-value 查询场景。用手机号作 key，Contact 对象作 value，get() 时间复杂度稳定 O(1)。
注意几个关键点：
• 手机号必须标准化：统一去空格、去短横线、补国家码前缀（如 +86），否则 “138-1234-5678” 和 “13812345678” 会被当成两个 key
• key 不能用 Contact 对象本身——它没重写 equals() 和 hashCode() 就会导致查不到
• 如果允许一个号码绑定多个联系人（如家庭共用号），就改用 Map>
• 别把 HashMap 当成数据库：它不支持模糊搜索（如“姓张的”）、范围查询（如“创建时间最近7天”），这类需求得靠遍历 values() 或引入额外索引结构

增删改查时别直接操作原始集合，封装成方法再加校验

很多人写到一半发现：添加重复手机号没拦截、删除时传了 null ID 导致 NPE、修改姓名后没同步更新 Map 的 key……这些不是语法错误，是业务逻辑裸奔。
实操建议：
• 添加联系人前，先用 map.containsKey(phone) 检查是否已存在
• 删除时，用 map.remove(phone) 同时从 Map 和 List 中移除，别只删 List 导致 Map “脏数据”
• 修改手机号必须两步：先 map.remove(oldPhone)，再 map.put(newPhone, contact)，并确保 List 中的 contact 对象字段也更新（或重建对象）
• 所有 public 方法入口加 Objects.requireNonNull(contact, "contact cannot be null")，别让异常穿透到 UI 层

导出联系人列表时，list.stream().sorted(...).collect(...) 比手写冒泡安全

用户要求“按姓名拼音排序”或“按添加时间倒序”，这时候别自己写排序逻辑。Java 8+ 的 Stream API 可读性高、不易出错，且底层复用 Arrays.sort() 的优化实现。
示例：
list.stream().sorted(Comparator.comparing(Contact::getName)).collect(Collectors.toList())
注意：
• sorted() 返回新 List，原 list 不变；如果想原地排序，用 Collections.sort(list, comparator)
• 中文姓名排序要用 Collator.getInstance(Locale.CHINA)，否则 “王” 和 “李” 可能按 Unicode 码点排错（“李”U+674E，“王”U+738B，实际“李”应在“王”前）
• 如果 list 很大（>10万条），排序可能卡顿，考虑前端分页 + 后端只返回当前页数据，而不是全量排序再切片

实际落地时最常被忽略的是数据一致性：List 和 Map 两个容器内容必须严格同步。哪怕只漏掉一次 map.put()，后续按号码查就会“明明刚存过却找不到”。建议把所有增删改操作收拢进一个 ContactManager 类，禁止外部直接访问内部集合。

本篇关于《Java列表与映射实现通讯录管理》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！