图书类设计应区分业务属性与存储需求：ISBN用String存，作者用List，状态用枚举，集合首选ArrayList，输入统一用nextLine()校验，业务逻辑拆至BookManager和ConsoleUI类。
图书类怎么设计才不会后期改崩
图书信息不是只有书名和编号，硬编码成 String title + int id 会很快卡死在借阅状态、ISBN校验、多作者处理上。必须从建模起点就区分「业务属性」和「存储/展示需求」。
-
ISBN用String存，别用long—— 带短横线（如"978-7-04-050694-5"）或可能以 0 开头，数值类型会丢精度或抛异常 - 作者字段别直接写
String author，改成List<string> authors</string>，哪怕当前只填一个，否则加个合著者就得重构所有 getter/setter 和 toString - 状态字段用枚举，别用
int status或String status：public enum BookStatus { AVAILABLE, BORROWED, LOST, RESERVED }后期加新状态、做 switch 判断、序列化输出都更稳
为什么 ArrayList 足够起步，但别碰 LinkedList
新手常以为“链表增删快”，但在图书管理系统里，你几乎不会在中间插入一本新书，也不会随机删掉第 17 本——主要操作是遍历查书、按 ID 查单本、批量导出。这时候 ArrayList 的缓存友好性和 O(1) 随机访问压倒一切。
- 用
ArrayList<book></book>存全部图书，get(int index)和size()快；add(Book)在末尾也基本是 O(1) - 避免用
LinkedList：它每次遍历都有指针跳转开销，get(int)是 O(n)，查 ISBN 得全扫一遍时反而更慢 - 真要优化查询（比如按 ISBN 快速定位），等系统跑起来再说——先用
stream().filter(b -> b.getIsbn().equals(input)).findFirst()，别一上来就上HashMap<string book></string>，容易过早复杂化
Scanner.nextLine() 吃掉输入的坑怎么绕过去
控制台交互时，输完数字再调 nextLine() 经常读到空字符串，这是 nextInt() 不吞换行符导致的典型 bug，不是 Scanner 有毛病，是没理解它的行为边界。
- 统一用
nextLine()读所有输入，数字字段后续用Integer.parseInt()转，避免混用nextInt()/nextDouble()和nextLine() - 用户输错时别直接退出，加一层校验：
String input = scanner.nextLine().trim(); if (input.isEmpty()) { System.out.println("不能为空"); continue; } - ISBN 输入建议加简单格式提示（比如“请输入13位或带短横线的ISBN”），但不要在输入时强行格式化——用户粘贴
"9787040506945"和"978-7-04-050694-5"都应接受，校验逻辑放在Book构造器里 normalize
main 方法里别写业务逻辑，哪怕只有一百行
把所有功能塞进 main，看似快，实则让「改一个菜单选项」变成满屏找 if-else、变量作用域混乱、根本没法单元测试。面向对象建模的第一道坎，就是把“谁该负责什么”划清楚。
立即学习“Java免费学习笔记（深入）”；
- 拆出
BookManager类，只管增删改查集合、持久化（哪怕只是存文件）、基础搜索逻辑 - 拆出
ConsoleUI类，只管 printMenu()、readInput()、showResult()，不碰Book实例的任何字段 -
main只剩三行：BookManager manager = new BookManager(); ConsoleUI ui = new ConsoleUI(manager); ui.start();
后面加图形界面、换数据库，只动构造参数，不动核心流程
