企业官网建设流程全解析

简介：这是一份基于微信小程序与SSM框架的在线考试系统完整源码包，主要面向高校学生、课程设计及毕业设计开发者。系统已实现管理员端与用户端：管理员可维护用户、考试资料、试题试卷、留言板及系统公告，用户可注册登录、浏览资料、在线参加考试并查看成绩，覆盖常见考试业务闭环。后端使用Java SSM（Spring+SpringMVC+MyBatis）搭配MySQL数据库，小程序端采用微信原生框架开发，前后端职责划分清晰。压缩包共1107个文件，包含Java、Vue、JS等程序源码，WXML/WXSS小程序页面，PNG/SVG界面资源，以及SQL建表脚本与项目配置文件，合计16.19MB，结构完整便于本地导入运行。已有343人学习下载，资源内附完整工程与配置说明，可辅助在本地配置运行，适合参考其权限控制、组卷逻辑与考试状态流转等内容，能有效缩短毕业设计或课程项目的开发周期。

1. 考试系统难的不是答题页，而是交卷那三秒：这是一套什么方案

拿到「基于微信小程序的考试系统设计与实现」这个题目时，很多人的第一反应是「做个答题页面还不简单」。但真正跑过一遍完整流程后你会发现，这个系统最容易被演示环节击穿的，恰好是交卷那一刻：网络闪断导致成绩丢、倒计时被切后台坑掉、题目乱序后答案对不上、重复提交产生两条成绩。这套基于微信小程序的考试系统设计方案，解决的正是「题目展示、计时作答、交卷判分、成绩留存」这条完整链路，并且把微信生态的登录能力直接复用，省去了传统网页考试系统最麻烦的账号注册与找回密码环节。它适合三类人：拿它当毕业设计选题、需要在答辩现场完整演示业务闭环的学生；想为内部培训、社团招新、课程测验快速搭一套轻量考试工具的中小团队；以及准备做考试类产品原型验证的开发者。

2. 选型与数据设计：考试小程序为什么用云函数加文档库就够

2.1 三种落地方案的对比：云开发、自建接口、第三方 BaaS

考试系统的技术选型，本质上是「服务器谁养、鉴权怎么做、数据放哪里」三个问题的权衡。目前最常见的做法有三种：小程序云开发、自建后端接口、接入第三方 BaaS 平台。很多人一上来就选自建接口，觉得这样显得技术含量高，但如果你是做毕设或者小范围内部考试，云开发反而是性价比最高的选择。

我一般会建议多数读者优先选云开发。原因很直接：考试系统的核心业务是「题库、试卷、答卷、成绩」这四类数据的关系维护，而不是服务器运维。云开发天然解决了 openid 获取、鉴权、数据库读写这三个最耗时的问题，而且微信开发者工具里可以一键部署云函数，调试起来非常顺。自建接口适合的场景是：你需要对成绩做防篡改审计、需要对接学校现有统一身份认证、或者预估同时在线考试人数超过千人。如果只是演示闭环和应对几十人同时考，云开发完全够用。

2.2 数据表怎么定：题目、试卷、答题记录、成绩的四种关系

考试系统的数据设计是整个项目的骨架。很多人在写代码前不画数据关系，结果做到答题记录时发现「试卷里的题目」和「题库里的题目」混在一起，改题库会把历史试卷也改掉。这里给出的是一套以文档型数据库为例的集合划分，换成 MySQL 等关系型数据库同样可以按这个思路建表。

这里最关键的设计决策是「试卷题目用快照，不用关联查询」。组卷时把选中题目完整拷贝进 papers 集合的 questions 字段，而不是存题目 ID 数组、每次考试时再去题库里联表查。这样做的直接好处是：如果考试进行到一半，管理员修改了题库里的某道题，已开始考试的学生拿到的题目不会变，成绩也不会被题库改动污染。代价是同一道题在数据库里可能有多份拷贝，但对于考试系统这个体量，这点存储成本完全可接受。

2.3 考试状态机：从「未开始」到「已交卷」的六个状态

考试流程不能只靠前端页面控制，服务端必须维护一份状态机，否则学生可以绕过页面直接调接口交卷，或者重复交卷刷成绩。我在设计时会把试卷状态拆成以下六种，前端的按钮展示和后端的接口校验都围绕这套状态来做。

状态机的核心价值在于「交卷接口的幂等性」。当同一个学生重复提交试卷时，后端只需要判断 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() } }) } // 签发临时 token，2小时过期 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. 让系统经得起演示：并发交卷与弱网联调的验证习惯

答辩现场最怕的不是功能没做完，而是演示到交卷那一步突然翻车。我的习惯是每次改动代码后，都按一套标准的测试矩阵在真机上完整走一遍，而不是只在开发者工具里点两下就收工。

验证弱网时，微信开发者工具的「模拟弱网」只是低配方案，真机 4G 网络信号弱的环境更容易暴露问题。我在封装交卷模块时习惯在日志里打印每一步的耗时，如果从点击交卷到看到成绩页超过 5 秒，就说明判分或写库链路有优化空间。并发联动在考试小程序里不好用 curl 直接压测，更实际的做法是准备三五个测试账号，在同一台路由器下同时交卷，看成绩是否全部落库。

最后说一个我自己的教训：最初我把判分逻辑完整地写在云函数里，真机演示时连续三次超时，一度怀疑是网络问题，后来才发现是默认超时只有 3 秒，冷启动再加几十道题的判分循环，根本跑不完。把判分挪回客户端本地执行、云函数只做校验和存储之后，交卷体验才真正稳定下来。考试系统这类项目，前端交互做得再花哨，都不如「倒计时不漂移、交卷不丢数据、重复提交不出错」这三个底线来得实在。希望你做完这套系统后，能在演示现场从容地说一句「你们随便考，我先交卷」，这比任何花哨的功能都更能打动评委，希望帮到你。

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