数学辅导小程序毕业设计：微信小程序+Java后端+MySQL全栈开发指南

简介：基于微信小程序与Java后端（SSM+MySQL）的数学辅导毕业设计完整工程包，面向计算机相关专业毕业生与需要课程设计的开发者，提供一套可运行、可扩展的前后端分离参考实现。项目按管理员与用户两类角色设计：管理员端涵盖用户管理、学习中心、口算练习、试题管理、考试管理等模块；用户端包含首页、学习中心、考试、我的以及学习周报、收藏管理、考试记录、错题本等功能，覆盖数学辅导场景下的主要业务闭环。包内共1281个文件，压缩包约17.44MB。其中png、svg等图像资源用于界面展示，js、java、vue、wxml、wxss等分别承载前后端逻辑与页面样式，SQL脚本可直接导入MySQL完成数据库初始化，另有说明文档与启动脚本便于快速部署和二次开发。已有174人学习下载，适合作为毕业设计参考或项目实战练手。

1. 数学辅导小程序毕业设计：微信小程序+Java后端这套组合到底值不值得做

打开那个“基于微信小程序+java后端的数学辅导毕业设计(源码+数据库+说明).rar”，里面通常是一套完整的交付物：小程序端源码、Java后端工程、数据库脚本和一份说明文档。这类选题在毕业设计里被选中的频率非常高，原因很直接：前端用微信小程序不用操心双端适配，后端用Java贴合主流招聘需求，数学辅导的主题也容易做演示。但这个方向也最容易翻车——前后端分离项目实战里最常见的状况是，数据库建好了、接口也写了，小程序端却怎么都对不上数据。这篇文章不评价任何一个现成压缩包里的代码好坏，只把这个方向应该怎么做讲透：从数据库表设计开始，到Java后端的登录鉴权和跨域配置，再到微信小程序端的列表加载更多和导航栏适配，最后把联调阶段的坑和答辩验收方法交代清楚。适合手里已经有源码包在二次开发的人，也适合准备从零开始做这个方向的人。

2. 数学辅导需求拆解与数据库设计：五张表撑起题库、答题、错题本的闭环

2.1 从使用场景倒推功能：学生端先做闭环

做数学辅导小程序，第一步不是写代码，是定功能边界。把使用者分成两类：学生是主用户，他们要完成“刷题—提交—看判分—把错题收进错题本”这个闭环；老师或管理员是次要用户，负责维护题目、查看统计数据。毕业设计的体量不需要把两边都做全，把学生端做扎实，就已经能撑起一篇完整的论文和一场流畅的答辩。

学生端要收敛成四个功能点：题目列表的分页浏览、题目详情与答题提交、自动判分与答案解析、错题本的增删改查。如果还想加点分量，加一个答题正确率统计，按知识点维度展示。管理端的题目维护如果时间不够，可以做成在后端直接执行SQL维护，答辩时用Navicat或命令行操作展示，效果是一样的。把学生端闭环打通，比加一个半成品管理后台更有说服力。

2.2 五张核心表：字段、外键与查询路径

功能定了，表结构就能跟着落。用 MySQL 的话，最稳的组合是五张表：

这里有一个很重要的设计取舍：answer_record 和 wrong_book 都关联 question，但职责完全不同。answer_record 是流水账，每次答题都记一行，用于统计正确率和答题轨迹；wrong_book 是用户维度的错题集合，同一道题只保留一条记录，wrong_count 做累加。如果图省事把这两张表合并，后面做统计和错题展示时会互相干扰，改起来非常痛苦。

user 表里必须存 openid，这是微信小程序登录的唯一身份凭据。nickname 和 avatar 是用户在微信侧授权后存下来的展示信息，身份判断永远看 openid，不要信前端传过来的 userId。question 表的 options 字段用 JSON 类型存选择题的四个选项，省掉一张选项子表，在选项数量固定时是合理简化。

2.3 建表SQL：MySQL 5.7 的完整脚本与索引约定

下面这份建表脚本，MySQL 5.7 以上能直接执行。字符集全部用 utf8mb4，这个问题现在偷懒，后面中文乱码的坑迟早要踩回来。

CREATE DATABASE IF NOT EXISTS math_tutor DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE math_tutor; CREATE TABLE user ( id INT PRIMARY KEY AUTO_INCREMENT, openid VARCHAR(64) NOT NULL UNIQUE, nickname VARCHAR(50) DEFAULT '', avatar VARCHAR(255) DEFAULT '', create_time DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE knowledge_point ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50) NOT NULL, grade VARCHAR(20) NOT NULL ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE question ( id INT PRIMARY KEY AUTO_INCREMENT, kp_id INT NOT NULL, type TINYINT NOT NULL COMMENT '1-选择题 2-填空题', difficulty TINYINT NOT NULL DEFAULT 3 COMMENT '1-5，越大越难', content TEXT NOT NULL, options JSON, answer VARCHAR(500) NOT NULL, analysis TEXT, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_kp (kp_id), CONSTRAINT fk_question_kp FOREIGN KEY (kp_id) REFERENCES knowledge_point(id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE answer_record ( id INT PRIMARY KEY AUTO_INCREMENT, user_id INT NOT NULL, question_id INT NOT NULL, user_answer VARCHAR(500) NOT NULL, is_correct TINYINT NOT NULL DEFAULT 0, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_user_question (user_id, question_id), KEY idx_user_time (user_id, create_time) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE wrong_book ( id INT PRIMARY KEY AUTO_INCREMENT, user_id INT NOT NULL, question_id INT NOT NULL, wrong_count INT NOT NULL DEFAULT 1, last_wrong_time DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_user_question (user_id, question_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

脚本里有三个关键点要解释。第一，question 表的 answer 字段设计成 VARCHAR(500)，填空题的答案可能有“x=2”这种情况，选择题统一存“A”这种单字符。第二，wrong_book 的 user_id 和 question_id 加了联合唯一索引，这是防重复数据的底线，数据库层面的约束永远比前端判断可靠。第三，外键约束在毕业设计里建议保留，能体现关系型数据库的设计意识，生产环境常常去掉外键靠业务保证，但这个项目数据量小，保留外键在答辩时更好讲。

2.4 预置题库：让演示现场有数据可看

表建好之后，要让小程序一打开就有题。常见做法是准备一份 data.sql，插入 20 到 30 道初中数学题，按知识点分开。覆盖三个方向：一元一次方程、平面几何初步、概率，每个知识点 8 到 10 道，难度集中在 1 到 3 档，避免一上来就把用户难退。

种子数据的质量直接决定演示效果。选择题给 A/B/C/D 四个选项，答案统一存大写字母；填空题给精确答案。尽管系统把答案做成字符串比对方便判分，如果混入大小写和空格，后端判分时还得做归一化处理，少给自己埋这种雷。另外，在 MySQL 里改表结构（比如给 question 表加字段）时，用 ALTER TABLE 操作完要把 seed 数据重新灌一遍，不然新字段全是空值，页面渲染会出问题。

3. Java后端实现：Spring Boot登录鉴权、分页接口与跨域配置

3.1 项目骨架与统一返回结构：先定规矩再写接口

Java后端现在最稳妥的选择是 Spring Boot 2.x 配 MyBatis-Plus，JDK 用 1.8 或 11 都行。毕业设计不需要上微服务，单体应用足够。目录结构按约定俗成的分法：controller 接请求、service 写业务、mapper 做数据访问、entity 映射表结构、config 放配置类。MyBatis-Plus 的好处是单表增删改查不用写 SQL，多表查询用注解或 XML 兜底，正好覆盖数学辅导里最常见的数据库增删改查需求。

接口的返回结构必须统一，否则小程序端每个页面都要写一套判断逻辑。定义一个 Result 类：

public class Result<T> { private Integer code; private String msg; private T data; public static <T> Result<T> ok(T data) { Result<T> r = new Result<>(); r.code = 200; r.msg = "success"; r.data = data; return r; } public static <T> Result<T> fail(Integer code, String msg) { Result<T> r = new Result<>(); r.code = code; r.msg = msg; return r; } }

code 约定：200 成功，401 未登录，404 接口不存在，500 服务端异常。小程序端拿到响应，只看 code 是不是 200，其他情况统一弹 msg。配合一个全局异常处理器，把业务异常封装成 ServiceException，用 @RestControllerAdvice 统一捕获，Controller 里就不用到处 try-catch 了。漏捕获的异常返回给前端的是一长串堆栈，演示时非常难看。

3.2 wx.login 换 token：认证链路与拦截器

微信小程序登录的正确流程是：前端 wx.login 拿 code，后端拿 code 去微信的 jscode2session 接口换 openid。很多初学者把 code 直接存进数据库，这是错的，code 是一次性的、五分钟就过期。后端拿到 openid 后查 user 表，查到就生成 token 返回，查不到就先用 openid 注册一条新用户再返回 token。

public LoginResponse wxLogin(String code) { // 1. 调微信接口换 openid String url = "https://api.weixin.qq.com/sns/jscode2session?appid=" + appid + "&secret=" + secret + "&js_code=" + code + "&grant_type=authorization_code"; String result = restTemplate.getForObject(url, String.class); JSONObject obj = JSON.parseObject(result); String openid = obj.getString("openid"); if (StringUtils.isBlank(openid)) { throw new ServiceException("code 无效或已过期"); } // 2. 查用户，没查到就注册 User user = userMapper.selectByOpenid(openid); if (user == null) { user = new User(); user.setOpenid(openid); userMapper.insert(user); } // 3. 生成 token，存入 Redis 并设置 7 天过期 String token = UUID.randomUUID().toString().replace("-", ""); redisTemplate.opsForValue().set("login:token:" + token, user.getId(), 7, TimeUnit.DAYS); return new LoginResponse(token, user.getId()); }

appid 和 secret 从 application.yml 里读取，不要写死在代码里。token 用 UUID 随机串，Redis 里存映射关系。如果不想引 Redis，可以用 HashMap 存，但重启就丢、也没有过期清理，演示时临时用可以，论文里说不过去。后面的受保护接口写一个拦截器，从 header 里取 token 查 Redis，查不到就返回 401。小程序端在 request 封装里看到 401，统一跳登录页。

3.3 题目分页与答题提交：参数校验、幂等与事务边界

题目列表接口是基础分页查询，用 MyBatis-Plus 的 Page 对象直接做：

@GetMapping("/page") public Result<Page<Question>> page( @RequestParam(defaultValue = "1") Integer page, @RequestParam(defaultValue = "10") Integer pageSize, @RequestParam(required = false) Integer difficulty) { LambdaQueryWrapper<Question> wrapper = new LambdaQueryWrapper<>(); if (difficulty != null) { wrapper.eq(Question::getDifficulty, difficulty); } wrapper.orderByAsc(Question::getId); return Result.ok(questionMapper.selectPage(new Page<>(page, pageSize), wrapper)); }

分页参数前后端要提前约定好：page 从 1 开始还是从 0 开始，pageSize 最大是多少。我的经验是统一从 1 开始，pageSize 限制 20，防止有人调接口传个 10000 把服务拖垮。排序用 id 升序，稳定，不会因为并发更新导致分页时记录反复横跳。

答题提交是这个项目最值得写好的接口，涉及参数校验、防重复提交、事务三个点：

@PostMapping("/submit") @Transactional(rollbackFor = Exception.class) public Result<Void> submit(@RequestBody SubmitRequest req, @RequestHeader("token") String token) { // 1. 参数校验 if (req.getQuestionId() == null || req.getUserAnswer() == null) { throw new ServiceException("题目和答案不能为空"); } // 2. 防重复提交：查重并做幂等 Integer userId = getUserIdByToken(token); AnswerRecord record = recordMapper.selectByUserIdAndQuestionId(userId, req.getQuestionId()); if (record != null) { throw new ServiceException("该题目已提交过"); } // 3. 判分逻辑 Question question = questionMapper.selectById(req.getQuestionId()); boolean correct = normalizeAnswer(question.getAnswer()) .equals(normalizeAnswer(req.getUserAnswer())); // 4. 写答题流水 AnswerRecord newRecord = new AnswerRecord(); newRecord.setUserId(userId); newRecord.setQuestionId(req.getQuestionId()); newRecord.setUserAnswer(req.getUserAnswer()); newRecord.setIsCorrect(correct ? 1 : 0); recordMapper.insert(newRecord); // 5. 答错则插入或更新错题本 if (!correct) { WrongBook wrongBook = wrongBookMapper.selectByUserIdAndQuestionId(userId, req.getQuestionId()); if (wrongBook == null) { wrongBook = new WrongBook(); wrongBook.setUserId(userId); wrongBook.setQuestionId(req.getQuestionId()); wrongBook.setWrongCount(1); wrongBookMapper.insert(wrongBook); } else { wrongBook.setWrongCount(wrongBook.getWrongCount() + 1); wrongBook.setLastWrongTime(new Date()); wrongBookMapper.updateById(wrongBook); } } return Result.ok(null); }

这个接口藏着前后端对按钮重复提交校验的核心问题。如果产品需求允许同一道题反复作答，就不能用“同题幂等”，要让前端每次提交带一个 requestId，后端拿 requestId 做唯一约束，遇到重复的 requestId 直接拒绝。上面代码里的同题幂等只适用于“每题只答一次”的设定，做之前要先想清楚。事务注解必须加在 public 方法上，写流水和更新错题本是两个写操作，任何一个失败都要回滚，否则会出现“答题记录有了但错题本没更新”的脏数据。rollbackFor 写成 Exception.class，因为 Spring 默认只回滚 RuntimeException，需要显式扩大范围。

3.4 跨域配置：浏览器调试时的 CORS 处理

跨域这个词在小程序端其实不太适用——小程序不走浏览器同源策略，但是用开发者工具调试某些页面或以后做 Web 管理端时，就会被 CORS 拦截。Spring Boot 里加一个配置类就能解决：

@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") .allowedHeaders("*") .allowCredentials(true) .maxAge(3600); } }

注意：allowCredentials(true) 时 allowedOriginPatterns 不能写成 "*"，这是 Spring 版本升级后的一个限制。开发阶段放开所有来源没问题，部署演示时如果绑定了正式小程序域名，最好收紧到具体来源。

4. 微信小程序端实现：列表加载更多、导航栏高度适配与答题闭环

4.1 request封装：token 注入与错误提示收口

小程序端不能一上来就堆页面。先建 utils 目录放 request.js，config 目录放 baseUrl，api 目录按业务模块放接口请求。一个典型目录结构：

miniprogram/ ├── app.js ├── app.json ├── utils/request.js ├── config/index.js ├── api/ │ ├── question.js │ └── user.js └── pages/ ├── index/ // 题目列表 ├── answer/ // 答题页 ├── wrong/ // 错题本 └── mine/ // 个人中心

request 封装是所有页面的心脏，做三件事：拼接 baseUrl、注入 token、统一处理错误码。

const request = (url, method = 'GET', data = {}) => { const token = wx.getStorageSync('token') return new Promise((resolve, reject) => { wx.request({ url: baseUrl + url, method, data, header: { 'Content-Type': 'application/json', 'token': token }, success(res) { const body = res.data if (body.code === 200) { resolve(body.data) } else if (body.code === 401) { wx.redirectTo({ url: '/pages/login/login' }) reject(body) } else { wx.showToast({ title: body.msg || '请求失败', icon: 'none' }) reject(body) } }, fail(err) { wx.showToast({ title: '网络异常，请检查后端服务', icon: 'none' }) reject(err) } }) }) } module.exports = { request }

登录成功时把 token 存进 wx.setStorageSync，后续所有请求自动带上。业务请求的 code 只认 200，其他的统一弹 toast，页面代码里不用再写一堆 if 分支。这样封装之后，每个页面只需要关心成功数据，出错路径被收口到一处。

4.2 列表加载更多：onReachBottom 的双重判断

微信小程序页面列表加载更多要处理三件事：首次加载、触底加载、到底提示。很多实现翻车就翻在 onReachBottom 触发频率太高，后端没有数据了还在发请求。

// pages/index/index.js Page({ data: { list: [], page: 1, pageSize: 10, hasMore: true, loading: false }, onLoad() { this.loadItems(true) }, onReachBottom() { if (!this.data.hasMore || this.data.loading) return this.loadItems() }, async loadItems(reset = false) { if (this.data.loading) return this.setData({ loading: true }) const page = reset ? 1 : this.data.page + 1 try { const res = await getQuestionPage({ page, pageSize: this.data.pageSize }) const nextList = reset ? res.records : this.data.list.concat(res.records) this.setData({ list: nextList, page, hasMore: res.records.length >= this.data.pageSize, loading: false }) } catch (e) { this.setData({ loading: false }) } } })

关键判断就三个：loadItems 一进来看 loading，防止重复请求；onReachBottom 里先看 !hasMore 直接拒绝，避免底部反复触发；hasMore 用“本次返回条数是否等于 pageSize”来判断，等于说明可能有下一页，小于说明到底了。最容易犯的错误是不加 loading 和 hasMore 双重判断，导致列表出现重复数据。另外，题目列表里的图片建议加上 lazy-load="true"，数学题的公式图多时能减少一次性渲染压力。

4.3 自定义顶部导航栏：不同机型的高度适配

在 app.json 里把 navigationStyle 设置成 custom 之后，页面顶部就空出一块状态栏和胶囊按钮区域，需要手动撑开。微信小程序顶部导航栏高度不能写死，iPhone 和小米的状态栏高度不一样，用固定值必然偏移。

// app.js App({ onLaunch() { const win = wx.getWindowInfo() const menu = wx.getMenuButtonBoundingClientRect() // 导航栏高度 = 状态栏高度 + 胶囊按钮高度 + 上下间距 const navHeight = (menu.top - win.statusBarHeight) * 2 + menu.height this.globalData.navHeight = navHeight this.globalData.statusBarHeight = win.statusBarHeight }, globalData: { navHeight: 44, statusBarHeight: 20 } })

自定义导航栏组件里动态设置高度：

<view class="nav-bar" style="padding-top: {{statusBarHeight}}px; height: {{navHeight}}px;"> <view class="nav-bar__title">题库</view> </view>

注意 wx.getWindowInfo 是基础库 2.20.1 之后推荐的 API，wx.getSystemInfoSync 虽然还能用但官方已不建议。真机上不同型号会有几像素误差，计算出结果后再微调是常态。这个参数在答辩时容易被评委注意到，因为写死数值的导航栏在演示真机上看起来就是歪的。

4.4 答题提交与错题本联动：requestId 怎么用

答题页是数据流最复杂的页面。用户从列表点一道题，跳答题页，选择答案后提交。提交接口的参数里带上 requestId，后端拿这个字段做幂等判断，防止用户手抖连点两下产生两条流水。

const generateUUID = () => { return 'xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx'.replace(/[xy]/g, c => { const r = Math.random() * 16 | 0 const v = c === 'x' ? r : (r & 0x3 | 0x8) return v.toString(16) }) } async handleSubmit() { const requestId = generateUUID() const payload = { requestId, questionId: this.data.questionId, userAnswer: this.data.selectedAnswer } const res = await submitAnswer(payload) if (res.isCorrect) { wx.showToast({ title: '回答正确', icon: 'success' }) } else { wx.navigateTo({ url: `/pages/result/result?questionId=${this.data.questionId}` }) } }

错题本页面从后端拉取当前用户的错题列表，每条带完整题目信息。答对两道从错题本移除，答错一次更新 last_wrong_time，这是产品层面的选择。数据流的闭环是：题目列表 → 答题提交 → 后端判分 → 写 answer_record → 答错更新 wrong_book → 错题本查询展示。把这个链路画在论文里，评委很容易跟得上。

5. 避坑与排查：毕业设计联调里最常见的5个坑

5.1 后端启动失败：端口占用和数据库连接不上

现象：Spring Boot 启动立刻报错，提示 Port 8080 was already in use，或者 Communications link failure。

原因：前一个没关掉的 Java 进程占着端口；MySQL 服务没启动，或连接串里的用户名密码写错。这两类问题占了后端启动失败的九成。

解决：Windows 下用 netstat -ano | findstr 8080 查占用端口的 PID，taskkill /F /PID 杀掉；数据库问题先确认 MySQL 服务在跑，再看 application.yml 里的 url、username、password。给新手的建议是启动失败时看控制台最前面几行日志，那才是真正的报错原因，看最后一行经常被误导。

5.2 小程序请求404：baseUrl路径对不上

现象：开发者工具里发起请求，返回 404，但后端接口确认是存在的。

原因：小程序端的 baseUrl 和后端 controller 的映射路径拼接后对不上。常见于 baseUrl 配成 http://localhost:8080，controller 映射的是 /api/question，实际请求变成了 /question。

解决：在 config/index.js 里把 baseUrl 写成 http://localhost:8080/api，或在每个 api 方法里补 /api 前缀。排错时打开开发者工具的 Network 面板，看实际发出的 URL——永远比猜路径快。

5.3 真机预览连不上本地后端：localhost 不代表电脑

现象：开发者工具里一切正常，手机扫码预览后所有请求全部失败。

原因：手机上的 localhost 指向手机自己，不是开发电脑。电脑上后端监听 127.0.0.1，手机也访问不到；两台设备不在同一网段时也连不上。

解决：把 baseUrl 从 http://localhost:8080 改成 http://<电脑局域网IP>:8080，电脑和手机连同一个 Wi-Fi，防火墙放行 8080 端口。这个坑每年毕业季都有大批人踩，提前把局域网 IP 配好就不会手忙脚乱。

5.4 列表加载更多死循环：loading 和 hasMore 判断缺失

现象：滑动到底部一直发请求，loading 图标不消失，列表出现重复数据。

原因：onReachBottom 触发频率非常高，hasMore 和 loading 没有做双重判断，导致上一次请求还没回来，下一次请求已经发出去了。另一种情况是分页参数传了 page+1，但 data 里的 page 没更新，一直请求同一页。

解决：严格按 4.2 的模板写：loading 为 true 直接 return；hasMore 为 false 直接 return；每次请求回来再更新 page；hasMore 用 records.length === pageSize 判断。这三个判断缺一个都会出问题。

5.5 错题本重复写入：幂等和唯一索引缺一不可

现象：错题本里同一道题出现多条记录，或数据库里中文显示为问号。

原因：前端提交按钮没有做防重复处理，用户快速连点两次，后端收到两个相同请求，各写一条流水；字符集问题则是建库时用了默认 latin1，或 JDBC 连接串没加 characterEncoding=utf8。

解决：防重做两层——后端检查 answer_record 里有没有同题记录，wrong_book 表加联合唯一索引（user_id, question_id）；字符集问题执行 ALTER TABLE wrong_book CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci，同时把 JDBC 连接串补上 useUnicode=true&characterEncoding=utf8。数据库这层兜底永远比业务代码可靠，这是做后端时间越长越认同的一条经验。

6. 验收与进阶：让答辩演示站得住的检查清单和扩展方向

6.1 演示前的验证清单

答辩前一周，用这张清单过一遍，能避免大部分现场翻车。第一，功能路径从头到尾走一遍：登录 → 列表分页 → 答题 → 判分 → 错题本，确认数据链路完整。第二，把预置题库的种子数据重置一遍，确保演示时不会因为之前调试产生的脏数据导致页面异常。第三，检查接口响应时间——本地联调时每个请求应在 200ms 以内，如果超过 500ms，评委追问时很难解释。第四，真机演示比开发者工具演示更有说服力，提前一天用真机跑一遍完整流程，特别是顶部导航栏高度和分页加载在真机上的表现。第五，准备一张错误场景截图，比如后端关掉时小程序的统一报错提示，证明你考虑了异常处理。

6.2 值得做的扩展方向

如果时间有富余，值得做的是题库管理后台的接口，不一定要完整前端，把 restful 接口写出来配合文档演示即可。另一个低成本高回报的扩展是学习统计：基于 answer_record 表做正确率和知识点薄弱环节的聚合统计，用 echarts 在小程序里渲染一个简单图表。数据量不大时 SQL group by 就能解决，不需要上重型报表工具。我在做过类似项目后的体会是，毕业设计的评分往往不看你做了多少页面，而是看数据链路是否完整闭环、异常处理是否有意识。提前把演示脚本写好，比临场自由发挥稳妥得多，希望帮到你。

本文还有配套的精品资源，点击获取