book 与 member 应通过 id 双向关联：book 存 current_borrower_id，member 存 borrowed_book_ids 列表，避免循环引用；library 仅协调，不托管全部实例；lend_book() 需校验存在性、可用性及借阅限额。
如何设计 Book 和 Member 的核心属性与关系
图书馆系统最常卡在“借阅关系怎么建”——不是用外键硬绑，也不是靠全局列表临时查。真实场景里，Book 要能回答“谁在借”，Member 要能列出“我借了哪些”，两者得双向可查，但又不能互相持有完整对象导致循环引用或内存泄漏。
实操建议：
-
Book里存一个current_borrower_id: int | None，只记 ID，不存Member实例；需要详情时再查库或缓存 -
Member里用borrowed_book_ids: list[int]存自己借的书 ID 列表，避免每次遍历全量Book对象找归属 - 如果用 Python，别在
__init__里默认传空列表作为参数（def __init__(self, borrowed_book_ids=[])是陷阱），改用None+ 初始化判断 - 数据库层面，
books表加borrower_id外键，members表不反向冗余书 ID，靠关联查询补足
为什么 Library 类不该是万能管家
很多人一上来就写个巨型 Library 类，把增删书、注册会员、处理借还、生成报表全塞进去，结果测试难写、逻辑缠绕、改一个功能牵出三个 bug。
实操建议：
-
Library只做协调：暴露add_book()、lend_book()这类高阶接口，内部调用Book或Member的方法，不直接操作属性 - 借书逻辑拆进
Transaction类（哪怕只是个简单数据类），包含book_id、member_id、due_date，方便后续扩展逾期计算、历史归档 - 避免在
Library里维护所有Book和Member实例的 list —— 改用字典按 ID 索引：self._books: dict[int, Book]，查起来 O(1)，删起来也安全 - 如果系统要支持多线程借还，
lend_book()必须对具体Book实例加锁，而不是锁整个Library实例
lend_book() 方法里最容易漏掉的三件事
看似简单的一个借书动作，运行时抛 ValueError: book not available 或静默失败，往往是因为没兜住这几个边界。
常见错误现象：
- 用户输入书 ID 不存在，程序直接 AttributeError 访问
book.is_available - 同一本书被两人同时点击借出，数据库没加约束，出现超借
- 会员已借满 5 本，但校验逻辑放在 UI 层，后端
lend_book()完全不检查
实操建议：
- 开头先做存在性检查：
if book_id not in self._books:→ raise 明确异常，别让下游猜 - 查
book.current_borrower_id is None且len(member.borrowed_book_ids) ，两个条件缺一不可 - 关键步骤用数据库事务包裹（哪怕只是 SQLite 的
BEGIN IMMEDIATE），更新books.borrower_id和插入transactions要么全成要么全退 - 返回值别只返回
True/False，至少带{'success': True, 'transaction_id': 123}，方便前端或日志追踪
Python 中用 @property 控制状态比用 public 属性更可靠
有人把 is_available 直接写成普通属性，结果外部代码随手 book.is_available = False 就改掉了，后续借还逻辑全乱。
实操建议：
- 去掉
self.is_available字段，改用@property动态算：return self.current_borrower_id is None - 如果真要设状态，提供明确方法：
book.mark_as_returned()，内部只允许通过合法路径变更current_borrower_id - 别给
Member加@property def overdue_books这种实时查库的属性——它会悄悄拖慢所有遍历会员的操作，改用缓存或异步更新 - 测试时重点 mock
Book.current_borrower_id的值，验证is_available返回是否符合预期，比测字段赋值更贴近真实使用链路
