Java图书管理系统核心在于分层设计与实体建模：Book和BorrowRecord须为POJO，避免硬编码ID、字符串拼接及Scanner混入业务逻辑；用JSON文件持久化；删除前须校验借阅状态并给出具体提示。
Java 图书管理系统不是“写个 CRUD 就完事”，核心在于理清实体关系、避免硬编码 ID、别把 Scanner 当输入层用到生产逻辑里。
图书与借阅必须建模为独立类，别用 Map 模拟
新手常把图书信息塞进 HashMap 或用一堆 String 字段拼接，结果增删改查全靠字符串匹配——查“Java编程思想”时漏掉空格就查不到。真实业务中 Book 和 BorrowRecord 必须是 POJO，带明确字段和 getter/setter：
public class Book {
private String isbn; // 别用 int，ISBN 有 X
private String title;
private String author;
private int stock; // 库存要单独字段，别用“状态：在库/已借出”
}
借阅记录必须关联真实 Book 实例或至少其 isbn，而不是存一个“图书名字符串”。否则同一书名多版本（如第1版/第2版）会混乱。
控制台交互别在 Service 层调 Scanner.nextLine()
把输入逻辑混进 BookService.addBook() 会导致：单元测试无法注入模拟输入、后续想改成 Web 接口时得重写全部业务方法。正确做法是分层：
立即学习“Java免费学习笔记（深入）”；
-
Main类负责调Scanner获取用户输入，转成Book对象 -
BookService只接收Book对象，专注校验 ISBN 格式、库存非负等业务规则 - 所有提示语（如“请输入书名”）只出现在
Main或专用ConsoleUI类里
否则你加个新功能（比如导出 CSV），就得在 addBook() 里临时塞个文件路径输入——逻辑彻底污染。
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
持久化别直接写 FileWriter 存文本，用简单 JSON 或 CSV 格式
用 PrintWriter 拼接“书名|作者|ISBN”看似简单，但遇到书名含“|”（如《Java|并发实战》）就解析失败；用 ObjectOutputStream 又导致文件不可读、跨版本不兼容。初级项目够用的方案是：
- 用
org.json:json或com.google.code.gson:gson写 JSON 文件，人类可读、易调试 - 每行一个 JSON 对象（JSON Lines），追加日志式写入，避免整文件加载
- 初始化时用
Files.exists()判断文件是否存在，不存在则创建空集合，别让第一次运行就抛FileNotFoundException
别碰数据库连接池或 JPA——对初级项目是过载，JSON 文件已足够体现“数据落地”概念。
删除图书前必须检查是否被借出，且错误提示要具体
常见 bug 是：先删 Book，再删 BorrowRecord，结果中间发生异常导致数据不一致。正确顺序是：
- 查
borrowRecords.stream().anyMatch(r -> r.getIsbn().equals(book.getIsbn())) - 如果存在未归还记录，直接返回
false或抛自定义异常BookNotDeletableException - 提示不能是“删除失败”，而要是“《深入理解JVM》已被用户张三借阅（借出日期：2024-03-15），请先处理借阅记录”
这个检查点最容易被跳过，但恰恰是区分“能跑”和“能用”的分水岭——真实图书馆系统第一条规则就是“禁止删除在借图书”。
真正卡住初学者的，从来不是语法，而是没想清楚“谁该知道什么”。比如 BookService 不该知道控制台怎么输入，ConsoleUI 不该知道 ISBN 校验正则怎么写。边界划清楚了，后面加搜索、加登录、甚至改造成 Spring Boot，才不会推倒重来。
