50 借 + 50 还：把「不超借」写成并发断言的借还引擎

在这个校园图书借阅平台里，借还流通是我必须先把结论钉死的一条链路。它看起来只是两条普通的写操作，但借书与还书各自持有不同的锁 —— 顺序一旦不一致，两条链路就会互相等待。下面的判断与取舍都来自项目记录（问题、决策、断言与指标）；超出记录的解释会标注为「分析」。

背景：为什么会担心并发

场景很具体：选课周、考试季，大量学生同时抢热门教材。同一批副本会被几十个请求同时争抢，而借还与归还的链路各自持有不同的锁。

问题：借书锁父表、还书锁子表

• 循环等待：借书锁父表、还书锁子表，两个事务以相反的顺序取锁就会互相等待。
• 连接池被打爆：等待中的事务占着连接不放，请求越堆越多。
• 负库存超借：更糟的是结果 —— 库存被扣成负数，同一本书借给了超出的读者。

我没有把它当成「SQL 写得对不对」的问题，而是当成加锁顺序的问题：循环等待正是死锁的四个必要条件之一。能直接破坏一个必要条件，就不该只在事后做补偿。

候选方案：三个选项

实现：把加锁顺序变成全局约定

我最终选择统一加锁顺序：借书与还书两条链路的加锁顺序被统一成同一个确定顺序，所有事务都按这个顺序取行级排他锁。顺序一致时，两个事务不可能再形成「你等我、我等你」的环。

验证：三个并发硬断言

这条链路上我最想保留的一个习惯是：不把并发结论写成描述性文字，而是写成用例里的硬断言。因为并发问题靠描述说不清，只有断言能在回归时报警。

同一批验证里还测了什么

同一条思路在项目里的另外两处

• 预约闭环：用归还事件驱动的 FIFO 状态机管理孤本预约，回收时主动唤醒队首读者，逾期未取自动淘汰并顺延 —— 资源不在队列里僵死。
• 推荐的可借性：把真实在架库存作为推荐权重的一路，并过滤无库存书目。这条线我坚持一个判断：算法再准，推荐了借不到的书，用户感受到的就是功能坏了。

复盘

• 我从此更愿意把结论写成断言，而不是写在文档里 —— 文档不会在回归时报警。
• 能消除的问题，不要只做补偿：这也是我倾向「破坏条件」而不是「事后重试」的原因。
• 代价要提前写下来：锁顺序是全局约定，这一点在评审里必须被当成硬规则。

完整的架构（确定性锁顺序、FIFO 预约状态机、库存感知的推荐、双模 AI 导读）与全部实测数据在项目页里：查看校园图书借阅系统项目详情。