用ArrayList管理图书和读者时，需重写Book和Reader的equals()与hashCode()（Book按isbn、Reader按id），借阅状态用枚举BorrowStatus替代字符串，控制台输入后及时调用nextLine()清空缓冲区，初期避免文件持久化以聚焦核心流程。
如何用ArrayList管理图书和读者对象
Java里不用数据库时，ArrayList是最直接的内存容器选择。别一上来就琢磨Map或Set——图书编号可能重复（比如不同版本同一书名），而读者借阅关系是动态增删的，ArrayList 和 ArrayList 足够撑起初期逻辑。
关键点在于对象设计要带可比较性：给 Book 类重写 equals() 和 hashCode()，依据 isbn（不是书名）判断是否为同一本书；Reader 则按 id 判等。否则 list.remove(book) 可能删不掉。
- 避免用
String title作为查找主键，改用String isbn字段，国际标准更可靠 - 借书操作前先
books.contains(b)，但前提是equals()已正确定义 - 不要在遍历
ArrayList时直接remove()，会抛ConcurrentModificationException，改用Iterator.remove()或倒序索引删除
借阅状态怎么用枚举比字符串更安全
别用 String status = "borrowed" 表示状态。Java枚举（enum）能杜绝拼写错误、支持 switch、还能附带行为——比如 BORROWED 状态下禁止二次借出。
定义一个 BorrowStatus 枚举：
立即学习“Java免费学习笔记（深入）”；
public enum BorrowStatus {
AVAILABLE, BORROWED, LOST, RESERVED
}然后在 Book 类中用 private BorrowStatus status = BorrowStatus.AVAILABLE;。这样所有状态变更都受限于枚举值，IDE还能自动补全、编译期报错。
- 如果后期要加“逾期”状态，直接在枚举里追加，不用改一堆
"overdue"字符串散落各处 - 避免把状态存在
int或byte里（如 0/1/2），可读性和维护性极差 - 枚举实例默认线程安全，多线程环境下比手动同步字符串变量省心
控制台输入怎么避开Scanner.nextLine()吃掉回车的坑
新手最常卡在这儿：scanner.nextInt() 读完数字后，缓存区还剩一个换行符，紧接着 scanner.nextLine() 就立刻返回空字符串——导致“输入读者姓名”那步永远拿不到内容。
解决方法固定且简单：在每个 nextInt()、nextDouble() 后，**立刻加一行** scanner.nextLine(); 消耗掉残留换行符。
- 别试图用
scanner.skip("\\R")，不同系统换行符（\n / \r\n）处理不稳定 - 统一用
nextLine()读所有输入，再用Integer.parseInt()转数字，反而更可控 - 如果封装了输入工具类，这个“清空缓冲区”的动作必须作为内部逻辑，别让业务代码反复写
为什么暂时别碰文件持久化（除非真需要关机不丢数据）
项目初期花半天写 saveToFile() 和 loadFromFile()，结果发现序列化后中文乱码、对象版本升级后反序列化失败、路径硬编码导致换个电脑就找不到文件……这些全是干扰主线逻辑的噪音。
真正该优先保证的是核心流程跑通：添加图书 → 注册读者 → 借书 → 还书 → 查询库存。只要每次运行时初始化几本样例书、两个测试读者，就能完整走通全部业务分支。
- 文件IO异常（
IOException）必须捕获，但别只写e.printStackTrace()，至少打到日志或提示用户“保存失败，请检查磁盘空间” - 如果真要加文件功能，优先选
Properties或 JSON（用org.json简单库），比原生ObjectOutputStream兼容性好得多 - 路径写成相对路径
"data/books.json"，并提前在程序启动时用new File("data").mkdirs();创建目录
真实开发中，内存模型跑稳比早早上磁盘更重要。很多教学项目卡在“怎么保存”，其实是把问题复杂度提前了。
