应使用 arraylist 而非 linkedlist：因图书增删集中在尾部、查询频繁，arraylist 的 o(1) 随机访问和缓存友好性更优；linkedlist 的指针开销在图书对象较小时反而拖慢遍历。
为什么用 ArrayList 而不是 LinkedList 存图书列表
图书管理系统里，图书增删集中在尾部（比如批量导入、新书上架），查询多于插入中间位置。这时候 ArrayList 的随机访问 O(1) 和缓存友好性明显胜出；LinkedList 的每个节点指针开销反而拖慢遍历和迭代——尤其当图书对象本身不大时，指针成本占比更高。
常见错误是看到“链表适合频繁增删”就直接套用，但没注意增删位置：图书列表极少在中间插入（比如第 37 本前插一本），真要那样，不如先用 ArrayList + add(index, element)，再观察性能瓶颈是否真的来自这一步。
- 新增图书一律用
list.add(book)，别写list.add(list.size(), book)—— 效果一样，后者多一次计算还干扰阅读 - 避免在 for 循环里反复调用
list.size()判断长度，JVM 一般会优化，但明确写成int n = list.size(); for (int i = 0; i 更稳 - 如果后期真需要按 ISBN 快速查某本书，别硬扛着遍历
ArrayList，立刻补一层Map<string book></string>，键用book.getIsbn()
HashMap 的 key 为什么必须重写 hashCode() 和 equals()
图书借阅模块常用 Map<string list>></string> 按作者归类，或 Map<string book></string> 按 ISBN 查书。一旦 key 是自定义对象（比如用 BookId 类封装 ISBN），不重写这两个方法，get() 就永远返回 null——因为默认的 hashCode() 返回的是内存地址哈希，两次 new 出来的对象哪怕内容相同，哈希值也不同。
典型报错现象：map.put(new BookId("978-7-02-000000-0"), book); 之后 map.get(new BookId("978-7-02-000000-0")) 拿不到值，调试发现 size 是 1，但 get 失败。
- IDE 自动生成的
hashCode()/equals()只要覆盖所有参与逻辑相等判断的字段（比如 ISBN 字符串）就行，别漏掉 null 检查 - 别用可变字段做 key 的计算依据（例如把
Book.title当 key 字段又允许改标题），否则 map 内部桶位置错乱，数据就丢了 - 如果 key 纯是字符串（如直接用
isbn当 key），不用额外处理——String已经重写好了
遍历借阅记录 Map 时，该用 entrySet() 还是 keySet()
展示“张三借了哪些书”这类功能，代码常写成 for (String userId : borrowMap.keySet()) { List<book> books = borrowMap.get(userId); ... }</book>。这看起来自然，但每次 get() 都是一次哈希查找，时间复杂度从 O(n) 变成 O(n × 平均查找耗时)，数据量大时肉眼可感卡顿。
真实场景中，借阅记录 Map 可能有上千个用户，每个用户平均借 3–5 本书。用 entrySet() 直接拿到键值对，既少一次哈希定位，又避免重复构造 Iterator。
- 优先写
for (Map.Entry<string list>> entry : borrowMap.entrySet())</string>，然后用entry.getKey()和entry.getValue() - 如果只用 value（比如统计所有借出图书总数），用
values()最干净：int total = borrowMap.values().stream().mapToInt(List::size).sum(); - 千万别在循环里修改正在遍历的 map（比如边查边删过期记录），会抛
ConcurrentModificationException；要删得先收集 key，再统一removeAll()
List 和 Map 嵌套太深时，怎么避免 NullPointerException
Map<string map list>>> userBooksByYear</string> 这种三层结构很常见（用户 → 年份 → 图书列表），但每层都可能为 null：用户没借过书、某年没借书、甚至年份 key 根本不存在。直接链式调用 userBooksByYear.get(userId).get("2024").size() 必崩。
不是靠一堆 if 判断，而是用“容器即空值”的思维：让每一层缺失时返回空集合，而不是 null。Java 8+ 推荐用 computeIfAbsent() 初始化，比手写 if-null-put 清晰得多。
- 初始化嵌套 map：
userBooksByYear.computeIfAbsent(userId, k -> new HashMap()).computeIfAbsent("2024", k -> new ArrayList()).add(book); - 读取时仍要防第一层 null：
Map<string list>> yearMap = userBooksByYear.get(userId);</string>后加一句if (yearMap == null) return Collections.emptyList(); - 别依赖 IDE 自动补全的
Objects.requireNonNull()，它只是提前报错，没解决空值语义问题
嵌套越深，初始化责任越往前移——不是等用到才检查，而是在第一次 put 时就确保路径畅通。这点容易被忽略，直到线上查半天才发现某类用户数据根本进不了第三层。
