Java简易图书管理系统开发教程

图书类设计应区分业务属性与存储需求：ISBN用String存，作者用List，状态用枚举，集合首选ArrayList，输入统一用nextLine()校验，业务逻辑拆至BookManager和ConsoleUI类。

图书类怎么设计才不会后期改崩

图书信息不是只有书名和编号，硬编码成 String title + int id 会很快卡死在借阅状态、ISBN校验、多作者处理上。必须从建模起点就区分「业务属性」和「存储/展示需求」。

• ISBN 用 String 存，别用 long —— 带短横线（如 "978-7-04-050694-5"）或可能以 0 开头，数值类型会丢精度或抛异常
• 作者字段别直接写 String author，改成 List authors，哪怕当前只填一个，否则加个合著者就得重构所有 getter/setter 和 toString
• 状态字段用枚举，别用 int status 或 String status：

  public enum BookStatus { AVAILABLE, BORROWED, LOST, RESERVED }

  后期加新状态、做 switch 判断、序列化输出都更稳

为什么 ArrayList 足够起步，但别碰 LinkedList

新手常以为“链表增删快”，但在图书管理系统里，你几乎不会在中间插入一本新书，也不会随机删掉第 17 本——主要操作是遍历查书、按 ID 查单本、批量导出。这时候 ArrayList 的缓存友好性和 O(1) 随机访问压倒一切。

• 用 ArrayList 存全部图书，get(int index) 和 size() 快；add(Book) 在末尾也基本是 O(1)
• 避免用 LinkedList：它每次遍历都有指针跳转开销，get(int) 是 O(n)，查 ISBN 得全扫一遍时反而更慢
• 真要优化查询（比如按 ISBN 快速定位），等系统跑起来再说——先用 stream().filter(b -> b.getIsbn().equals(input)).findFirst()，别一上来就上 HashMap，容易过早复杂化

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、变量作用域混乱、根本没法单元测试。面向对象建模的第一道坎，就是把“谁该负责什么”划清楚。

• 拆出 BookManager 类，只管增删改查集合、持久化（哪怕只是存文件）、基础搜索逻辑
• 拆出 ConsoleUI 类，只管 printMenu()、readInput()、showResult()，不碰 Book 实例的任何字段
• main 只剩三行：

  BookManager manager = new BookManager();
  ConsoleUI ui = new ConsoleUI(manager);
  ui.start();

  后面加图形界面、换数据库，只动构造参数，不动核心流程