Spring Boot + 微信小程序：面向小学生的阅读交流系统开发实战

毕设季又到了，每年这个时候总能看到一堆人抱着“基于SSM的XX管理系统”这类题目来回折腾。今天想借我这边最近带过的一个项目，聊聊一个比较有代表性、也很有话题度的选题——面向小学生的阅读交流系统，技术栈是 Spring Boot 后端 + 微信小程序前端。

这个选题好在哪里？首先它在教育信息化这个大类里，方向本身就具备现实意义；其次技术上覆盖了后端接口开发、小程序端渲染、本地缓存、鉴权、数据库设计、部署上线整个链路，拿来当毕设、作为项目经历写进简历，说服力都不差。这篇文章我会从题目选定、功能模块拆解、数据库设计、后端实现、小程序端开发、文档撰写、答辩准备到后期定制服务，完整地把一条龙的做法讲清楚。文章很长，适合收藏下来慢慢对着做。

1. 为什么我建议把“小学生阅读交流”作为毕设题目

1.1 这个题目的价值点不只是“能交差”

先聊聊选题。指导老师和答辩组通常看什么？一看工作量够不够，二看技术栈新不新，三看系统有没有实际应用场景。这三个标准，“小学生阅读交流系统”刚好全部踩中。

工作量很好堆：学生端要有图书浏览、借阅、打卡、记录阅读心得；教师端要有班级管理、阅读任务下发、数据统计；管理后台要能管书库、管用户、管审核。光是这几个模块，数据库表就能设计出十几张，代码量轻松破万行，文档写起来素材充足。

技术栈层面，Spring Boot 是当前企业开发的事实标准，微信小程序又不依赖 App 上架流程，纯个人开发也能在开发者工具里完成全部调试和体验。两者结合，后端接口可以按小程序端的需求拆分，前端页面也不需要太多花哨的东西。关键是在线教育、亲子共读这类方向的系统，商业上已经被验证过，答辩论据充分。

应用场景就更不用愁了。小学生阅读打卡、阅读存折、读书心得交流，这些都是真实的校园需求。某小学图书角的阅读记录，有的至今还在用纸质本子。你把这个流程电子化，答辩时讲“系统解决了纸质记录易丢失、统计困难、教师无法及时掌握学生阅读进度”这类痛点，老师一听就明白，不用费劲解释“你的系统是干什么的”。

1.2 题目怎么包装更讨巧

有同学直接把题目定为“基于Spring Boot的读书管理系统”，不能说错，但显得平淡。我建议在表述上加一点限定词，比如“面向小学生的阅读交流系统”，一下子就有了目标用户画像，系统的功能设计、界面风格、安全策略都要围绕“小学生”这个群体展开，而不再是一个通用业务系统。

如果你做的是简化版，也可以叫“小学班级图书角管理小程序”，把范围缩小到班级场景。题目越小越具体，越容易做出深度，答辩时越不容易被追问到答不上来。

2. 系统骨架：从用户故事到数据库表结构设计

2.1 用户角色与功能拆解

拿到题目后第一步不是写代码，而是把角色和功能画清楚。这个系统我设计了三种角色：

有些同学想省事，把教师和管理员合并成一个角色，也可以，但答辩时工作量体现得不够。建议拆开，后台不需要做太复杂，能登录、能对核心表做 CRUD、能看到统计数据，就已经符合“前后端分离完整项目”的定位，配合小程序端，是一个完整的全栈项目。

2.2 数据库设计：一张表也别浪费

数据库是答辩时被追问的高发区，表结构设计一旦有硬伤很容易被看出来。这个项目里，我实际落地了 12 张表，核心的 8 张先列出来：

• student（学生表）：openid、昵称、头像、所在班级、积分、阅读等级、创建时间。
• teacher（教师表）：工号、姓名、任教班级、登录密码（BCrypt 加密）。
• book（图书表）：ISBN、书名、作者、出版社、封面图、分类、馆藏数量、可借数量、简介。
• borrow_record（借阅记录表）：学生ID、图书ID、借出时间、应还时间、实际归还时间、状态。
• reading_task（阅读任务表）：教师ID、班级、任务标题、必读书目要求、截止时间。
• reading_note（读书笔记表）：学生ID、图书ID、笔记内容、字数统计、是否公开、审核状态。
• checkin_record（打卡记录表）：学生ID、日期、打卡内容、连续打卡天数。
• book_review（书评/交流表）：学生ID、图书ID、评价内容、星级、点赞数、评论状态。

表关系上注意几点：借阅记录和图书的关系是多对一，读书笔记和学生是多对一，打卡表需要做“学生+日期”的联合唯一索引，防止同一天重复打卡。要说明的一点是，这套表结构做了适度的冗余设计，比如借阅记录里直接存了“应还时间”，没有每次动态计算，简化了业务逻辑，你答辩时可以说这是“以空间换时间”的思路，前提是能自圆其说。

积分和排行的逻辑也要提前想好：每本书首次借阅得 10 分，每篇审核通过的笔记得 20 分，连续打卡每天额外加 5 分。这个规则在小程序端是明文展示的，给学生一个明确的“升级路径”。积分不是简单存一个总数字，而是通过流水表记录每一次积分变化，否则以后想追溯“这个学生的积分怎么来的”就傻了。

2.3 环境准备与技术选型基准

开发环境建议用统一的版本，避免迁移到别的电脑就崩：

这里有个很容易踩的坑：MySQL 8.0 默认的认证插件是 caching_sha2_password，老版本的数据库驱动可能连不上，要么把驱动升级到 mysql-connector-java 8.0 以上，要么建用户时指定 mysql_native_password。我见过太多人卡在这里半小时起步。

3. 后端核心实现：从登录鉴权到借阅闭环，每一个坑都说明白

3.1 学生端微信登录与 openid 绑定

小程序端的登录流程，网上资料一大把，但新手最容易混淆一个概念：wx.login 拿到的 code 不是用户身份，code 换来的 openid 才是。

流程是：小程序调用 wx.login() 拿到临时 code，把 code 发给后端；后端拿 code + appid + secret 去微信接口服务交换 openid；拿到 openid 后，先去 student 表查有没有这条记录，没有就自动注册一个新用户，然后返回一个自定义登录态 token 给小程序。

后端实现上，我在 UserController 里写了一个登录接口：

java复制@PostMapping("/wx/login")
public Result wxLogin(@RequestBody WxLoginRequest request) {
    // 1. 拿 code 换 openid
    String url = "https://api.weixin.qq.com/sns/jscode2session?appid=" + appId
            + "&secret=" + appSecret + "&js_code=" + request.getCode()
            + "&grant_type=authorization_code";
    String result = restTemplate.getForObject(url, String.class);
    JSONObject json = JSON.parseObject(result);
    String openid = json.getString("openid");
    
    // 2. 查库绑定用户
    Student student = studentMapper.findByOpenid(openid);
    if (student == null) {
        student = new Student();
        student.setOpenid(openid);
        student.setNickname("阅读者" + RandomUtil.randomNumbers(4));
        studentMapper.insert(student);
    }
    
    // 3. 生成自定义 token 返回
    String token = JwtUtil.generateToken(student.getId(), student.getOpenid());
    return Result.success(token);
}

注意点一：jscode2session 接口是 GET 请求，网络超时偶尔会发生，这里要做超时重试或返回友好的错误提示，不要直接抛异常。注意点二：不要在前端把 openid 存在本地当登录凭据，openid 本身不是秘密，但也绝不能在小程序端传来传去，后端返回自定义 token 统一管理会话，这是安全底线。

3.2 基于 JWT 的会话管理与接口拦截

我选了 JWT（JSON Web Token）做登录态，原因很简单：无状态、扩展方便、小程序端只要在请求头里带上 Authorization 字段即可。后端用一个拦截器统一校验：

java复制public class JwtInterceptor implements HandlerInterceptor {
    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        String token = request.getHeader("Authorization");
        if (token == null || !JwtUtil.verify(token)) {
            response.setStatus(401);
            return false;
        }
        // 把用户信息塞进 request 上下文
        Integer studentId = JwtUtil.getStudentId(token);
        request.setAttribute("studentId", studentId);
        return true;
    }
}

配置类里指定拦截路径：

java复制registry.addInterceptor(jwtInterceptor)
        .addPathPatterns("/api/**")
        .excludePathPatterns("/api/wx/login", "/api/book/list", "/api/book/detail");

注意把 /api/wx/login 放行，同时有些公开接口比如图书列表、图书详情，为了减少前端“未登录无法浏览”的尴尬，我也放行了。但写笔记、借书、打卡这些操作接口必须拦截，这是保护用户数据的最基本姿势。

JWT 工具类要注意一点：生成 token 时别把学生 id 直接明文放 payload，_base64 解码谁都能看，我一般把 claims 里的字段名做个混淆（比如不叫 studentId 而叫 sub），或者至少给敏感数据加一层处理。你不需要做到银行级安全，但别让答辩老师一眼看出“你这 token 里能直接读到数据库自增 id”。

3.3 借书与还书：事务一致性怎么处理

借书看着简单，里面有很多细节。我在 BorrowService 里写了一个借书方法，你重点看两个地方：

java复制@Transactional(rollbackFor = Exception.class)
public Result borrowBook(Integer studentId, Integer bookId) {
    // 1. 判断学生是否存在违约记录（如超期未还）
    int overdueCount = borrowRecordMapper.countOverdueByStudent(studentId);
    if (overdueCount >= 3) {
        return Result.error("存在超期未还记录，暂不能借书");
    }
    
    // 2. 查书，锁定可借数量
    Book book = bookMapper.selectByIdForUpdate(bookId);
    if (book == null || book.getAvailable() <= 0) {
        return Result.error("图书暂无可借库存");
    }
    
    // 3. 扣减库存 + 生成借阅记录
    bookMapper.decreaseAvailable(bookId);
    BorrowRecord record = new BorrowRecord();
    record.setStudentId(studentId);
    record.setBookId(bookId);
    record.setBorrowTime(new Date());
    // 设定借阅周期，比如 14 天
    record.setDueTime(DateUtil.offsetDay(new Date(), 14));
    record.setStatus(0); // 0 借出 1 已还 2 超期
    borrowRecordMapper.insert(record);
    
    // 4. 增加积分和流水
    studentMapper.increasePoints(studentId, 10);
    pointRecordMapper.insert(studentId, "借阅图书", 10);
    
    return Result.success();
}

关键细节都在注释里：

• selectByIdForUpdate 是行级锁，防止并发借书时库存被超卖。这个知识点面试和答辩都爱问，你要能说出“悲观锁的一种应用方式”。
• @Transactional 保证扣库存、写借阅记录、加积分要么全部成功要么全部回滚。
• 超期次数的限制，算是业务层面的一个规则，体现系统不是简单 CRUD，而是有业务逻辑判断的。

还书流程对称，更新借阅记录状态、回补库存、有超期就更新为“超期已还”并把积分扣回来。还有，凡是涉及积分的操作，数据库里既要改总分也要记流水，这一点很多人不做流水，答辩被追问时说不出溯源方案，就露怯了。

3.4 定时任务处理超期订单

超期订单不能全靠用户还书时被动判断。我在项目里用 Spring 自带的 @Scheduled 写了一个定时任务，每天凌晨扫描一次所有状态为“借出中”且 due_time 早于当前时间的记录，把状态改为超期，并冻结对应学生的借书权限：

java复制@Scheduled(cron = "0 0 2 * * ?")
public void processOverdueRecords() {
    List<BorrowRecord> overdueList = borrowRecordMapper.selectOverdueList();
    for (BorrowRecord record : overdueList) {
        record.setStatus(2);
        borrowRecordMapper.updateStatus(record);
    }
    // 同时把超期学生的状态置为不可借
    studentMapper.freezeOverdueStudents();
}

这个逻辑简单，但答辩时可以往深了讲：为什么要定时任务？因为被动触发会漏；为什么半夜两点跑？因为业务低峰期；为什么不用 Quartz？因为 Spring 自带的调度够用，少一个依赖少一处配置出错的风险。这种“为什么”答得越清晰，越能证明这不是抄来的代码。

3.5 教师端与后端的权限设计

教师端和学生端复用小程序，那接口就要做角色区分。我在 JWT 的 payload 里存了 role 字段，拦截器里只做登录校验，真正做权限控制的是在接口方法上加一个自定义注解 @RequireRole("teacher")。

比如发布阅读任务这个接口：

java复制@RequireRole("teacher")
@PostMapping("/task/add")
public Result addTask(@RequestBody ReadingTask task) {
    taskMapper.insert(task);
    return Result.success();
}

一种更工程化的替代方案是引入 Spring Security 或 Shiro，但对于毕设项目，自研一个轻量注解开销更小、逻辑更直观，而且答辩时可以讲清楚“我自定义了一套 RBAC 简化模型”。不要贪多，安全框架引入得越重，越容易在被追问时暴露细节漏洞。

3.6 文件上传：图书封面的本地存储方案

图书封面图、学生头像这些图片，最省事的方案是上传到本地服务器目录，数据库只存一个相对路径。后端接收前端的 multipart/file 请求后：

java复制String originalFilename = file.getOriginalFilename();
String fileName = System.currentTimeMillis() + "_" + originalFilename;
File dest = new File(uploadDir + fileName);
file.transferTo(dest);
String url = "/images/" + fileName;

而这个 /images/** 路径，需要在 WebMvc 配置里映射到物理目录：

java复制registry.addResourceHandler("/images/**")
        .addResourceLocations("file:" + uploadDir);

我这里没有推荐用 OSS 对象存储，原因是毕设项目用本地存储部署简单、零成本，但要意识到本地存储的问题：服务器重启或迁移时图片容易丢、磁盘占用不可控。如果项目要部署到云端，换成 OSS 也就是引入一个 SDK 的事，代码改动不大。答辩时你可以提一句“生产环境可以替换为云对象存储”，显得有架构意识。

4. 小程序端实现：不只是套模板，交互设计要贴合小学生

4.1 页面结构：从 TabBar 到核心页面

微信小程序端的页面规划，我建议四到五个 Tab 已经足够：

• 首页：轮播图、今日推荐书单、最新书评、公告栏。
• 书架/书库：列表+搜索+分类筛选，展示图书封面、简介、可借数量。
• 任务中心：教师的阅读任务、打卡入口、读书笔记入口。
• 消息/动态：同学公开的书评动态，可以点赞。
• 我的：个人信息、借阅记录、积分排行、我的笔记。

这五个 Tab 合起来就是一个完整的核心体验闭环：浏览 → 借阅 → 打卡 → 写笔记 → 看排行。页面不在多，而在每张页面都能说清楚“为什么要有它”。

图书列表用一个 book-card 自定义组件，组件内部包含封面图、书名、作者和“可借/已借完”状态。注意状态视觉区分很关键，小学生识字能力有限，要用颜色和图案暗示状态：绿色表示可借，红灰色表示已借完，卡片上直接覆盖标签而不是让用户点进详情才发现。

4.2 请求封装与 loading 状态

小程序端我封装了一个 request.js，统一设置 baseURL 和 header：

javascript复制const request = (url, method = 'GET', data = {}) => {
  return new Promise((resolve, reject) => {
    wx.request({
      url: baseUrl + url,
      method: method,
      data: data,
      header: {
        'Content-Type': 'application/json',
        'Authorization': wx.getStorageSync('token')
      },
      success: (res) => {
        if (res.statusCode === 401) {
          // token 失效，回登录页
          wx.reLaunch({ url: '/pages/login/login' });
          reject(res);
        } else if (res.data.code === 200) {
          resolve(res.data);
        } else {
          wx.showToast({ title: res.data.msg, icon: 'none' });
          reject(res);
        }
      },
      fail: (err) => {
        wx.showToast({ title: '网络异常，请稍后再试', icon: 'none' });
        reject(err);
      }
    });
  });
};

核心点：把 401 统一处理、把业务错误码统一 toast、把成功数据统一解包，这样页面代码里就不会每处都写一堆错误分支。另一个小细节，交互按钮在请求期间要加防重复点击，比如打卡按钮，小学生连点两下就产生两条重复记录了，后端虽然有唯一索引兜底，但前端的 disabled 状态也要做好。

4.3 打卡日历与连续天数计算

打卡页面我实现了一个日历视图，小学生每天点一下“今天打卡”，系统记录一条数据。计算连续打卡天数不查 MAX(date) 一条 SQL 就能出来，正确做法是查出该学生最近的所有打卡日期，然后在 Java 逻辑里从今天（或昨天）往前数连续区间：

java复制public int calcStreak(List<Date> checkinDates, Date today) {
    int streak = 0;
    Set<String> dateSet = checkinDates.stream()
            .map(d -> new SimpleDateFormat("yyyy-MM-dd").format(d))
            .collect(Collectors.toSet());
    Date cursor = today;
    for (int i = 0; i < 365; i++) {
        String key = new SimpleDateFormat("yyyy-MM-dd").format(cursor);
        if (dateSet.contains(key)) {
            streak++;
        } else {
            break;
        }
        cursor = DateUtil.offsetDay(cursor, -1);
    }
    return streak;
}

这段代码没啥难度，但答辩时可以讲的点是：为什么不用 SQL 的 COUNT + GROUP BY？因为连续天数的本质是“集合连续性判断”，纯 SQL 要写窗口函数，对 MySQL 版本有要求，而且可读性差。用 Java 内存逻辑处理 365 次循环，对单用户毫秒级完成，这是合理取舍。

4.4 阅读笔记编辑器：字数统计与敏感词过滤

小学生的书评输入要控制长度。我的笔记提交页面，输入框下方实时显示“还能写 300 字”，通过 bindinput 事件统计 value.length 并在超限时截断。

更重要的是后端不能轻信前端限制，ReadingNote 实体里的 content 字段设置了长度检查，超长直接报业务异常。还有一个小学生系统专属的需求：敏感词过滤。 小学生和同学之间的交流会产生吵架、辱骂的文本，我在后端维护了一个敏感词词表，用简单的含敏感词算法先过滤一遍（不追求正则效率，准确率优先），命中后把文本替换为 *。这个设计答辩时非常加分，因为它体现的是“面向小学生的系统必须考虑内容安全”的非功能性需求，而绝大多数同学根本不会往这个方向想。

5. 代码讲解与论文写作：毕设交付不是写完代码就结束

5.1 论文结构怎么搭，篇幅重心放哪里

代码写完，论文才是重头戏。通用结构无非是绪论、相关技术、需求分析、系统设计、系统实现、系统测试、总结展望，但篇幅重心有讲究。

我建议论文里把力气花在需求分析和系统设计两章，尤其是：

• 系统用例图 + 用例描述表格：每个角色每个核心功能一张表，表里写清前置条件、基本流程、异常流程。这一张表能占一页，而且答辩时“系统有哪些功能、流程是什么”随手拈来。
• 数据库设计：ER 图 + 每个表字段明细。12 张表每张表一个三线表格，字段名、类型、约束、含义，这就是五六页的工作量。
• 系统实现章节配核心代码：不要整段贴代码，挑关键方法贴，比如登录、借书、打卡计算连续天数，图个“过程性展示”，老师翻起来不费力。

需求分析里要讲角色。学生、教师、管理员三种角色的用例和权限边界逐条写清，这一块既是论文内容，也是后续代码讲解的提纲。一位答辩组老师曾经在私下交流时说，他最烦看到“用户登录后可以……”这种没营养的用例描述。写用例时加状态、加前置条件、加分支结果，比如“学生登录后可查询本人借阅记录，如存在超期记录则界面显示警示”，这个层次才到位。

5.2 代码讲解：模拟答辩现场该讲什么

代码讲解时间一般控制在 8 到 15 分钟，很多同学上来就照着 PPT 念，听的人昏昏欲睡。我的建议是按场景讲，先讲“用户从打开小程序到完成一次借书的完整请求链路”：

1. 小程序 wx.login() 拿到 code，发送给后端。
2. 后端调微信接口换 openid，在 student 表查重，生成 JWT 返回。
3. 小程序把 token 存到 storage。
4. 用户点击借书，前端带 token 调用 /api/borrow/add。
5. 拦截器校验 token，解析出 studentId。
6. 借书 service 加锁查库存 → 扣库存 → 写记录 → 加分 → 流水记录。
7. 前端刷新书架列表，弹出“借阅成功，请 14 天内归还”。

一个链路讲完，整个项目的全貌就浮出来了，后面的模块再逐个补充，老师就能建立“这个系统是一个整体，不是拼凑代码”的印象。

还有一个很值得讲的点：为什么后端接口返回统一结构 Result(code, msg, data)？ 统一返回结构的好处是前端封装请求只需要处理三种形态：成功、业务失败、系统异常。你顺着这个思路把 Result 类和全局异常处理器 @RestControllerAdvice 讲一遍，内容充实而且显得你懂工程化，不是只会写 CRUD。

5.3 文档里必须有的几张图

• 系统功能结构图：树状图，从系统拆到一级功能、二级功能。
• 系统架构图：展示小程序端、Spring Boot 后端、MySQL、微信接口服务之间的调用关系。
• 数据库 ER 图：学生-借阅-图书、学生-笔记-图书、教师-任务-学生几条核心关系链。
• 时序图：选登录和借书两个核心业务流程画。这里注意，正文里画图最好用绘图工具导出静态图片，不要用 Mermaid，因为转 Word 排版时会出现兼容问题。

这几张图只要逻辑对、命名规范、没有明显缺漏，基本不会被挑出大毛病。最怕的是画错关系，比如“学生和图书直接多对多”而忽略了借阅记录表，一看到底，老师就知道你没想清楚。

6. 部署上线与“一条龙定制”的常见问题处理

6.1 本地演示环境怎么搭最稳

答辩现场环境不可控，我见过太多人在演示环节翻车。经验就是把本项目封装成“开箱即用”的状态：

• 把数据库导出成一个 .sql 文件，里面包含建库语句、建表语句、测试数据。测试数据量要够，至少几十本书、十几个学生、若干条借阅记录，否则演示时书架页面光秃秃的很难看。
• 提供一个 startup.md 启动文档，写清“修改 application.yml 里的数据库账号密码→导入 sql→启动后端→打开小程序开发者工具导入前端项目→修改 appid 为测试号→编译运行”这五步。
• 后端端口固定 8080，小程序开发工具里不用 HTTPS 域名，勾选“不校验合法域名”，本地 localhost 就能直连。

小程序开发工具里本地调试有个坑：默认的 baseUrl 用 http://localhost:8080，但真机预览时 localhost 指向的是手机自己，不是电脑。解决办法是启动开发者工具时用“IP 地址 + 端口”形式，把 baseUrl 换成局域网 IP。这个细节没人提醒，能卡你半小时。

部署到云服务器的话，选最便宜的轻量应用服务器就行，1核2G跑一个 Spring Boot 应用绰绰有余，再用 systemd 配个自启动脚本。数据库用宝塔面板装好 MySQL，把 sql 导进去，小程序端 request 的 baseUrl 改成服务器的公网 IP 或域名（需备案）即可。

6.2 “程序+文档+代码讲解+一条龙定制”里，真正值钱的是哪部分

作为过来人说句实话，程序源码、论文文档只是交付的载体，真正的价值来自两个方面。

第一是代码讲解。代码是你写的，你才讲得清；如果是抄的，背半天也能露馅。我的习惯是给每个核心模块准备三句话：这个模块解决什么问题、用了什么技术点、有哪些可以优化的方向。比如“借阅模块解决了图书库存管理和超期风险，使用了乐观锁与事务，后续可以改成 Redis 缓存热点图书数量”，几句话就把深度拉起来了。

第二是定制能力。所谓一条龙服务，核心是在基础版本上面对不同需求做适配——有的学校要求把 Vue 后台换成 Thymeleaf 模板引擎，有的要加一个家长端角色，有的要接入人脸识别登录，这些都可以在现有架构上扩展。碰到这类需求，优先改配置而不是改核心代码，保住系统稳定性的同时把需求吃掉，这才是定制服务能长期运转的原因。

前阵子一位买过这套项目源码的同学发消息来，说答辩时老师指着一张数据库表问“这个 borrow_record 表为什么要存 borrow_time 和 due_time 两个时间字段，直接存一个借阅周期天数不行吗”。他按我当时讲过的思路答：两个时间字段便于直接做超期筛选和索引查询，天数只存在于业务规则层，时间戳才是事实数据，如果只存天数，必须用“借阅时间 + 天数”推算出应还时间，增加查询复杂度。老师点了点头，没有再追问。这件事给我很大触动——你的项目不管是不是自己写的，代讲的深度完全取决于是否把“为什么这样设计”想透。

6.3 代码交付与后期扩展建议

交付阶段需要打包的文件尽量提供一个清单：源码压缩包、数据库 SQL 文件、启动说明、论文 Word 版和 PDF 版、答辩 PPT、演示视频。视频可以录屏，从启动后端到小程序端把每个模块走一遍，录个五到十分钟，答辩时哪怕环境出问题，视频也能兜底。

系统后期扩展方向，除了前面提到的云存储、Redis、学生端消息推送（订阅消息），还可以考虑：

• 阅读报告自动生成：每周生成一份学生阅读周报，包含阅读时长、完成书目、积分变化，推送给教师和家长。
• 图书推荐算法：根据学生历史借阅类别和笔记高频词，做一个简单的基于内容的推荐，一套规则就能落地，未必非要上协同过滤。
• 语音朗读与评测：小学生识字有限，加入 TTS 朗读功能，让书摘能“听”，这个方向如果做出来，系统体验完全不一样。

以上这些都是可以在现有代码基础上不断迭代的增量功能。做毕设的原则是：先保证核心链路稳定跑通，再用扩展点展示你的思考。 代码别指望一次写完美，先把“借书→打卡→笔记→排行”这条主线完整打通，再补充管理员后台和统计图表，整个项目就已经远超“能过”的标准了。