简介这是一份基于微信小程序与SSM框架的在线考试系统完整源码包主要面向高校学生、课程设计及毕业设计开发者。系统已实现管理员端与用户端管理员可维护用户、考试资料、试题试卷、留言板及系统公告用户可注册登录、浏览资料、在线参加考试并查看成绩覆盖常见考试业务闭环。后端使用Java SSMSpringSpringMVCMyBatis搭配MySQL数据库小程序端采用微信原生框架开发前后端职责划分清晰。压缩包共1107个文件包含Java、Vue、JS等程序源码WXML/WXSS小程序页面PNG/SVG界面资源以及SQL建表脚本与项目配置文件合计16.19MB结构完整便于本地导入运行。已有343人学习下载资源内附完整工程与配置说明可辅助在本地配置运行适合参考其权限控制、组卷逻辑与考试状态流转等内容能有效缩短毕业设计或课程项目的开发周期。1. 考试系统难的不是答题页而是交卷那三秒这是一套什么方案拿到「基于微信小程序的考试系统设计与实现」这个题目时很多人的第一反应是「做个答题页面还不简单」。但真正跑过一遍完整流程后你会发现这个系统最容易被演示环节击穿的恰好是交卷那一刻网络闪断导致成绩丢、倒计时被切后台坑掉、题目乱序后答案对不上、重复提交产生两条成绩。这套基于微信小程序的考试系统设计方案解决的正是「题目展示、计时作答、交卷判分、成绩留存」这条完整链路并且把微信生态的登录能力直接复用省去了传统网页考试系统最麻烦的账号注册与找回密码环节。它适合三类人拿它当毕业设计选题、需要在答辩现场完整演示业务闭环的学生想为内部培训、社团招新、课程测验快速搭一套轻量考试工具的中小团队以及准备做考试类产品原型验证的开发者。2. 选型与数据设计考试小程序为什么用云函数加文档库就够2.1 三种落地方案的对比云开发、自建接口、第三方 BaaS考试系统的技术选型本质上是「服务器谁养、鉴权怎么做、数据放哪里」三个问题的权衡。目前最常见的做法有三种小程序云开发、自建后端接口、接入第三方 BaaS 平台。很多人一上来就选自建接口觉得这样显得技术含量高但如果你是做毕设或者小范围内部考试云开发反而是性价比最高的选择。方案部署成本开发量鉴权实现适合场景小程序云开发低无需买服务器和域名中前端 云函数 云数据库云函数上下文直接拿 openid毕设、小规模内部考试、快速原型自建后端接口高需要服务器、域名备案、HTTPS高需要写完整的用户体系和接口层wx.login 拿 code 换 openid再自签 token对数据安全、性能有强要求的生产系统第三方 BaaS低接入即用低但业务逻辑受平台限制使用平台账号体系原型验证、非核心业务我一般会建议多数读者优先选云开发。原因很直接考试系统的核心业务是「题库、试卷、答卷、成绩」这四类数据的关系维护而不是服务器运维。云开发天然解决了 openid 获取、鉴权、数据库读写这三个最耗时的问题而且微信开发者工具里可以一键部署云函数调试起来非常顺。自建接口适合的场景是你需要对成绩做防篡改审计、需要对接学校现有统一身份认证、或者预估同时在线考试人数超过千人。如果只是演示闭环和应对几十人同时考云开发完全够用。2.2 数据表怎么定题目、试卷、答题记录、成绩的四种关系考试系统的数据设计是整个项目的骨架。很多人在写代码前不画数据关系结果做到答题记录时发现「试卷里的题目」和「题库里的题目」混在一起改题库会把历史试卷也改掉。这里给出的是一套以文档型数据库为例的集合划分换成 MySQL 等关系型数据库同样可以按这个思路建表。集合/表核心字段作用usersopenid、nickname、avatarUrl、createdAt用户基础信息openid 是微信生态唯一标识questionssubjectId、type、content、options、answerIndex、analysis题库题目与答案分离paperssubjectId、title、questions 快照、durationSeconds、createdAt试卷存的是组卷时刻的题目快照answersopenid、paperId、questionId、type、value、spendSeconds、submitAt逐题答题记录用于错题回看和行为分析scoresopenid、paperId、score、totalScore、submitAt成绩单一次考试一条记录这里最关键的设计决策是「试卷题目用快照不用关联查询」。组卷时把选中题目完整拷贝进 papers 集合的 questions 字段而不是存题目 ID 数组、每次考试时再去题库里联表查。这样做的直接好处是如果考试进行到一半管理员修改了题库里的某道题已开始考试的学生拿到的题目不会变成绩也不会被题库改动污染。代价是同一道题在数据库里可能有多份拷贝但对于考试系统这个体量这点存储成本完全可接受。2.3 考试状态机从「未开始」到「已交卷」的六个状态考试流程不能只靠前端页面控制服务端必须维护一份状态机否则学生可以绕过页面直接调接口交卷或者重复交卷刷成绩。我在设计时会把试卷状态拆成以下六种前端的按钮展示和后端的接口校验都围绕这套状态来做。状态值含义前端表现draft草稿组卷未完成不可见published已发布等待开考显示「开始考试」按钮ongoing进行中有考生正在作答显示倒计时与答题卡submitted已交卷等待批阅等待成绩graded已出分显示成绩与错题回顾closed已关闭只读状态可查看历史成绩状态机的核心价值在于「交卷接口的幂等性」。当同一个学生重复提交试卷时后端只需要判断 paperId 对应的状态是否已经是 submitted 或 graded是就直接返回第一次的成绩而不是重新判分、重新写一条成绩记录。这个设计在弱网环境下非常重要因为客户端可能发起了请求、服务端已经处理成功但响应包没回到客户端学生以为没交上又点了一次交卷。没有状态机做兜底就会出现「一次考试两条成绩」的翻车现场。3. 小程序端核心实现倒计时、答题卡、交卷的最小可跑代码3.1 答题页的数据结构与题型归一化考试系统最常见的题型是单选、多选、判断、填空。如果为每一种题型单独写一套页面逻辑代码会非常臃肿。我一般会做一层「题型归一化」把四种题型统一成一个答题数据结构页面只负责渲染提交时一律按这个结构走。// questionTypes.js 题型常量与答题结构归一化 const QUESTION_TYPES { RADIO: radio, // 单选value 存选中项下标如 2 CHECKBOX: checkbox, // 多选value 存选中项下标数组如 [0, 2] JUDGE: judge, // 判断value 存 0 或 1 FILL: fill // 填空value 存用户输入的字符串 } // 每道题的答题结果统一为以下对象 // 记录 spendSeconds 可以用于后续的答题行为分析也可以在成绩页展示用时 const answerItem { questionId: q_1024, type: QUESTION_TYPES.RADIO, value: 2, spendSeconds: 12 }这里要注意一个高频翻车点多选题的 value 必须是数组且数组里存的是选项下标而不是选项文本。因为前端展示时可能会做题目乱序一旦乱序选项下标对应的文本就变了如果你存的是文本后续判分和题目快照对照时非常容易错位。判分时用「题目快照里的 answerIndex 数组」和「用户提交的 value 数组」做集合比较两个数组排序后相等才算对。填空则要注意去除首尾空格再比对避免学生多打一个空格被判错。3.2 倒计时与切后台为什么 setInterval 会「自己停下」倒计时是考试小程序里遇到坑最多的模块。很多初学者的第一版是用 setInterval 每秒递减一个剩余秒数变量真机一测就翻车把小程序切到后台回个微信消息再切回来倒计时还在走但已经比真实时间慢了十几秒。原因是小程序在后台运行时JS 定时器会被系统挂起等回到前台才继续执行。解法很简单不要累减变量而是用「绝对截止时间戳」做差值。// countdown.js 基于时间戳的倒计时封装 const DEFAULT_DURATION 1800 // 考试时长单位秒30分钟 const GRACE_SECONDS 5 // 宽限秒数防止用户在最后一刻误触交卷 function startCountdown(deadlineTs, onTick, onTimeout) { const timer setInterval(() { const remainMs deadlineTs - Date.now() const remainSec Math.ceil(remainMs / 1000) if (remainSec 0) { clearInterval(timer) onTick(0) onTimeout() return } onTick(remainSec) }, 500) // 每500ms刷新一次避免每秒一次的视觉卡顿 }这个封装的要点是deadlineTs 不是「剩余多少秒」而是「开考时间 考试时长」得到的绝对时间戳。开考时间由服务端下发的serverTime计算不能用本地时间因为考生手机的系统时间可能不准。切后台再回来时只需要在页面的 onShow 生命周期里重新执行一次Date.now()与 deadlineTs 的差值计算倒计时自然就校准了。GRACE_SECONDS 的作用是倒计时归零时先不强杀进入一个 5 秒的宽限期这 5 秒内学生如果正在点交卷按钮仍然视为有效提交超过宽限期则强制提交当前已答内容。3.3 交卷的本地缓存与服务端判分边界交卷是整个系统里最不能出错的环节因为网络不可靠是常态但学生的答题结果必须可靠。我推荐的做法是「先写本地缓存再请求服务端请求成功才清缓存失败则保留待重试」。这样即使学生在考试结束那一刻断网成绩也不会静默丢失。// submitExam.js 交卷核心流程 async function submitExam(paperId, answers) { // 第1步先把答卷写入本地缓存作为断网兜底 wx.setStorageSync(pending_${paperId}, { answers, submitAt: Date.now() }) // 第2步调用云函数或自建后端接口 try { const res await wx.cloud.callFunction({ name: submitExam, data: { paperId, answers } }) const result res.result if (result.code 0) { // 服务端确认接收后才清理本地缓存 wx.removeStorageSync(pending_${paperId}) wx.redirectTo({ url: /pages/result/result?paperId${paperId}score${result.score} }) } else { wx.showToast({ title: result.msg || 提交失败, icon: none }) } } catch (err) { // 网络异常时保留缓存回到页面提示用户重试 wx.showToast({ title: 提交失败已暂存本地待重试, icon: none }) } }交卷后判分放在哪一端取决于你更看重「响应速度」还是「结果可信」。纯前端判分的好处是秒出成绩演示效果好但如果学生用抓包工具改了答题数据前端判分的结果就不具备公信力。我在实际项目中采用的折中方案是前端先本地判分用于秒开成绩页同时把答案原样提交给服务端服务端异步重新判分并覆盖成绩前端页面展示的成绩以服务端最终结果为准。这样兼顾了体验和可信度。云函数的超时时间默认只有 3 秒如果试卷题量大判分逻辑放在云函数里很容易超时这也是为什么把判分拆到客户端会更稳的原因之一。4. 后端鉴权与题库接入从登录到组卷的完整链路4.1 登录鉴权wx.login 换 openid 后为什么要再签一层 token微信小程序的登录体系已经相当成熟但很多初学者容易犯一个错误把前端拿到的 openid 当成唯一凭证到处用。openid 是用户的弱隐私标识它出现在前端代码和请求参数里一旦被别人截获就可以伪造身份提交答卷。正确做法是用 openid 换一个后端签发的临时 token后续所有接口都校验 token。// 云函数 login/index.js登录并签发 token const cloud require(wx-server-sdk) cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV }) const db cloud.database() exports.main async (event) { // 云函数上下文里直接拿 openid不需要前端传 const { OPENID } cloud.getWXContext() const users db.collection(users) // 用户不存在时自动注册 const existed await users.where({ openid: OPENID }).get() if (existed.data.length 0) { await users.add({ data: { openid: OPENID, nickname: 考生, createdAt: Date.now() } }) } // 签发临时 token2小时过期 const token t_ Date.now() _ Math.random().toString(36).slice(2, 10) await db.collection(sessions).add({ data: { token, openid: OPENID, expiresAt: Date.now() 7200 * 1000 } }) return { code: 0, token, expiresIn: 7200 } }这个云函数的逻辑说明小程序端先通过wx.login()拿到 code但云开发场景下前端不需要传 code云函数调用时微信会自动注入 openid。sessions 集合用来存有效 token前端每次请求把 token 放在 header 或 data 里后端校验时去 sessions 集合查这个 token 是否存在且未过期。expiresIn 的单位是秒7200 表示两小时实际项目中可以根据考试时长调整一般设为考试时长的 1.5 倍即可。如果自建后端流程是前端用 code 调微信接口换 openid后端再签发 token逻辑等价。4.2 题库导入Excel 转 JSON 时最容易破坏的三个字段题库数据是整个系统的心脏。很多人在搭建题库时选择了人工一条条往数据库里录入效率极低且容易错。常见做法是用 Excel 维护题库再通过脚本批量转成 JSON 导入。这个转换过程有三个字段非常容易出错。{ subject: 计算机网络, questions: [ { id: q_1001, type: radio, content: OSI 参考模型共有几层, options: [4, 5, 6, 7], answerIndex: 3, analysis: OSI 分为物理、数据链路、网络、传输、会话、表示、应用七层。 }, { id: q_1002, type: checkbox, content: 以下属于传输层协议的是, options: [TCP, UDP, IP, HTTP], answerIndex: [0, 1] } ] }第一个易错字段是 options 的排列顺序。Excel 导入时如果选项列被排序工具重排过前端展示的顺序和后端 answerIndex 的对应关系就会被打破。第二个易错字段是答案索引单选用数字下标多选必须用数组判断题的 answerIndex 建议统一用 1 表示正确、0 表示错误不要混用 true/false 和「对/错」文本。第三个易错点是题干中的特殊字符比如答案里的英文双引号、换行符如果不做转义JSON.parse 会直接报错导入脚本必须对这类字符做预处理。4.3 组卷策略固定抽题、随机抽题、试卷快照组卷是考试系统区别于普通答题工具的关键功能。一套题库要能生成多套试卷每套试卷又能被多次考试使用这需要把「组卷」和「考试」做成两个独立环节。// buildPaper.js 组卷函数固定概率抽题并生成试卷快照 function buildPaper(subjectId, countPerType, shuffle) { // countPerType 示例{ radio: 10, checkbox: 5, judge: 5, fill: 3 } const snapshotQuestions pickQuestions(subjectId, countPerType, shuffle) // 把题目快照整体写入 paper 记录 // 后续修改题库不影响已生成的试卷 const paper { subjectId, title: subjectId 标准模拟卷, questions: snapshotQuestions, durationSeconds: 1800, createdAt: Date.now() } return db.collection(papers).add({ data: paper }) } // pickQuestions 内部逻辑按题型分组后从题库里随机取指定数量 // shuffle 为 true 时同时对题目顺序和每道题的选项顺序做乱序 function pickQuestions(subjectId, countPerType, shuffle) { // 从题库按 subjectId type 过滤每组随机取 count 道 // 若题库题量不足需要提前做完整性校验避免组出一张不够题的试卷 }组卷的核心逻辑理解countPerType是各题型的题目数量比如单选题 10 道、多选题 5 道、判断题 5 道、填空题 3 道。shuffle开关控制是否乱序乱序时必须把题目的 answerIndex 一起重新映射这就是前面章节反复强调的坑——洗牌只洗了 options 数组没有同步更新答案下标判断题和多选题就会大面积误判。试卷快照的意义前面已经说过是为了保证成绩可复现。另外还有一个实用习惯组卷时生成一张考试说明页把题型分布、每题分值、考试时长一起展示给学生这套数据也一起写进 paper 记录避免前端写死。5. 避坑手册考试小程序最容易翻车的六个现场5.1 倒计时切后台回来后还在走但交卷时间已超现象考生把小程序切到后台回微信消息再切回来页面倒计时显示还剩 10 分钟但服务端校验时发现考试已经超时拒绝接收答卷。 原因setInterval 在小程序后台被系统挂起回到前台才恢复而且代码里用的是递减变量而不是绝对时间戳差值。 解决倒计时一律基于deadlineTs - Date.now()计算deadlineTs 存在全局变量或 storage 中页面的 onShow 生命周期里重新计算一次剩余时间并刷新 UI。服务端同步校验收卷时间以服务端时间为准绝不信任客户端上报的本地时间。5.2 真机预览请求失败开发者工具却一切正常现象在微信开发者工具里点击交卷、加载题库都正常一换成真机预览接口请求全部报request:fail url not in domain list。 原因开发者工具默认关闭了合法域名校验而真机上微信强制校验 request 请求的域名必须在小程序后台配置过云开发调用走 wx.cloud 系列接口不受此限制自建接口则必须配置合法域名。 解决云开发场景直接用wx.cloud.callFunction不要手动拼 URL。自建接口场景在小程序管理后台配置 request 合法域名域名必须备案并支持 HTTPS。开发者工具里关闭校验只能用于本地调试不能作为真机方案。5.3 主包超过 2MB代码上传一直失败现象代码写完后上传提示主包体积超过 2MB无法提交审核。 原因最常见的体积杀手是题库数据被直接写在代码里一个包含几百道题带图片的 JSON 文件就能占掉大几百 KB如果还塞了教材配套音频、图片素材超限是必然的。 解决题库数据移入云数据库或后端小程序端按需拉取题目不要整个文件打进包里。大体积的静态资源用小程序的运行时分包加载或者放到云存储后按需下载。注意主包体积限制是 2MB整个小程序总包上限是 20MB分包不是万能药资源能走后端就走后端。5.4 交卷时网络闪断成绩静默丢失现象学生在考试结束前最后 10 秒点了交卷页面一直转圈最后提示网络错误学生刷新后重新进入发现没有成绩于是又做了一遍数据库里出现两条答卷记录。 原因前端直接请求后端断网时请求失败且没有重试机制后端接口没有做幂等同一学生同一试卷提交多次会生成多条成绩。 解决前端在发起请求前先把答卷写入本地缓存请求成功后才清理缓存失败时保留缓存并提示用户重试后端对openid paperId做唯一约束或重复提交检测已经交过卷的请求直接返回第一次成绩。两个措施缺一不可只做前端的缓存换一台设备成绩依然会丢。5.5 题目乱序后答案对不上多选题翻车最严重现象开启题目乱序和选项乱序后学生反馈「我明明选了对的却给我判错」其中多选题错得最多。 原因乱序函数只打乱了 options 数组的顺序没有同步更新题目的 answerIndex。单选题碰巧首选项相同的还能对上多选题本身答案就是多个下标错位后几乎不可能蒙对。 解决洗牌时用一个映射数组把旧下标和新下标的关系保留下来答题和判分时统一使用「新下标」体系。前端 value 永远存选项下标不存选项文本判分前用题目快照中的 answerIndex 和用户提交的 value 做排序后比较。5.6 云函数默认超时太短判分跑到一半被掐断现象本地调试云函数时一切正常真机上交卷后频繁提示「云函数调用超时」考试成绩偶尔能存上、偶尔存不上。 原因云函数的默认超时时间只有 3 秒。一张卷子 30 道题判分逻辑加写库操作在弱网环境下很容易超过 3 秒而且每次调用都会冷启动首次调用耗时更高。 解决把耗时的判分逻辑移到客户端本地执行云函数只做简单的数据校验和成绩落库或者在小程序云开发控制台把该云函数的超时时间调大到 10~20 秒如果题目量特别大就改成异步任务交卷接口先返回「已受理」判分完成后通过订阅消息或手动刷新获取成绩。6. 让系统经得起演示并发交卷与弱网联调的验证习惯答辩现场最怕的不是功能没做完而是演示到交卷那一步突然翻车。我的习惯是每次改动代码后都按一套标准的测试矩阵在真机上完整走一遍而不是只在开发者工具里点两下就收工。测试场景操作方式通过标准正常交卷完整答完一张卷点击交卷成绩页秒开数据库成绩记录唯一弱网交卷开发者工具开启弱网模拟再点交卷前端提示暂存本地网络恢复后重试成功切后台再交卷答到一半切后台等 30 秒再回来立即交卷倒计时校准后扣除后台时长交卷正常重复提交交卷成功后返回页面再次点交卷后端返回第一次成绩不产生新记录乱序判分开启乱序后用已知答案的测试账号作答得分与人工判卷完全一致验证弱网时微信开发者工具的「模拟弱网」只是低配方案真机 4G 网络信号弱的环境更容易暴露问题。我在封装交卷模块时习惯在日志里打印每一步的耗时如果从点击交卷到看到成绩页超过 5 秒就说明判分或写库链路有优化空间。并发联动在考试小程序里不好用 curl 直接压测更实际的做法是准备三五个测试账号在同一台路由器下同时交卷看成绩是否全部落库。最后说一个我自己的教训最初我把判分逻辑完整地写在云函数里真机演示时连续三次超时一度怀疑是网络问题后来才发现是默认超时只有 3 秒冷启动再加几十道题的判分循环根本跑不完。把判分挪回客户端本地执行、云函数只做校验和存储之后交卷体验才真正稳定下来。考试系统这类项目前端交互做得再花哨都不如「倒计时不漂移、交卷不丢数据、重复提交不出错」这三个底线来得实在。希望你做完这套系统后能在演示现场从容地说一句「你们随便考我先交卷」这比任何花哨的功能都更能打动评委希望帮到你。本文还有配套的精品资源点击获取