考研政治刷题小程序（AI推荐题目、ECharts数据分析、章节练习与专项训练、模拟考试、错题本与收藏夹、学习打卡与目标管理、题库和组卷维护）

考研政治刷题小程序：四种练习模式，为什么最后都走同一个作答页

关键词：Spring Boot 3.3.1 · uni-app 微信小程序 · Vue 3 管理端 · 章节练习与专项训练 · 模拟考试与答题卡 · 错题本与收藏夹 · 学习打卡与目标管理 · ECharts 数据分析

一、写在前面

准备二战的学长跟我吐槽过一件事：政治刷题，要么抱着纸质题册一页页翻，要么在几个零散的刷题小程序之间来回切------这个有章节练习，那个有模拟卷，错题却散在各处；错题抄在本子上，过两周翻回去，连自己当初为什么选错都想不起来；等到想知道"这个月到底刷了多少题、哪一科最拖后腿"，只能凭感觉估。

数据其实一直在产生，只是没落到能用的地方。做毕设时我盯上了这个场景，并且定了个前提：不能只是把纸质题册搬进小程序。如果只是增删改查，那"在线刷题"就只是换了个做题的地方，答辩被问"你的设计点在哪"会很尴尬。所以这套系统的思路是------把科目、章节、知识点、题目分层结构化，让四种练习入口收敛到同一条作答流程，让每一次作答都变成可回溯、可统计的学习记录。

下面先讲系统概述与技术选型，再讲双端分工，最后拆开讲核心实现。重点说三件事：四种练习模式为什么共用一套刷题流程 、错题记录为什么是"写入或更新"而不是每次追加 、模拟考试交卷时到底落了哪些数据。这三块是答辩时最容易被追问的地方。

二、系统概述与技术选型

系统采用前后端分离架构，由面向学生的 uni-app 微信小程序、面向管理员的 Web 管理端，以及 Spring Boot 服务端组成。学生端负责练习、考试和个人学习管理，管理端负责学习内容与运营数据维护，两端共用同一套后端接口和数据表。

层级	主要技术与职责
学生端	uni-app、Vue 3、Pinia、uni-ui、SCSS；提供登录注册、学习首页、刷题训练、模拟考试、错题收藏、学习统计和个人服务入口
管理端	Vue 3、Vite、Element Plus、Pinia、Axios、ECharts；用于题库、科目章节、每日一练、试卷、公告、反馈和学习数据的维护与分析
服务端	Spring Boot 3.3.1、Java 17、MyBatis-Plus、MySQL、JWT；提供 REST 接口、当前用户解析、业务处理、分页查询和数据持久化
数据与资源	以科目、章节、知识点、题目、选项、练习记录、考试记录等数据支撑学习流程，并提供文件上传与静态资源访问能力

服务端采用 Controller、Service、Mapper、Entity、DTO 的分层组织方式，把题库、练习、考试、打卡、公告和分析模块拆成独立业务接口；普通结果与分页结果使用统一的数据结构返回，小程序端与管理端各自封装请求方法调用接口，后端通过 MyBatis-Plus 访问 MySQL。

为什么学生端选 uni-app。 目标用户是随身带手机的学生，刷题这个动作要能在地铁上、睡前、课间发生，所以小程序是天然形态；uni-app 又能让小程序端直接沿用 Vue 3 的技术栈，学生端和管理端在状态管理、请求封装、组件写法上保持一致，少一套心智负担。

三、两块工作区：学生端和管理端

系统区分普通用户和管理员两类角色。学生在小程序端完成注册、登录、找回或修改密码、个人资料维护，进入日常学习流程；管理员通过 Web 管理端进入内容维护与数据分析页面。

角色	主要使用范围
学生（小程序端）	章节练习与专项训练、随机刷题、每日一练、模拟考试、错题本与收藏夹、学习打卡与目标管理、查看公告与个人学习统计
管理员（Web 端）	科目、章节、知识点、题目与选项、试卷与组卷、每日一练配置；练习记录、用户考试记录、学习打卡；公告发布与反馈处理；用户、刷题、题目、考试、打卡、反馈等维度的数据看板

登录成功后，服务端生成 JWT，前端把凭证保存到本地状态与缓存中，后续请求在请求头里带上；后端拦截器解析当前用户及其角色，为角色菜单、个人数据查询和业务记录归属提供依据。

这里有个容易被忽略的点："当前用户"不能由前端传参决定。如果查询"我的错题本"时由前端在参数里带用户 ID，那这个接口就等于对所有人开放；正确做法是拦截器解析令牌后把当前用户放进线程上下文，业务代码从上下文取 ID 拼进查询条件------学生端能拿到的只有自己的数据，这一点在答辩讲"数据范围"时很好用。

四、核心功能与实现

4.1 题库分层：科目---章节---知识点---题目

后台以"科目---章节---知识点---题目"四层结构维护学习内容。题目关联所属科目、章节和知识点，并维护单选题、多选题、判断题等题型，以及难度、来源类型、来源年份、正确答案和解析内容；选项以独立数据保存。

四层结构看着比"一张题目表打天下"麻烦，但它决定了后面所有功能的实现难度：

章节练习要靠"科目 + 章节"条件查题，没有章节表就只能靠题目标题里的文字匹配；
专项练习要按题型、难度、来源年份筛选，这些字段如果不在题目表上，筛选就无从下手；
题目分析要出"来源类型分布""难易题目 TOP20"，统计的前提是这些维度已经被结构化记录下来。

换句话说，统计能力是建表时就决定了的，不是后期加一个图表接口就能补上。被问"为什么不扁平化"时，这是最实在的回答。

4.2 四个练习入口，为什么最后都走同一个作答页

系统提供四种练习方式：

学习入口	题目组织方式
章节练习	先选科目与章节，系统按章节条件查询对应题目，适合按知识结构系统学习
专项练习	按题型、难度、来源年份等条件筛选题目，围绕薄弱题型或特定来源集中训练
随机练习	前端获取符合条件的题目后打乱顺序，形成随机化的刷题过程
每日一练	按当天已配置的每日一练及其题目明细进入练习，固定频率的学习入口

四种入口的差别只在"题目怎么来"，题目拿到之后的一切都一样。 所以代码上把它们收敛到同一个作答页面：

复制代码

章节练习 ┐
专项练习 ┤→ 按条件取题 → 统一作答页 → 即时判题 → 展示解析
随机练习 ┤                ↓
每日一练 ┘            保存练习记录 → 答错写错题本 → 汇入学习统计

好处很直接：判题规则、解析展示、记录写入、错题沉淀只有一份实现。如果四种练习各写一套作答页，往后改一次判题口径就要改四处，早晚会出现"章节练习判对了、专项练习判错了"这类很难复现的问题；而且新加一种练习方式时，只需要写"题目从哪来"，不用再抄一遍作答逻辑。

4.3 分题型的即时判题与逐题记录

作答页按题型提供不同交互：单选题 选择后直接判题，多选题 在选择完成并确认后判题，判断题以"正确、错误"作为固定作答项。判题后展示正确答案与题目解析，并支持上一题、下一题与答题卡跳转。

每次作答会记录用户、题目、练习模式、用户答案、是否正确和用时；答错时同步写入或更新错题记录。这组字段看着普通，但它是后面所有统计的原料：

有"是否正确"，才能算正确率和科目对比；
有"用时"，才能出平均答题速度；
有"练习模式"，才能画练习模式分布；
有"题目 ID"，才能反查某道题被做错多少次。

如果只存一个"本次练习得了多少分"，这些图一个都画不出来。 记录粒度决定分析上限，这是做统计功能时最值得写进论文的一句话。

4.4 错题本：为什么是"写入或更新"，而不是每次追加

错题本记录用户答错的题目、错误次数、最近错误时间和掌握状态。学生可查看错题对应的题干、正确答案与解析，选择单题重做或批量重做，并在掌握后更新状态。

这里的实现关键在于去重写入 ：同一道题第一次做错时创建错题记录，之后再错就更新同一条记录------错误次数加一、最近错误时间刷新、掌握状态按规则调整。

如果改成"每错一次追加一条"，会出现三个问题：

错题本列表里同一道题出现 5 次，重复堆积，复习时反而更难定位真正的薄弱点；
"这道题我错过几次"要从多条记录里数，查询和展示都变复杂；
学生在错题本里点"重做"，到底重做的是哪一条？归属不清。

错误次数和最近错误时间本来就是同一道题的累计属性，把它放在一条记录上，语义才对得上。

收藏夹是另一条线索：它保存学生主动标记的重点题目，支持收藏、取消收藏、查看详情和集合练习。错题本记"被动做错的题"，收藏夹记"主动想再看一遍的题"，两者分开沉淀，考前复习时就有了两个不同维度的入口。

4.5 每日一练、学习目标与打卡进度

管理员可为指定日期创建每日一练，并为其配置题目和题目顺序；小程序首页加载当日配置后，展示"每日一练"入口和题目数量。学生也可以在个人学习目标页面设置每日刷题目标。

系统以学习打卡记录保存每日刷题数量、正确数量和学习时长，首页据此展示当天刷题数、正确率、连续打卡天数以及科目学习进度。

这里有个设计选择值得说：打卡是按天汇总的独立记录，不是页面上的实时统计。

理由是"历史数据要稳定"。连续打卡天数、历史每日正确率、学习时长趋势这些数字，代表的是那一天当时的情况。如果每次打开首页都拿练习记录实时重算，那么这周新增了题目、学生重做了错题，上周的曲线也会跟着变，论文里画的趋势图就失去了可比性------一张会随数据增删而变化的趋势图，说明不了任何趋势。

4.6 模拟考试：组卷、答题卡与交卷落两份数据

后台可以维护试卷名称、总分、考试时长、题目数量和发布状态，提供手动组卷与自动组卷两个页面；试卷题目明细保留题目分值和排序。学生在小程序端查看已发布试卷后进入考试，作答过程中维护当前答案与标记状态，答题卡区分已答、未答和标记题目。

交卷时，系统会写入两份数据：

记录	保存内容	回答的问题
考试记录	得分、正确数、错误数、用时、交卷时间	这场考试考得怎么样
逐题答案记录	考生、试卷、每道题的作答与正误	每一道题我到底选了什么

只有前者的话，成绩单上的分数无从解释；只有后者的话，列表页要按试卷逐条聚合才能显示一行成绩------一次交卷写两份，成绩可追溯、明细可复盘。

结果页支持按全部、错题、标记题三种视角查看作答情况、正确答案与解析。这个设计是照着真实考试习惯来的：考完先看总分，再看错在哪，最后回看那些"当时拿不准、先标记一下"的题------三类题的复习价值完全不同，混在一个列表里看很浪费。

4.7 公告、反馈与内容运营

管理员维护公告标题、内容、置顶和发布状态；小程序首页展示公告入口，用户进入公告列表查看已发布内容。用户也可以通过反馈页面提交文字和图片，服务端提供文件上传接口处理相关资源；后台集中查看反馈，填写回复内容、记录回复时间和处理状态。

把"学习内容发布"和"使用反馈"放在同一套运营流程里，好处是内容维护有出口、使用问题有入口：公告负责把重要节点（比如新考点更新、模考安排）推给全部学生，反馈负责收集单点问题，两者都在管理端有明确的处理状态，不会出现"学生反馈了但没人知道"的情况。

4.8 数据分析：一个页面同时回答两个问题

管理端首页与分析页面使用 ECharts 呈现统计结果，覆盖用户、刷题、题目、考试、打卡和反馈等维度：

分析模块	主要数据关注点
首页看板	用户数、题目数、当日活跃用户、当日刷题量、新增用户和考试参与情况等概览数据
用户与刷题分析	用户注册、活跃趋势、刷题排行榜、学习时长、打卡天数、刷题趋势、科目对比、正确率和练习模式分布
题目与考试分析	题目总量、难易题、正确率、来源分布，以及考试参与人数、成绩分布、平均分、考试趋势和用时分布
打卡与反馈分析	每日打卡趋势、学习时长、正确率，以及反馈数量、回复率、回复时效和每日反馈趋势