Spring Boot与微信小程序在线答题系统：从数据库到判分全解析

最近后台常有人私信问我："Java Spring Boot 基于微信小程序的在线答题系统"这类项目到底应该从哪看起，代码拿到手之后一打开全是文件，完全懵。这个问题我太有共鸣了，这确实是一个特别典型的全栈入门级系统，但它并不是简单的增删改查。我陆陆续续带过不少人跑通这类项目，也拆过不少版本的源码，结合自己的开发经验，把这里面最核心的设计思路、最容易翻车的细节，以及拿到源码、文档、运行视频后应该怎么组合着用，一次性说清楚。这篇文章适合正在做毕设、准备项目答辩、或者刚接触Spring Boot和微信小程序、想搞明白一个真实系统是怎么串联起来的人。

从需求到选型：为什么是Spring Boot和微信小程序，而不是一套Web后台

1.1 先看使用场景，再看技术栈

如果让我用一个词概括这套系统的本质，我会说它是"轻量级考试终端"。用户拿到手机，打开微信，扫一下小程序码，就能进去答题。这个场景意味着：

第一，学习成本几乎为零。不用下载App，不用注册账号，微信本身就解决了身份问题。第二，开发成本也是可控的。后端选Spring Boot，因为它在Java生态里整合能力最强，MyBatis或MyBatis-Plus操作数据库、Spring Security或拦截器做鉴权、Redis或数据库做缓存，都很成熟，资料也多。前端不是Vue也不是React，而是微信小程序，因为它天然跑在微信里，不需要处理浏览器兼容性。第三，整个系统的业务量级不需要微服务架构，单体应用完全够用。

如果这个项目交付给一个企业做内部考试，或者在一个学校做课程测验，管理员在管理端配置试卷，学员在微信小程序里答题，这样一个闭环就是全部需求。别急着加复杂的东西，比如题库批量导入、Excel导出、成绩排名、证书生成，这些属于扩展功能，可以在主流程跑通之后慢慢加。

1.2 前后端分离到底分的是什么

很多初学者看到"前后端分离"就紧张，实际上在这套系统里，分离点非常清晰。小程序的代码运行在微信客户端里，Spring Boot代码运行在服务器上，两者之间只通过JSON格式的HTTP接口互相通信。小程序负责页面渲染、用户交互、倒计时显示、本地缓存；后端只负责数据校验、业务逻辑、数据库读写，以及返回统一的Result对象给前端。

不要试图在Spring Boot里用Thymeleaf或者JSP去渲染页面，那是传统Web应用的思路，放到小程序场景里完全不合适。小程序页面有自己的wxml和wxss，和后端没有任何耦合。这也意味着，只要你接口设计得清晰，以后把小程序换成App，后端几乎不用改。表结构、数据库连接、ServiceImpl，这些代码是可以完全复用的。

1.3 接口设计之前，必须把“答题”这两个字拆开

我见过不少开发者的第一版代码，直接给题目表加一个"正确答案"字段，然后把试卷表、答题记录表揉在一起，最后交卷统计时算出一个分数，就以为系统做完了。实际上，"在线答题系统"最小的完整链路至少包含六个环节：登录、获取试卷、开始考试、答题保存、交卷计时、自动判分。每一个环节都是一组接口，而且接口与接口之间有非常强的状态关系。

举个例子，开始考试时用户点击"开始答题"，后端需要创建一条考试记录，记录开始时间；用户每答一题，可以保存也可以最后统一提交；交卷时，后端要遍历答题明细逐条判分。这个过程中，任何一环没有设计好，最后都会出bug。我个人建议在写代码之前，先把这个链路画出来，不用画成流程图，自己在文档里写清楚"哪个接口由谁调用、改变什么状态、返回什么数据"就够了。

数据库建模：拆开一套答题系统，最能看出代码功底的就是表结构

2.1 核心表设计：一张试卷拆出来的六张表

很多人拿到的源码刚开始都是乱的，我的建议是先从数据库脚本开始读。系统再花哨，只要看数据表设计就能明白它到底能干什么。这套系统通常至少会拆出六张表，我整理一下最典型的结构：

这种设计看起来有点复杂，其实每张表都有它存在的理由。question表里type字段用来区分单选题、多选题和判断题，选项我用options字段保存JSON字符串，比如["A. Java", "B. Python"]，简单项目完全够用。paper_question表的存在是为了解决"一份试卷包含哪些题目"的问题，不要直接把question_id拼成字符串塞到paper表里，否则后续查询题目详情会非常痛苦。

exam_record和answer_detail是这套系统里最核心的两张表。exam_record记录某个人在某一场考试里的整体情况，answer_detail记录每一道题的作答情况。为什么一定要拆开？因为同一份试卷，同一个用户可能考三次，每一次都是一条新的考试记录；而一次考试里可能有50道题，每一道题的答案状态都要独立记录。如果把它们放在一张表里，要么数据冗余，要么没法追溯。

2.2 正确答案冗余：自动判分的底线

在实际开发中，有一个我踩过坑的点：不要在answer_detail里只存user_answer，然后在交卷时临时去question表拿正确答案来比对。虽然这样也能算出分数，但如果你允许管理员编辑题目，一旦题目被改，历史考试记录的判分就会出现偏差。正确的做法是，在答题明细表里既存用户答案，也冗余一个is_correct字段，交卷判分时把这个字段写入。这样历史记录永远是当时的真实结果，题目后续怎么改都不影响。

另外，题目的score字段不要默认全按5分算，因为不同题型的分值可能不一样。多选和判断、单选的分值权重不同，这在设计试卷时就要明确。之前有套源码，所有题目都写死10分，后面用户想做一个主观题和客观题混合的试卷，就得改数据库，非常被动。

2.3 状态字段与逻辑删除：别把业务状态设计得只能“删掉”

考试记录里的status字段很有讲究。简单设计可以只放两个值，0代表未交卷，1代表已交卷。但我在实际项目中更推荐用三个值：0-答题中，1-已交卷，2-已超时。为什么呢？因为超时交卷和后端强制交卷，本质上都算"已交卷"，但它们背后的业务语义完全不同。如果用户因为断网或者其他原因一直没提交，后端需要有一个定时判断或者被动判断的机制，把这种记录标记为超时，这样统计成绩时才能准确区分"主动交卷"和"被迫交卷"。

还有一点，数据库表尽量带上is_deleted逻辑删除字段，尤其是question和paper这种基础数据表。虽然Spring Boot项目里可以直接用delete语句物理删除，但一旦题目被试卷引用，物理删除会导致paper_question出现孤数据。逻辑删除是成本最低的容错方案。

2.4 数据库脚本初始化：字符集和SQL文件顺序

在运行这套系统时，很多人上来就执行SQL脚本，结果报错"table already exists"或者中文乱码。原因很简单：第一，SQL脚本里缺少DROP TABLE IF EXISTS；第二，建表时没有指定utf8mb4字符集。小程序用户的nickname可能存在emoji，utf8mb4才支持完整的Unicode编码。我实际跑的脚本里，通常会在开头统一加上SET NAMES utf8mb4，并在每张表的ENGINE=InnoDB后面追加DEFAULT CHARSET=utf8mb4。这属于非常细节的坑，但每一次都能绊倒一批刚上手的人。

登录链路与Token鉴权：小程序端和后端是怎么互相认出彼此的

3.1 登录流程的完整链路

小程序端和后端交互，第一步遇到的永远都是登录。这里最容易出现的误解是：小程序直接调wx.login拿code，然后拿这个code去请求微信的接口，换取openid。真正正确的做法是，小程序把code传给你的Spring Boot后端，由后端拿着code去微信的服务器换openid和session_key。为什么要绕过前端？因为请求需要appid和secret，secret是绝对不能暴露在小程序代码里的，否则任何人通过抓包都能拿到你的用户身份凭证。

整个链路是这样的：wx.login成功之后拿到一个临时凭证code，这个code有效期非常短，只能使用一次。前端把这个code发到后端的/login接口，后端调用微信接口服务换取openid，然后根据这个openid查user表，如果不存在就自动注册一个新用户，最后生成一个我们自己的token返回给前端。前端把token存到wx.setStorageSync里，之后每次请求都通过请求头Authorization带上去。

@RestController public class UserController { @PostMapping("/login") public Result login(@RequestBody LoginRequest request) { String code = request.getCode(); String openid = wxService.code2Session(code); User user = userService.findOrCreateByOpenid(openid); String token = tokenService.createToken(user.getId()); return Result.success(token); } }

这里有一个很小的细节：很多源码在登录成功之后会把整个User对象返回给前端，但你自己开发时最好只返回id和token，不要直接把openid返回给前端。因为openid对应微信用户的唯一身份，它和账号密码一样属于敏感信息，前端根本不需要知道。

3.2 Token方案怎么选：自建Token表还是JWT

这是我在指导别人时最常被问到的问题。JWT的好处是后端无状态，token自带过期时间，通过签名就能验证合法性；但如果要做强制下线、封号这类操作，JWT就比较啰嗦。自建Token表的好处是随时可以把某个token标记为失效，逻辑直观，缺点是要多查一次数据库。

在在线答题系统这种场景里，我的建议是简单为主，自建Token表完全够用。user表旁边加一张token表，字段就是id、user_id、token、expire_time、create_time。用户登录时生成一个UUID字符串，同时写入数据库。每次请求进来，拦截器根据请求头里的token去token表里查，再判断是否过期。整个链路清晰，代码也容易读。

public class AuthInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { String token = request.getHeader("Authorization"); if (token == null || tokenService.isExpired(token)) { response.setStatus(401); return false; } return true; } }

Token设置过期时间也很讲究。答题场景不比日常刷信息流，用户可能在一场考试里停留40分钟，如果token仅仅设置了30分钟有效期，答到一半就被强制退出，这是灾难。我个人会把token过期时间设置为2小时以上，或者设置一个滑动过期策略：只要用户在持续操作，就刷新过期时间。

3.3 拦截器与全局异常：401该返回就返回，不要重定向

这个问题常见于从传统Web开发转过来的同学。以前做网页后端，session失效了往往重定向到登录页，那是浏览器无感知的跳转。但小程序不是浏览器，它不会自动处理302，你需要做的是在拦截器里直接返回401状态码，让前端wx.request统一拦截这个状态码，再跳转到登录页。这里推荐写一个全局异常处理器，把业务异常、参数校验异常、Token过期异常分别映射到不同的错误码，前端可以根据错误码给出不同的提示，而不是清一色弹出"请求失败"。

小程序端的request封装也很关键。每个请求都要自动带token，遇到401要统一清理本地token并跳转登录页。我在封装的时候会把code等于401的情况单独处理，判断页面是否已经在登录页，避免反复跳转死循环。这块虽然不难，但是对于整套系统的使用体验影响非常大。

答题、交卷与计分：业务闭环里最容易被忽略的三个细节

4.1 倒计时到底该信前端还是信后端

答题系统里几乎一定会有倒计时功能。最简单的做法是在小程序端做一个60分钟的倒计时，时间到了自动调提交接口。但如果你真这么做了，就会出现一个经典的作弊漏洞：用户把手机时间改了，原本60分钟变成120分钟，倒计时完全失效。更稳妥的做法是，开始答题时后端记录start_time和试卷的duration，小程序端只负责显示剩余时间，真正的时间截止判断以后端为准。也就是说，即使前端倒计时不准确，用户过了截止时间再调用交卷接口，后端会先校验当前时间是否已经超过start_time加duration，超时就直接拒绝或者按超时记录处理。

long now = System.currentTimeMillis(); long deadline = record.getStartTime().getTime() + paper.getDuration() * 60 * 1000L; if (now > deadline) { // 按超时处理 }

这个校验放在交卷接口的第一行，是一次很便宜但很关键的保护。前端倒计时崩溃拉胯不可怕，后端守住底线，成绩就不会乱。

4.2 答题过程中要不要实时提交

很多第一次设计这个系统的人会把每一道题的答案都实时POST到后端，美其名曰"及时保存"。但实际这样做有副作用：每题一请求，频繁的网络交互会打断用户的作答节奏，而且一旦网络抖动，答题页面可能白屏。我的建议是，小程序端先把用户每一题的答案放在本地全局对象里，同时用setStorageSync本地备份，只在两个时间点触达后端：一是用户手动点击保存时，二是交卷时。

但这不等于后端就可以偷懒不做幂等。交卷接口必须支持重复提交而不产生重复数据。比如用户第一条交卷请求已经成功，但是由于网络原因前端没收到响应，用户又点了一次交卷，后端第二次收到时，如果发现考试记录状态已经是已交卷，就直接返回原成绩，而不是重新计算一遍导致成绩覆盖或者记录重复。这个细节最容易出bug，也是评阅老师最喜欢追问的点。

4.3 判分逻辑：单选、多选、判断要分开处理

自动判分是这套系统的技术核心，它的实现质量直接决定系统的可用性。题目有单选题、多选题、判断题，每种题型的判分规则完全不同，不能简单粗暴地拿字符串"=="去比较。

单选题和判断题的判分最简单，用户答案等于正确答案就算对。多选题的判分要复杂一点，如果全对才得分，漏选就零分，是一种策略；如果漏选得一半分，又是一套策略。我建议把计分规则独立成一个ScoreCalculator类，方法只根据题目类型和用户答案返回得分。这样判分逻辑可以单独写单元测试，不用每次修改规则都跑到小程序里手动点一遍。

public int calculateScore(Question q, String userAnswer) { if ("SINGLE".equals(q.getType()) || "JUDGE".equals(q.getType())) { return q.getAnswer().equals(userAnswer) ? q.getScore() : 0; } if ("MULTI".equals(q.getType())) { // 全对则满分，漏选计一半，错误零分 } return 0; }

判分之后，需要把每道题的对错状态写入answer_detail表，同时累加总分写回exam_record表。有些源码会在交卷接口里直接写一大段for循环，把所有逻辑堆在一起，虽然能跑，但过一段时间你回来看这段代码，会发现根本不敢动。拆成独立Service的好处就是，以后要加"主观题人工复核""错题自动加入错题本"这样的功能，改动面会小很多。

4.4 错题本模块：判断边界要放在交卷时

很多在线答题系统的进阶版本还会带一个错题本，用户在"我的"页面可以看到历史错题并重新练习。这个功能实际上不复杂，交卷判分统计之后，遍历answer_detail，凡是is_correct等于0的记录，去错题本表里做一次upsert：先查是否已经存在这条错题记录，存在则更新错误次数和最后错误时间，不存在则新插入。需要注意的是，错题记录必须带user_id，因为不同用户看到的错题完全独立。

做完错题本，整个系统的业务闭环才算相对完整：登录、答题、交卷、判分、错题积累、再次练习。如果你正在设计自己的扩展功能，我建议优先做这个，它的实现成本低，但在答辩和实际使用中的展示效果非常好。

交付物怎么用：源码、文档和视频的顺序比数量更重要

5.1 拿到源码第一件事不是看Controller，而是看表结构和启动类

我拆过不少类似的项目源码，也帮人跑通过N多套环境。有一个体会是，拿到一套源码千万不要从Controller开始一行行读，那样大概率两天后你还在第一个接口里打转。正确的顺序是：先建库，导入SQL脚本，然后花半小时看懂表结构，再去启动Spring Boot项目，用接口调试工具试着调通登录接口。表结构理解了，你对系统的整体认知就已经建立了百分之六十。

然后是启动类，也就是那个带@SpringBootApplication注解的类。看它的旁边有哪些注解，比如@MapperScan("com.example.mapper")，你能大致猜到包结构。接着打开application.yml，看数据库连接配置、端口配置。把项目跑起来这个阶段，数据库连接失败是最高频的错误，参数配好，基本就成功一大半了。

5.2 接口文档是源码的另一个大脑

很多人忽略文档，觉得看代码就够了，这是大忌。成熟的源码通常会附带一份接口文档，里面会写明每一个接口的路径、请求方式、参数、返回示例。我推荐的做法是，打开接口文档，同时打开小程序端的request封装和页面逻辑，反过来对照后端Controller。从前端页面里能看到"用户点击开始考试调了哪个接口"，从Controller里能看到"这个接口背后做了哪些服务调用"，这样一个三维视角建立起来，整个系统的运行流程就非常立体了。尤其答辩时，老师最喜欢问的是"用户点这个按钮之后，后端发生了什么"，你得能在脑子里快速追出这条链路。

5.3 运行视频的独特价值是帮你节约环境配置时间

运行视频的核心价值不是演示功能，而是它能直观告诉你环境配置的顺序。我见过很多人在部署阶段被卡住，就是因为他不知道需要先启动Redis还是先启动MySQL，也不知道小程序开发工具里要勾选"不校验合法域名"才能连上一个HTTP协议的本地后端。这类细节，运行视频里通常都会有。如果你拿到这样的视频，建议第一遍正常速度看，第二遍专门挑环境配置部分截图记录，再结合后端控制台日志去理解。

部署到真机预览时还有一个坑：小程序要求请求地址必须是HTTPS的合法域名，本地调试时答案是这个"不校验合法域名"的开关，但如果要正式发布，就必须把Spring Boot部署到服务器，并在Nginx上配置SSL证书。很多初学者第一次跑通只是本地预览，结果一到上线环节就抓瞎，这个点值得提前了解。

5.4 讲解视频怎么听才不浪费

讲解视频如果在讲功能演示，那它的价值就只是画面演示；如果在对表和代码流程做梳理，那价值就很高。我听这类项目讲解时有一个自己的节奏：先听数据库设计部分，如果对方能在十分钟内把用户、题目、试卷、考试记录这几张表的关系讲清楚，那这个讲解视频的含金量就比较高；然后听登录流程和交卷计分流程，这部分是答辩的重点。如果你自己要做答辩PPT，直接把这一条链路讲清楚，拿出核心表结构图和核心代码，比贴几十页截图都管用。

我在实际带人跑通这套系统后发现，提问最多的不是"代码怎么跑"，而是"如果我想加一个功能从哪里入手"。比如加一个考试排行榜，你就需要知道成绩数据都在exam_record表里，统计逻辑可以接一个List按score倒序排；比如加一个题目选项乱序，你只需要在返回题目JSON时对options数组做shuffle，并且保证判分时仍用正确答案字段，不受选项顺序影响。这些扩展思路顺着表结构走，会顺畅很多。

5.5 本地编译与部署的最后一步

最后聊一个我几乎每次都会遇到的环境问题：Spring Boot版本和小程序基础库版本带来的兼容性困扰。源码里如果用了Spring Boot 2.x，那么Java版本一般是8或11；如果用了3.x，Java版本就得是17以上，这个不匹配会导致项目根本起不来。小程序端也一样，用了比较新的组件或API，但运行基础库版本太旧，功能就会异常。所以拿到源码第一件事，建议先看pom.xml里的Spring Boot版本和你本地的JDK版本是否匹配，再去看小程序代码里是否用了某些较高版本才有的API。

我个人在跑这类项目时还有一个习惯：如果源码里自带的数据库连接配置用的是localhost，但MySQL密码不是root，就会启动失败。这时先不要怀疑源码有问题，检查一下用户名和密码。这类项目八成的问题都出在环境配置，剩余两成才是代码逻辑，把这个心态摆正，调试效率会高很多。

这套系统的复杂度不在代码量，而在事务边界和状态流转。真正把它跑通之后你会发现，最有价值的部分不是你写了多少行代码，而是你对"一个用户从进入小程序到完成一次考试"这条完整链路的掌控力。如果手头还有源码和讲解视频，别急着从Controller开始啃，先把数据库脚本导进去，再按我刚才说的顺序走一遍，你会发现这类项目的读法和写法，其实全都是共通的。