核心在于BorrowRecord必须完整绑定Book、Member和时间状态；应由BorrowService统一处理并保证事务一致性，字段含id、bookId、memberId、borrowDate、returnDate、status，且需覆盖重复借阅、限额超限等边界测试。
Java 图书借阅管理系统不是靠堆砌类就能跑起来的，核心在于「借阅行为」能否被准确建模——BorrowRecord 必须同时绑定 Book、Member 和时间状态，缺一不可。
为什么不能把借阅逻辑全塞进 Book 或 Member 类里
常见错误是让 Book.borrowBy(Member m) 或 Member.borrow(Book b) 直接修改库存或借阅数。这会导致：
-
BorrowRecord丢失——无法追溯谁在什么时间借了哪本书、是否已归还 - 并发借阅时出现超借（两个线程同时判断
stock > 0，都通过） - 归还逻辑无法反向校验（比如归还的书根本不在该会员名下）
正确做法是用独立的 BorrowService 统一处理，所有借阅/归还操作必须生成一条 BorrowRecord 实例，并用 synchronized 块或 ReentrantLock 锁住 bookId + memberId 组合键。
BorrowRecord 必须包含的字段和约束
这个类不是可选的“日志”，而是业务主实体。少一个字段，后续统计或对账就可能出错：
立即学习“Java免费学习笔记（深入）”；
-
id：自增或 UUID，唯一标识一次借阅行为 -
bookId：关联Book.id，不能只存书名（重名书会冲突） -
memberId：关联Member.id，不能只存姓名（同名会员无法区分） -
borrowDate：用LocalDateTime.now()，别用Date或字符串 -
returnDate：初始为null，归还时才设值；查询“当前借阅中”就靠它是否为null -
status：枚举值PENDING/RETURNED/OVERDUE，别用字符串硬编码
如何避免“借了没扣库存”或“还了没加库存”
库存变更必须和 BorrowRecord 写入数据库在同一个事务里，不能分两步。典型错误写法：
book.setStock(book.getStock() - 1); borrowRecordDao.insert(record); // 失败则库存已扣，但记录没存 bookDao.update(book); // 成功了才更新库存
正确顺序（以 JDBC 为例）：
Connection conn = dataSource.getConnection();
conn.setAutoCommit(false);
try {
bookDao.decreaseStock(conn, bookId); // UPDATE book SET stock = stock - 1 WHERE id = ? AND stock > 0
if (bookDao.getAffectedRows() == 0) throw new IllegalStateException("库存不足");
borrowRecordDao.insert(conn, record);
conn.commit();
} catch (Exception e) {
conn.rollback();
throw e;
}注意：decreaseStock 的 SQL 必须带 AND stock > 0 条件，并检查影响行数，否则并发时仍可能超借。
测试时最容易漏掉的边界场景
光测“正常借、正常还”不够，以下情况必须覆盖：
- 同一本书被同一会员重复借阅（应拒绝，除非已归还）
- 会员借阅已达上限（如最多借 5 本），再借应抛
LimitExceededException -
returnDate被手动设为早于borrowDate（构造函数或 setter 中要校验） - 数据库里
returnDate是NULL，但 Java 对象里被初始化为LocalDateTime.MIN（导致判空失效）
真实系统里，80% 的线上问题来自这些没走通的分支路径，而不是主流程。
