基于Spring Boot和Redis的无人图书借阅系统设计：从借阅流程到并发控制-代码聚汇网

基于Spring Boot和Redis的无人图书借阅系统设计：从借阅流程到并发控制

要上进的柯同学·2026-09-02·阅读 22 GEO检测（免费）

无人图书借阅系统Spring BootMyBatis Plus

|难度：普通|阅读约 40 分钟

1. 为什么做无人图书借阅系统

1.1 传统图书借阅模式的痛点

先讲个真实的场景。前两年我参与过一次校园图书馆的改造项目，当时图书馆的管理员跟我倒了一肚子苦水：每天大量的借还书操作都靠人工扫码，高峰期排队能排到门口；闭馆之后读者没法还书，第二天开馆门口堆着一沓书；更麻烦的是图书盘点，人工清点几千册书要花整整两天，还经常对不上账。

这类问题在中小型图书馆、企业图书角、社区阅读站里特别典型。要么养一个专职管理员成本太高，要么开放时间有限导致借阅率上不去。无人图书借阅系统要解决的，本质上就是这三件事：把借还书的操作从人工变成自助，把图书的在架状态从"靠人记忆"变成实时可查，把借阅规则的执行从"靠管理员提醒"变成系统强制约束。

1.2 系统的目标与设计边界

做这个系统之前，我给自己划了几条边界。第一，不做纯硬件方案。市面上成熟的无人图书馆大多依赖RFID门禁、自助借还机等专用设备，成本动辄十几万，不适合个人项目或小场景。第二，要做成真正能落地的东西，而不是demo。所谓落地，指的是读者端能完成借书、还书、续借、预约，管理员端能处理违规、补录、盘点，两个角色都能通过简单的Web界面操作。

第三，也是最重要的一点，系统要能够应对无人值守的场景。什么意思呢？就是读者自己操作的时候可能会误操作、可能会赖账、可能会借了书不还。用户身份怎么验证、图书怎么识别、违规怎么处理，这些不能靠"自觉"，得靠流程设计硬性约束。整个系统的核心价值，不在界面多好看，而在借阅流程设计的严谨性。

这篇文章里的源码，我按Spring Boot 2.7 + MyBatis Plus + MySQL 8.0 + Redis的方案实现，前端用Thymeleaf模板引擎做管理端，自助终端页面用纯HTML + Vue 3 CDN方式嵌入，方便在触屏设备上运行。整套代码我放到Gitee仓库里，后面会讲怎么从零启动。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 整体架构与关键技术选型

2.1 技术选型：为什么是这组搭配

先说后端。Spring Boot是Java后端项目的事实标准，这一点没什么争议。搭配MyBatis Plus是为了减少单表CRUD的样板代码，图书信息、借阅记录、用户表这些基础操作，用MyBatis Plus的BaseMapper直接继承就能拿到现成的增删改查，能省下大概三分之一的数据层代码。为什么不用Spring Data JPA？我个人的偏好是JPA在复杂查询和SQL调优时不够直观，MyBatis的XML里写SQL可以精细控制每一行查询逻辑，对初学者也更友好——至少SQL执行计划看得清楚，不像JPA那样在Hibernate生成的SQL里绕来绕去。

Redis在系统里承担的任务很明确：缓存高频读取的图书状态，以及处理图书的临时占用锁。你可能会问，图书借阅这种低频操作为什么要用分布式锁？道理很简单，两个读者同时扫同一本书的条码，理论上系统应该只允许一个人借走。如果直接查数据库改状态，在高并发下可能出现两个事务都读到"图书在馆"，然后都放行——这就是经典的丢失更新问题。Redis的SETNX可以实现一个轻量级的图书借阅锁，保证同一本书在同一时刻只有一个借书请求能进入后续流程。

前端为什么没有用重型框架？因为自助终端的页面逻辑并不复杂，主要就是展示在架图书、提供搜索、处理借还流程。Vue 3用CDN方式引入，不需要Node.js构建链，部署时只要把HTML文件丢到静态目录里就行。对小型项目来说，少一套前端工程化链路，就意味着少一层维护成本。

2.2 模块划分：清晰到能直接找到代码

源码的包结构我按业务域拆，而不是按技术层拆，这是项目可维护性的关键。很多人新手写Spring Boot项目习惯按controller、service、mapper三层建包，结果业务逻辑分散在各个service里，改一个借书需求要动七八个类。我采用的做法是这样的：

text复制com.library.unmanned
├── common          // 通用类：统一返回结果、异常处理、常量定义
├── config          // 配置类：Redis、MyBatis Plus、拦截器、WebMvc
├── controller      // 接口层：管理员端、自助终端端、读者端
├── service         // 业务层：接口 + 实现类
├── mapper          // 数据访问层：MyBatis Plus的Mapper接口
├── entity          // 实体类：与数据库表对应
├── dto             // 数据传输对象：接收前端参数，避免实体直接暴露
├── vo              // 视图对象：返回给前端的数据结构
├── enums           // 枚举：借阅状态、图书状态、操作类型等
├── mq              // 消息队列：异步处理还书通知、逾期提醒
└── utils           // 工具类：日期计算、条码生成、RFID解析

其中enums这个包很少有人单独提，但它对业务正确性的影响比想象中大。图书状态、借阅状态、操作类型这些如果散落在代码里用魔法数字表示，调试的时候会非常痛苦。我专门定义了一个BorrowStatusEnum，把"借出中、已归还、逾期未还、已预约"这些状态全部收敛起来，任何地方要用状态判断都从这里取，避免出现"1代表什么、2代表什么"这种记忆负担。

2.3 自助终端的设备对接方案

无人图书借阅系统的自助终端，硬件上一般由三部分组成：触屏显示设备、扫码枪/条码扫描器、身份证/校园卡读卡器。这套源码里我抽象了DeviceAdapter接口：

java复制public interface DeviceAdapter {
    // 识别读者身份信息，返回读者编号
    ReaderInfo identifyReader() throws DeviceException;
    // 扫描图书条码，返回图书编号
    String scanBook() throws DeviceException;
    // 门禁放行控制（可选）
    void openGate(boolean allow);
}

实际对接时会有两种方式：一种是读卡器和扫码枪通过串口或USB连接，由终端浏览器调用本地服务接口转发数据；另一种是直接用WebUSB或WebSocket对接。考虑到大多数场景用的是普通触屏一体机，我推荐用第二种里的WebSocket方案——终端机跑一个轻量级的本地代理程序（源码里附带了一个netty-websocket小服务），负责读取串口数据并通过WebSocket推送到浏览器页面。这样做的好处是页面代码不依赖特定硬件厂商的SDK，换一个品牌的读卡器只需要改本地代理程序，前端一行代码都不用动。

如果你不想搞硬件，想先跑通流程，源码里还提供了一个模拟模式。在application.yml里配置device.mock-enabled=true后，页面上会直接出现"模拟刷卡"和"模拟扫描"按钮，方便纯软件环境下的测试。

3. 数据库设计：把业务规则落到表结构

3.1 核心表结构一图看懂

数据库是整个系统的地基。这块设计不好，后面写业务逻辑的时候会不断返工。我把表拆成了五张核心表加两张辅助表：

表名	用途	关键字段
reader	读者信息	id, reader_no, name, phone, password, status, borrow_count
book_info	图书信息	id, barcode, isbn, title, author, category, location, status, borrow_times
borrow_record	借阅记录	id, reader_id, book_id, borrow_time, due_time, return_time, fine, status
reservation	预约记录	id, book_id, reader_id, reserve_time, pick_up_deadline, status
fine_record	罚款记录	id, reader_id, borrow_record_id, amount, reason, status
operation_log	操作日志	id, operator_type, operator_id, action, detail, create_time
admin_user	管理员账户	id, username, password, role

这里重点说三个容易被忽视的设计。

第一，封面图和ISBN。book_info表里存isbn字段，封面的做法是前端根据ISBN调用豆瓣或京东的开放接口实时获取，不落库。这样省去图片存储的麻烦，也不占数据库空间。当然如果内网环境无法访问外网，源码里也留了本地封面上传的接口。

第二，fine_record单独成表，而不是在borrow_record里加一个金额字段。原因在于罚款可能会涉及减免、补缴、多次调整等操作，每次变更都应该有一条独立记录，方便审计。borrow_record里保留一个当前欠款金额的冗余字段，用于查询效率，但真正的流水以fine_record表为准。

第三，所有的时间字段都用datetime而不是timestamp。MySQL里timestamp的范围只到2038年，而且跟时区绑定，很容易出问题。datetime就没有这个坑。同时，借阅系统涉及大量的"应还时间"计算，所有时间统一用服务器本地时间，不要用客户端传过来的时间，防止读者自己调整设备时间钻空子。

3.2 图书状态的完整生命周期

图书的status字段我设计了五个取值，这五个状态构成一本书在系统里的完整生命周期：

text复制IN_LIBRARY（在馆） -> LENT_OUT（已借出） -> IN_LIBRARY（已归还）
IN_LIBRARY -> RESERVED（已被预约）
RESERVED -> LENT_OUT（预约者成功借走）
RESERVED -> IN_LIBRARY（预约者超时未取，自动释放）
LENT_OUT -> LOST（报失） / DAMAGED（破损）

这些状态转换看起来简单，但真正写代码的时候，每个转换背后都要考虑边界情况。比如"在馆图书被预约"后，如果有读者想直接借阅，系统应该拦截并提示"该书已被预约，请选择其他图书"。再比如"借出中的图书被预约"，读者还书时，系统会自动把归还操作改成"转入预约保留区"而不是直接上架，同时通知预约者前来取书。

状态机如果散落在service层里到处if/else，后期加需求会疯掉。我建议把状态转换写成一个独立的StateMachine类，所有状态变更走统一入口。这样要做状态流转的合法性校验、操作日志记录、消息通知，都在一个地方处理。源码里这个类在service/impl/BookStateMachine.java中，核心逻辑大约150行，是系统里改动最频繁、也最需要保证正确性的部分。

4. 借还书核心流程的实现细节

4.1 借书流程：从扫码到记录落库

借书的交互流程是这样的：读者在自助终端刷卡验证身份，然后把书放到扫描区扫码，系统校验通过后完成借阅。看源码之前，先把这个流程的校验顺序理清楚——顺序错了，可能出现用户借到书但系统没记录，或者系统记录了但用户已经带书离开的情况。

借书操作的service方法签名是：

java复制@Transactional(rollbackFor = Exception.class)
public BorrowResult borrowBook(String readerNo, String barcode) {
    // 1. 校验读者身份和状态
    Reader reader = checkReaderStatus(readerNo);
    // 2. 加Redis锁，防止同一本书并发借出
    String lockKey = "lock:book:" + barcode;
    boolean locked = redisTemplate.opsForValue()
            .setIfAbsent(lockKey, "1", Duration.ofSeconds(5));
    if (!locked) {
        throw new BizException("图书正在被其他读者操作，请稍后再试");
    }
    try {
        // 3. 校验图书状态，必须为在馆且未被预约
        BookInfo book = checkBookAvailable(barcode);
        // 4. 校验借阅数量上限
        checkBorrowLimit(reader);
        // 5. 锁定图书状态
        book.setState(BookStatus.LENT_OUT);
        bookMapper.updateById(book);
        // 6. 计算应还时间（默认30天）
        LocalDateTime now = LocalDateTime.now();
        LocalDateTime dueTime = now.plusDays(
                config.getBorrowDays()
        );
        // 7. 插入借阅记录
        BorrowRecord record = new BorrowRecord();
        record.setReaderId(reader.getId());
        record.setBookId(book.getId());
        record.setBorrowTime(now);
        record.setDueTime(dueTime);
        record.setStatus(BorrowStatus.BORROWED);
        borrowRecordMapper.insert(record);
        // 8. 更新读者的当前借阅数量
        reader.setBorrowCount(reader.getBorrowCount() + 1);
        readerMapper.updateById(reader);
        // 9. 记录操作日志
        operationLogService.log("BORROW", reader.getId(), 
                "借出图书: " + book.getTitle() + " 条码: " + barcode);
        return BorrowResult.success(record);
    } finally {
        redisTemplate.delete(lockKey);
    }
}

注意几个细节。事务注解rollbackFor = Exception.class是必须的，Spring默认只在碰到RuntimeException时回滚，如果业务代码里抛的是自定义CheckedException，不加rollbackFor的话数据就悬空了。Redis锁的过期时间设为5秒是经验值，借书流程涉及的数据库操作一般在几百毫秒内完成，5秒足够。但要注意，如果锁过期了而方法还没执行完，一个极端情况是另一个请求进来同时借同一本书，解决方案有Redisson的看门狗机制，但对这个场景来说，锁定时间内的操作基本不会超过几十毫秒，加上数据库层面books表状态更新本身也是行锁，实际安全性是有兜底的。

4.2 还书流程：逾期计算与状态变更

还书流程比借书流程更复杂，因为牵扯到逾期罚款。无人值守场景下，如果读者借了书不还，到期后系统必须自动计算违约金，并且在读者下次借书的时候拦住他——这些逻辑全部要自动化。

还书操作的核心方法：

java复制@Transactional(rollbackFor = Exception.class)
public ReturnResult returnBook(String barcode) {
    // 1. 根据条码查借阅记录，找到状态为借出中的记录
    // 2. 计算是否逾期
    BorrowRecord record = getBorrowingRecordByBarcode(barcode);
    LocalDateTime dueTime = record.getDueTime();
    LocalDateTime now = LocalDateTime.now();
    long overdueDays = Duration.between(dueTime, now).toDays();
    // 3. 生成罚款记录 
    if (overdueDays > 0) {
        BigDecimal amount = config.getFinePerDay()
                .multiply(BigDecimal.valueOf(overdueDays));
        FineRecord fine = new FineRecord();
        fine.setBorrowRecordId(record.getId());
        fine.setAmount(amount);
        fine.setStatus(FineStatus.UNPAID);
        fineRecordMapper.insert(fine);
        record.setFine(amount);
    }
    // 4. 更新借阅记录状态为已归还
    record.setReturnTime(now);
    record.setStatus(BorrowStatus.RETURNED);
    borrowRecordMapper.updateById(record);
    // 5. 检查是否有预约
    Reservation reservation = reservationMapper
            .selectOne(new LambdaQueryWrapper<Reservation>()
                .eq(Reservation::getBookId, record.getBookId())
                .eq(Reservation::getStatus, ReservationStatus.WAITING)
                .last("LIMIT 1"));
    if (reservation != null) {
        // 转入预约保留状态，通知预约者来取书
        book.setState(BookStatus.RESERVED);
        notifyReservationReader(reservation);
    } else {
        book.setState(BookStatus.IN_LIBRARY);
    }
    bookMapper.updateById(book);
    // 6. 更新读者借阅数量
    reader.setBorrowCount(reader.getBorrowCount() - 1);
    readerMapper.updateById(reader);
    return ReturnResult.success(overdueDays, fineAmount); 
}

逾期天数这里有个小坑要提醒你：不要直接用两个LocalDateTime相减算天数差值，得先取到日期再算。否则读者晚上11点50分还书，实际只超过截止时间10分钟，也会被算成逾期一天，读者肯定要投诉。正确做法是：

java复制long overdueDays = Duration.between(
        dueTime.toLocalDate().atStartOfDay(),
        now.toLocalDate().atStartOfDay()
).toDays();
if (overdueDays > 0 && now.isAfter(dueTime)) { /* 才算逾期 */ }

额外处理一个边界：如果还书时间刚好等于dueTime，则视为按期。这个if判断一定要有，否则等于时间戳一样的情况下，Duration算出来是0，问题不大；但要是晚了一秒而两边的日期都取当天凌晨，会把不足一天的逾期漏掉。

4.3 并发场景的兜底逻辑

前面提到Redis锁解决同一本书的并发借阅，但还书和借书之间同样存在并发问题。比如读者A在还某本书的同时，读者B在自助终端上借同一本书——如果你只靠Redis锁，B在扫码时A还没还完，锁没有生效，B查询到的图书状态可能还是已借出，直接被拦截。

真正稳妥的方案是在数据库层面再兜一层。book_info表里的status字段更新时用乐观锁控制，即update语句带条件：

sql复制UPDATE book_info SET status = #{newStatus} 
WHERE id = #{bookId} AND status = #{expectedStatus}

如果影响行数为0，说明状态已经变了，当前请求需要重新查询最新状态并提示"图书状态已变化，请重试"。MyBatis Plus的@Version注解可以实现自动的乐观锁版本控制，但需要注意它在批量更新和自定义SQL时不一定生效，我倾向于在关键状态变更的地方手写带条件的update，这样执行计划可控、报错信息也清晰。

另外还有一个容易忽略的并发点：同一个读者在多个自助终端上同时操作。借书前要检查该读者的当前借阅数量，这个检查结果可能不准确。解决办法是把读者借阅数量上限的校验和更新做成一个原子SQL操作：

java复制int updated = readerMapper.decreaseBorrowCount(
        readerId, maxLimit, currentCount);

如果更新行数不为1，说明并发下别的终端已经占用了名额。

5. 无人值守场景的安全与容错设计

5.1 身份认证与防冒用

无人值守系统里最大的安全问题，是怎么确认"屏幕前操作的人就是卡片的主人"。很多人觉得校园卡或者身份证本身能证明身份，但实际场景中，拾获他人卡片去借书、甚至盗用图书的事情并不少见。这个问题从软件层面做完整闭环很难，但可以做几层围栏。

第一层，卡号加密码。自助终端要求输入卡密码，密码连续错误5次锁定30分钟。这5次错误尝试也意味着可以防止暴力破解。第二层，借阅数量与历史行为画像。同一账号短时间内连续借大量书籍，触发异常告警，推送管理员审核。第三层，操作门禁联动。如果硬件条件允许，借书成功后门禁才放行；如果自动门成本太高，可以在自助终端旁边贴一张提示，配合监控摄像头使用。

代码层面，登录状态用JWT管理，终端页面每次请求都在拦截器里校验token。给读者端签发的是短期token（默认30分钟），因为自助终端的操作都是短流程，长了容易被人利用已在登录状态的终端。管理员端的token有效期看需求，但必须要做单点登录，同一管理员账号同时只能在一处登录，避免管理员的信息被冒用。

5.2 设备异常与数据一致性兜底

自助终端最怕的场景是什么？扫码枪读到条码，读者把书放到了架子上，但系统在写库的过程中服务器宕机了。结果是读者以为借成功了，但系统没有记录，书就这么消失了。

这类问题的本质是硬件操作与数据操作的原子性无法保证。我采用的兜底策略是"操作前置确认"：在借书流程里，页面扫码成功之后，不立即调用后端借书接口，而是先弹出一个确认框，展示书名、作者、借阅截止时间，同时播放语音提示"请确认您要借阅这本书"，等用户点击确认后再真正执行借书。还书流程类似，还书前要求用户把书放到指定区域。

这样做的另一个好处是防止误扫码。触屏设备上扫码枪一次可能扫两次，弹确认框能阻断大部分误操作。还有一个细节：每个借书请求在Redis里加一个自增的请求流水号，前端生成请求时带上这个流水号，后端做幂等校验。即使用户在页面上重复点了两次"确认借阅"，第二次请求也会因为同一个流水号被拦截，不会生成两条借阅记录。

5.3 日志审计与告警通知

无人值守系统一旦出事，复盘全靠日志。operation_log表记录了每一次借书、还书、登录、修改等操作，包含操作人、操作时间、操作内容和IP地址。但光记录还不够，要能在异常发生时主动通知管理员。

我实现的方式是在OperationLogService里内置一个简单的规则引擎，碰到以下情况自动发企业微信/钉钉机器人消息：

同一账号2小时内借书超过10本
同一本书24小时内被借还超过3次（可能有人利用系统测试漏洞）
读者连续5次密码错误触发锁定时
还书超时超过30天仍未归还
管理员账户登录异常（非工作时间登录）

告警消息推送用Spring的事件机制实现，OperationLogService发布ApplicationEvent，监听器里异步发送webhook请求。这样做的好处是主业务链路不依赖消息通知服务的可用性，推送失败也不影响借还书流程。

6. 源码如何跑起来与避坑建议

6.1 项目启动的环境准备

仓库地址我放在Gitee上，项目名library-unmanned。把代码clone下来之后，按下面步骤操作：

安装JDK 8以上版本（推荐JDK 11，Spring Boot 2.7官方支持）
安装MySQL 8.0，执行sql/init.sql脚本初始化数据库
安装Redis并启动，默认端口6379
修改application-dev.yml里的数据库账号密码、Redis配置
运行LibraryUnmannedApplication.java启动类
浏览器访问http://localhost:8080/admin进行管理员登录验收，默认管理员账号admin/admin123

6.2 模拟模式怎么看效果

没有硬件设备时，打开application.yml配置device.mock-enabled=true启动项目。自助终端页面路径是/terminal，打开后会看到模拟操作区，点击"模拟刷卡"会弹出一个输入框，随便输一个已存在的读者编号就能通过身份认证。扫面图书同理，输入图书条码即可。源码的SQL初始化脚本里预置了10本测试图书和5个读者账号，跑起来可以直接做完整的借还流程测试。

6.3 几个我踩过的坑

第一个坑是MySQL 8.0的时区问题。连接MySQL 8.0时，JDBC的serverTimezone参数如果不设，会报"server time zone value"错误。这个错误本质上是MySQL 8.0默认时区是美国，跟中国差了8个小时，而且它要求客户端连接时明确指定时区。解决办法是在JDBC URL里加上serverTimezone=Asia/Shanghai。注意不要直接加&useSSL=false就完事，时区和SSL是两个独立参数，缺一个都可能出问题。

第二个坑是MyBatis Plus的字段映射。数据库字段名为borrow_time，Java实体字段名为borrowTime，默认的驼峰转下划线映射在大部分场景下能正常工作。但如果你用了@TableField注解或写自定义SQL，必须小心。我遇到过统计逾期数量时SQL里写的是borrow_time as borrowTime，结果查询结果映射不到实体上，返回的count一直为0。后来排查发现是返回的列名是borrowTime，但MyBatis Plus的默认映射规则会把驼峰再转回下划线去找列，找不到就置为null。解决办法是查出来的结果用resultType="map"或者显式set别名。

第三个坑是前端页面在触屏设备上的适配。普通的PC端页面在触屏一体机上看起来没问题，但操作按钮太小，读者手指点不中。这个属于体验问题但会直接影响借阅成功率。源码的terminal页面针对触屏做了一些适配，按钮最小高度44px，重要操作之间的间距加大。如果你的终端分辨率跟我预置的不一样，需要重新调整页面样式，这个没有捷径，只能拿真机去调。

第四个坑是关于PDF导出功能的。图书借阅记录和罚款记录需要支持导出报表，我一开始用的POI生成Excel文件，在本地测试没问题，部署到Linux服务器后发现导出的文件打不开。查日志发现是缺少字体导致的——Linux服务器没有安装微软雅黑，POI生成Excel时如果单元格里有中文，默认字体找不到就会报错。这个问题的标准解决方案是在服务器上安装常用的中文字体包，或者在导出代码里显式指定一个Linux环境可用的中文字体，比如"WenQuanYi Zen Hei"。

6.4 后续扩展方向

这套系统的当前版本还比较克制，我把很多硬件相关的功能做了接口抽象但没往深做。如果你有条件和需求，接下来比较有价值的扩展方向有三个。

一是接入人脸识别。现在很多图书馆的通宵自习室里，人脸的识别精度已经足够高。把DeviceAdapter里identifyReader的默认实现换成对接百度AI或飞桨的人脸接口，就能实现刷脸借书，体验会好很多，而且能从一定程度上解决盗用卡片的问题。

二是RFID盘点。把图书的barcode条码换成RFID标签，在书架上部署RFID读取天线，可以定时自动盘点在架图书，发现错架、丢失的书第一时间告警。这部分硬件成本会高一些，但逻辑上就是在现有系统上加一个inventory_report的定时任务。

三是借阅数据分析。只要把borrow_record表积累的数据利用起来，就能做热门图书排行、读者兴趣画像、单馆图书周转率分析。这对大一点的图书室来说非常有用，也是系统从"管书"走向"服务读者"的重要一步。

无人图书借阅系统这个项目做完，我最大的体会是：业务系统的复杂度从来不在技术，而在流程设计。一个借书接口，表面上只是状态更新和记录插入，但真正要把无人值守场景下各种异常情况都处理好，需要你在设计表结构的时候就想清楚状态机，在写代码前就想好并发边界，在部署前就想好设备异常怎么兜底。技术选型反而是最简单的部分——Spring Boot加MyBatis Plus这个组合足够可靠，剩下的就看你怎么把业务规则翻译成代码了。希望这份源码能帮你在做类似项目的时候少走几个弯路。