Spring Boot + 微信小程序考研复习辅助平台：毕业设计实战详解

又到毕业设计开题季，后台收到最多的一类私信就是：“有没有适合做毕设的项目？最好技术栈常规、功能完整、答辩还有东西可以讲。”如果你也在找这类项目，那基于 Spring Boot + 微信小程序的考研复习辅助平台，真的值得认真研究一下。它表面上是帮考研学生做复习计划、打卡、刷题、记错题的小程序，但作为毕业设计，它同时覆盖了小程序前端、后端接口、数据库设计、登录鉴权、内容管理这些常见答辩考点，开发周期适中，上手门槛也不算高。这篇文章不打算讲那种浮在表面的功能介绍，而是把业务拆解、技术选型、数据库设计、核心接口、小程序实现、部署调试、文档答辩这些环节全部串起来，把我做这类项目时踩过的坑和攒下来的经验一次性说清楚。

1. 先想清楚业务再写代码：考研复习平台的定位与功能拆解

1.1 这个平台到底在解决什么痛点

很多同学拿到“考研复习辅助平台”这个题目，第一反应是“做一个背单词的App”或者“做一个刷题小程序”，这其实把题目理解窄了。考研复习的核心痛点不是单一功能可以覆盖的，而是集中在四个方面：复习计划散乱、学习过程没有记录、错题反复做错、资料和资讯东一份西一份。平台的名字里带“辅助”两个字，说明它不是一个教学系统，不是一个卖课系统，而是一个帮助学生“自己管理自己”的工具。

想清楚这一点非常重要，因为产品定位决定功能边界，功能边界决定数据库表怎么设计，表结构又决定接口怎么实现。如果一开始就把定位搞成“在线教育平台”，那后面可能要接视频、接支付、接直播，工作量直接翻倍，而且答辩时也容易被老师追问“为什么考研平台还需要支付功能”。把定位收敛到“复习辅助”，核心就是四件事：制定计划、记录进度、刷题训练、整理笔记。

这个定位放在毕业设计里还有一个隐性好处：业务闭环足够完整，但复杂度可控。计划的创建、打卡的记录、题目的练习、错题的归集，是一条完整的数据流，从用户操作一直贯通到数据库的增删改查，能体现出你对业务流程的理解，又不会因为题目太大而做不完。

1.2 用户端、管理端功能清单与答辩亮点

平台按照角色可以拆成用户端和管理端。用户端面向考研学生，管理端面向系统维护人员或内容运营人员。我建议功能清单按下面的表格来划分，每一项都给出它在答辩时能承担的角色。

从这个表格能看出来，功能清单不需要多花哨，但要覆盖“内容管理 + 用户行为 + 数据闭环”这三个层面。很多同学的毕设只有用户端，缺少管理端，答辩时老师一旦问“后台怎么维护数据”，就答不上来。而管理端哪怕只是简单的题库管理和文章管理，也能让整个系统看起来更完整。

另外，打卡和错题本这两个功能是我认为最值得强调的答辩亮点。打卡涉及“同一天不能重复打卡”的并发问题，错题本涉及“同一道题反复做错只保留一条记录并累加次数”的去重问题，这些都不是单纯的增删改查，能体现你对数据一致性的考虑。后文我会专门用一章讲这两个接口怎么实现。

2. 技术选型不是随便选的：Spring Boot + 微信小程序为什么合适

2.1 微信小程序做客户端，答辩时怎么讲才有说服力

考研复习辅助平台选微信小程序而不是独立的 Android/iOS App，很多人觉得是因为“小程序开发简单”，这个说法在答辩时其实站不住脚。更合理的解释是：考研学生使用场景高度碎片化，可能在食堂排队时刷几道题，可能睡前看一眼明天的计划，打开微信直接进入小程序，比下载一个独立 App 的成本低得多。这是产品层面的理由，比“开发方便”更有说服力。

从技术层面讲，微信小程序也足够完成复习辅助类应用的所有需求。比如页面栈和路由管理适合做多 Tab 结构，本地缓存适合保存登录 token 和用户偏好，wx.request 能满足绝大多数后端接口调用。还有一个容易被忽略的优势：小程序的 UI 组件和 API 文档非常规范，页面生命周期清晰，对没有太多前端经验的同学来说，学习曲线比 React Native 或 Flutter 要平缓不少。

2.2 Spring Boot 后端的分层设计与统一返回格式

后端选 Spring Boot 的理由不需要说太多，资料多、生态成熟、招人需求大，这几个词背下来就好。我更想说的是它在毕设里的实际优势：分层结构非常适合“可讲解”的场景。

建议把后端代码分成这样几层：Controller 层只负责接收参数和返回结果，Service 层处理业务逻辑，Mapper 层操作数据库，Entity 层映射数据表。这样做最大的好处是，答辩论“这个登录功能怎么实现的”时，你可以沿着请求路径一条线讲下来：小程序发起请求到 Controller，Controller 把参数交给 Service，Service 调用 Mapper 查用户表，拿到数据后生成 Token 返回前端。每一层职责清晰，老师一听就知道你的代码不是随便堆出来的。

再强调一个细节：统一返回格式。后端所有接口都应该返回同样的 JSON 结构，比如 { code: 200, message: "success", data: ... }。这样小程序端只需要写一个公共解析函数，就能处理所有接口的返回结果，不用每个接口单独写一套状态判断，代码会干净很多。

2.3 前后端接口约定：一次点击背后发生了什么

在写任何代码之前，先把前后端接口约定想好，能省掉后面联调时的大量沟通成本。我习惯用一个表格把接口清单列出来，包含路径、请求方式、入参、出参，写完发给前端同事或自己对照实现。以打卡接口为例：

当用户在小程序点击“今日打卡”按钮时，小程序端拼接用户信息，调用 wx.request 发起 POST 请求，后端接口先判断今天是否已经打过卡，如果没有就插入一条打卡记录，返回成功；如果已经打过卡，就返回“今天已打卡”的提示。这个过程看起来简单，但每一步都有设计空间，后面接口实现章节我会把具体代码写出来。

3. 数据库设计：几张表把业务闭环串起来

3.1 核心表结构与关联关系

数据库是毕业设计的重头戏。考研复习辅助平台不需要设计成几十张表的大系统，但核心表一定要能串起业务闭环。我建议至少设计以下七张表：用户表、复习计划表、打卡记录表、题目表、答题记录表、错题本表、笔记表。如果加入了资讯功能，再加一张文章表。

用户表最简单，核心字段是 openid、昵称、头像、创建时间。openid 是微信体系下的用户唯一标识，相当于用户在平台里的身份证。

复习计划表用来存放用户自己创建的计划，核心字段是用户 id、计划内容、计划日期、完成状态。要注意的是，用户可能一天建多条计划，所以外键和日期不能设计成唯一约束。

打卡记录表和复习计划表的关系要理清楚。打卡记录表示的是“某天是否来过”，不是“某个计划是否完成”。一张打卡记录表字段是用户 id、打卡日期、打卡时间，用“用户 id + 日期”做唯一索引，保证同一天只能有一条打卡记录。

题目表是题库的载体，字段建议设计成：科目类型（英语、数学、政治、专业课等）、所属章节、题干、选项内容、正确答案、解析。正确答案字段在数据库中必须存在，因为判题在后端完成，不能把正确答案暴露在小程序端。

答题记录表记录每次做题的情况，字段是用户 id、题目 id、用户答案、是否正确、作答时间。错题本表收藏错题，字段是用户 id、题目 id、错误次数、最近错误时间。这两张表看起来很像，但作用完全不同：答题记录是流水，记录每一次行为；错题本是聚合，只保留当前仍然是错题的记录。

3.2 字段类型、唯一索引、逻辑删除这些细节别省

数据库设计里有很多细节，容易在写表结构时偷懒，但后面调试的时候全是坑。

第一，打卡记录表的唯一索引一定要加。很多同学只在代码里判断“今天是否已经打卡”，但两个请求同时到达时，代码判断会失效，只有数据库级别的唯一索引才能稳稳兜底。也就是说，在建表时给“用户 id + 打卡日期”加上唯一索引。

第二，时间字段建议用 datetime，不要用 varchar 存时间字符串。考试复习平台涉及大量日期比较，比如查“今天打了没”“这个月连续打卡多少天”，datetime 类型才能直接用 SQL 函数处理，varchar 会导致每次都要类型转换，慢且容易出错。

第三，每张表都建议加一个 deleted 逻辑删除字段。毕设系统的用户量不大，物理删除看起来无所谓，但老师喜欢问“如果用户删除了笔记，数据还在吗”。有逻辑删除字段，答这个问题时就很从容：删除只是把 deleted 置为 1，查询时统一过滤，数据还在，只是不再展示。

4. 新手必看：登录、打卡、刷题、错题本四个核心接口怎么实现

4.1 微信登录与 Token 签发

微信小程序登录流程可以用六个字概括：拿 code，换 openid。用户进入小程序后，前端调用 wx.login 拿到一个临时 code，把 code 传给后端；后端拿着 code 调用微信提供的接口，换取该用户唯一的 openid；如果 openid 在用户表里不存在，就自动注册一个新用户；最后生成一个 token 返回给小程序端，后续所有请求带上 token，后端根据 token 解析出用户身份。

这个过程里有两个容易踩的坑。第一个是不要把 openid 直接当 token 用。openid 是固定不变的，如果被别人拿到，就等于拿到了用户的永久身份凭证。更安全的做法是正常签发一个带过期时间的 token，比如用随机字符串或 JWT。第二个是注册逻辑要放在登录流程里，不要单独做“先注册再登录”，小程序端没有密码这个说法，微信登录本身就是注册和登录的一体化流程。

下面给一个登录接口的参考代码：

java复制@PostMapping("/api/auth/login")
public Result<String> login(@RequestBody LoginDTO dto) {
    // 1. 使用 dto.getCode() 调用微信接口，换取 openid
    String openid = wechatService.code2Session(dto.getCode());
    
    // 2. 根据 openid 查询用户，不存在则注册
    User user = userMapper.selectByOpenid(openid);
    if (user == null) {
        user = new User();
        user.setOpenid(openid);
        user.setNickname("考研新同学");
        userMapper.insert(user);
    }
    
    // 3. 生成 token，存入缓存或数据库，返回前端
    String token = UUID.randomUUID().toString().replaceAll("-", "");
    tokenService.save(token, user.getId());
    return Result.success(token);
}

实际开发中，code2Session 这一步要处理网络异常和 code 失效，建议加一个 try-catch，如果微信接口返回错误码，直接给前端返回统一的错误信息。

4.2 每日打卡：防重复提交是重点

打卡接口是“看起来简单，写起来要考虑周全”的典型代表。核心需求是用户一天只能打卡一次。实现逻辑其实不复杂，先查今天是否已有记录，有就返回提示，没有就插入一条新记录。但这里有几个容易踩的坑。

前端按钮要做防抖，防止用户连点两次。后端不能只靠查询判断，因为两个请求同时进来时，两个查询可能都返回“没有记录”，然后两个插入都成功，一天就打卡了两次。解决办法是依靠数据库的唯一索引兜底，插入时捕获重复键异常，返回“今天已经打卡过”。

连续打卡统计也值得做。用户打卡成功后，判断昨天是否打过卡，如果打过，连续天数就加一；如果没打过，连续天数就从 1 重新开始。这个逻辑放在打卡接口里做比较合适，因为打卡本身是一个低频操作，不用额外建表，给用户表加一个 continuous_days 字段就行。

java复制@PostMapping("/api/plan/check")
public Result<String> check(@RequestBody CheckDTO dto) {
    Long userId = dto.getUserId();
    LocalDate today = LocalDate.now();
    
    // 唯一索引兜底，防止并发重复打卡
    try {
        PlanRecord record = new PlanRecord();
        record.setUserId(userId);
        record.setCheckDate(today);
        record.setCreateTime(LocalDateTime.now());
        planRecordMapper.insert(record);
    } catch (DuplicateKeyException e) {
        return Result.error("今天已经打卡，不要重复提交");
    }
    
    // 更新连续打卡天数
    int continuousDays = countContinuousDays(userId, today);
    userMapper.updateContinuousDays(userId, continuousDays);
    return Result.success("打卡成功，连续打卡 " + continuousDays + " 天");
}

4.3 刷题判题与错题本：把训练闭环做完整

刷题和错题本是两个接口接力完成的闭环。刷题接口负责从题库取题，用户作答后提交答案，系统判断对错；如果答错了，错题本接口负责把这道题收录进去。

先说刷题的取题策略。小型毕设系统不需要太复杂的推荐算法，但“随机取题”也不能直接用 ORDER BY RAND() 一棒子打死。更好的做法是先按科目分组，再在每组内用随机数定位题目范围，这样每题被抽中的概率更均匀，SQL 性能也更好。实际代码里可以先查该科目题目总数，再生成一个随机偏移量，用 LIMIT offset, 1 取一条。

java复制@GetMapping("/api/question/random")
public Result<QuestionVO> randomQuestion(@RequestParam Long type) {
    // 查询该科目题目总数
    int total = questionMapper.countByType(type);
    // 生成随机偏移量，避免每次都全表排序
    int offset = new Random().nextInt(total);
    Question question = questionMapper.selectByTypeWithOffset(type, offset);
    return Result.success(convert(question));
}

提交答案的接口要同时做两件事：第一，把本次答题记录写入答题记录表；第二，如果答案错误，检查这道题是否已经在错题本里，已经存在就累加错误次数，不存在就新增一条错题记录。

java复制@PostMapping("/api/question/submit")
public Result<Boolean> submit(@RequestBody SubmitDTO dto) {
    // 1. 查询正确选项
    Question question = questionMapper.selectById(dto.getQuestionId());
    boolean isCorrect = question.getAnswer().equals(dto.getUserAnswer());
    
    // 2. 写入答题记录
    AnswerRecord record = new AnswerRecord();
    record.setUserId(dto.getUserId());
    record.setQuestionId(dto.getQuestionId());
    record.setUserAnswer(dto.getUserAnswer());
    record.setIsCorrect(isCorrect);
    answerRecordMapper.insert(record);
    
    // 3. 错题处理，已存在则累加次数，不存在则新增
    if (!isCorrect) {
        WrongBook exist = wrongBookMapper.selectByUserAndQuestion(
            dto.getUserId(), dto.getQuestionId());
        if (exist != null) {
            wrongBookMapper.increaseCount(exist.getId());
        } else {
            WrongBook wrong = new WrongBook();
            wrong.setUserId(dto.getUserId());
            wrong.setQuestionId(dto.getQuestionId());
            wrong.setWrongCount(1);
            wrongBookMapper.insert(wrong);
        }
    }
    return Result.success(isCorrect);
}

这个接口把“答题”和“错题本”打通了，是整条业务链路最核心的部分。答辩的时候顺着这个接口讲，能清楚展示你对多表关联、条件判断、去重更新的掌握程度。

5. 小程序端实现：页面结构、请求封装与登录状态管理

5.1 页面骨架与底部导航设计

小程序端建议用底部的 TabBar 把功能分成四个板块：首页、刷题、笔记、我的。首页展示今日计划、打卡入口和复习倒计时，刷题页按科目进入刷题，笔记页管理用户自己的学习记录，我的页面展示个人信息和统计数据。

页面结构上，每个 Tab 对应一个一级页面，刷题流程下的答题页、结果页是二级页面。底部的 TabBar 不要超过四个，超过以后用户操作负担重，界面也拥挤。四个 Tab 的意义是让评审老师一打开小程序就能看出这个平台的核心功能是什么，不需要到处找。

首页是重点页面，要承载“打卡 + 今日计划 + 学习状态”三个信息区。打卡按钮的状态应该根据今天是否已打卡而变化：未打卡是醒目的主色按钮，已打卡变成灰色不可点击状态，同时显示连续打卡天数。这个交互细节建议用 onShow 生命周期刷新，因为用户从刷题页返回首页时，打卡状态和计划进度都应该是最新的。

5.2 请求封装与登录状态管理

小程序的网络请求不能每个页面写一遍 wx.request，非常容易被后来的人改乱。建议在 utils 目录里封装一个公共的 request 函数，统一处理请求头、token 注入、401 跳转和错误提示。

javascript复制function request(url, method, data) {
  return new Promise((resolve, reject) => {
    wx.request({
      url: getApp().globalData.baseUrl + url,
      method: method,
      data: data,
      header: {
        'Content-Type': 'application/json',
        'token': wx.getStorageSync('token')
      },
      success: (res) => {
        if (res.data.code === 200) {
          resolve(res.data.data);
        } else if (res.data.code === 401) {
          // token 失效，重新登录
          wx.removeStorageSync('token');
          wx.navigateTo({ url: '/pages/login/login' });
        } else {
          wx.showToast({ title: res.data.message, icon: 'none' });
          reject(res.data);
        }
      },
      fail: (err) => {
        wx.showToast({ title: '网络异常，请稍后重试', icon: 'none' });
        reject(err);
      }
    });
  });
}

token 的存储建议放在本地缓存里，请求时从缓存读取，登录后写入缓存。登录状态管理要注意一个典型的坑：小程序的 wx.login 在冷启动和热启动时都可能返回新的 code，所以不能只在启动时登录一次。更稳妥的做法是写一个 ensureLogin 函数，每次打开小程序时检查本地是否有 token，没有就执行登录流程，有就直接进入首页。

6. 跑通项目与部署上线：本地调试、小程序配置与服务器部署

6.1 本地调试环境清单

本地把项目跑起来，是很多同学拿到源码后遇到的第一个坎。环境清单其实不算复杂，但版本要对齐。JDK 建议用 8 或 11，MySQL 用 5.7 或 8.0，后端构建工具用 Maven，前端开发工具用微信开发者工具。前后端联调前，先确认几个基础配置：MySQL 连接串是否指向正确地址、用户名密码是否正确、后端服务的端口是否和小程序端的 baseUrl 一致。

本地联调最容易翻车的是 IP 配置。小程序端如果写 http://localhost:8080，在微信开发者工具里能跑通，但真机预览时手机访问不到电脑的 localhost。建议在项目里用一个常量统一管理 baseUrl，真机调试时改成电脑在局域网里的 IP，比如 http://192.168.1.100:8080。这个小配置不处理好，会遇到“开发工具能打开、手机打不开”的经典问题。

6.2 微信开发者工具的关键配置

微信开发者工具里有三个配置直接影响调试体验。第一，AppID 如果没有正式的小程序账号，可以使用测试号，但测试号会限制一些能力，建议注册个人小程序账号，流程很快。第二，在开发阶段，详情面板里勾选“不校验合法域名、web-view（业务域名）、TLS 版本以及 HTTPS 证书”，否则本地请求会被域名校验拦下来。第三，记得开启 ES6 转 ES5，保证代码在低版本微信客户端上也能正常运行。

需要提醒的是，“不校验合法域名”只是本地开发调试的手段，真正发布上线之前，必须在小程序后台配置服务器域名，而且这个域名必须支持 HTTPS。后端服务器如果没有现成的 HTTPS 域名，开发阶段的真机预览确实比较麻烦，这也是很多初学者卡住的地方。我的建议是一开始就尽量用一台配置好 HTTPS 的服务器，省得后面上线时再重新处理。

6.3 部署到服务器的流程与注意点

部署流程可以概括为：后端打包，前端上传，依赖安装。后端在项目根目录执行 mvn clean package -DskipTests，生成一个可运行的 jar 包，用 java -jar 命令启动即可。前端在微信开发者工具里点击上传，把代码提交到微信后台，然后在后台提交审核、发布。数据库需要先在生产环境的 MySQL 里执行建表 SQL，数据可以通过管理端页面录入，也可以直接导入 SQL 文件。

这里有一个非常容易被忽略的问题：后端接口地址在生产环境必须是 HTTPS，且这个域名必须在小程序后台配置成合法域名。如果直接用 IP 访问，微信客户端会拒绝请求。所以部署前先把 HTTPS 证书配置好，再把域名加入合法域名列表，这两个条件缺一不可。

7. 文档写作、定制修改与答辩准备的实战经验

7.1 毕设文档怎么组织，写到什么程度

毕业设计文档虽然不是代码，但它决定了老师对你工作的第一印象。常见的文档结构包括：开题报告、需求规格说明书、概要设计说明书、详细设计说明书、数据库设计说明、测试报告、总结与展望。每一部分的写作重点不太一样，但有一个共同的技巧：多画图、多列表、多写“为什么”。

需求分析部分，要把用户角色、业务流程、功能清单写清楚。这里不用写代码，但要把用例图画出来，把小程序的页面流转逻辑画出来。概要设计部分，重点画系统架构图，说明前后端如何交互、数据如何流转。详细设计部分，挑核心模块写，比如登录流程、打卡流程、刷题流程，每个流程配时序图。数据库设计部分，除了表结构，还要解释每张表的用途和表之间的关联关系。

文档写到什么程度算够？我的标准是：老师只看文档，不看代码，也能知道你做了哪些功能、每个功能是怎么实现的、遇到了什么问题。很多同学文档里只有功能截图，缺少设计过程，答辩时老师随便问一个“表结构为什么要这样设计”就露馅了。

7.2 答辩高频问题与回答思路

答辩环节老师一般不会为难人，但有几个问题几乎每年必问。提前准备一下，现场会从容很多。

第一个问题是“为什么选微信小程序，而不是 App 或网页”。回答思路是从用户场景切入：考研学生需要碎片化学习，小程序打开即用、无需安装，传播分享也方便。第二个问题是“微信登录是怎么实现的”。把 code 换 openid 的流程讲清楚，再补充一句所有请求都带 token、token 有失效机制，就能体现安全性考虑。第三个问题是“如果用户量变大，系统怎么优化”。不需要长篇大论讲分布式架构，只要说三个点：数据库索引、分页查询、热点数据缓存，就能证明你有扩展意识。第四个问题是“错题本和答题记录有什么区别”。答答题记录是流水、错题本是聚合结果，一个是过程数据，一个是状态数据。

7.3 “定制”改哪些不动哪些

很多同学会拿到一份现成源码之后自己改，这里有一个原则：优先改界面文案，慎重改核心逻辑。项目名称、学校信息、页面标题这些直接替换就好，一般不会出问题。但登录流程、打卡判重、错题归集这些核心逻辑不要乱动，因为改动一个地方可能牵扯到表结构和前端判断，改完很容易出现“打卡成功了但连续天数没更新”这类连锁问题。

如果确实要改功能，建议按这样的顺序：先完整跑一遍现有功能，把流程记下来；再列一个“要改的功能清单”，标注影响范围；最后逐个修改并自测。比如把“刷题按章节”改成“刷题随机难度”，需要修改的是题目表的难度字段、刷题查询条件、小程序端筛选组件，这个影响范围是可以提前评估清楚的。

8. 常见问题速查表：一次把坑踩完

8.1 高频问题、原因与解决方案

8.2 几条只有跑过项目才懂的经验

第一，接口返回格式一定要从一开始统一，不然后面写前端页面时，每写一个页面都要翻一次接口文档，效率非常低。第二，题库数据不用手工一条条录入，写一个 SQL 脚本批量插入，几百条题目几秒钟就能导进去，演示的时候数据丰富度会高很多。第三，答辩演示时一定要用真机预览，不要只开着电脑端的微信开发者工具，真机上的页面尺寸、网络环境、加载速度更真实，也更能体现你确实调过真机调试。

还有一条特别想说：部署上线前，建议把所有接口都跑一遍冒烟测试。我遇到过管理端删了一条文章，小程序端首页直接崩溃的情况，原因是返回的数据里有一个字段为 null，前端没做判空处理。这种问题纯靠写码是发现不了的，必须手动把功能完整走一遍。

把这些经验记下来，至少能帮你少熬几个通宵。回头再看整个项目，最值得花时间的不是技术选型，而是把业务逻辑理清楚、把数据链路跑通、把文档写完整。技术框架只是工具，评审老师真正想看的是你对问题的理解和完成度。如果你正准备动手，我的建议是先把这条主线跑通：登录 -> 建立计划 -> 打卡 -> 刷题 -> 错题归集，这条链路完整了，平台的核心价值就出来了，后面加资讯、加笔记、加统计都是锦上添花。