簡介這是一份基于微信小程序與SSM框架的在線考試系統(tǒng)完整源碼包主要面向高校學(xué)生、課程設(shè)計(jì)及畢業(yè)設(shè)計(jì)開發(fā)者。系統(tǒng)已實(shí)現(xiàn)管理員端與用戶端管理員可維護(hù)用戶、考試資料、試題試卷、留言板及系統(tǒng)公告用戶可注冊(cè)登錄、瀏覽資料、在線參加考試并查看成績覆蓋常見考試業(yè)務(wù)閉環(huán)。后端使用Java SSMSpringSpringMVCMyBatis搭配MySQL數(shù)據(jù)庫小程序端采用微信原生框架開發(fā)前后端職責(zé)劃分清晰。壓縮包共1107個(gè)文件包含Java、Vue、JS等程序源碼WXML/WXSS小程序頁面PNG/SVG界面資源以及SQL建表腳本與項(xiàng)目配置文件合計(jì)16.19MB結(jié)構(gòu)完整便于本地導(dǎo)入運(yùn)行。已有343人學(xué)習(xí)下載資源內(nèi)附完整工程與配置說明可輔助在本地配置運(yùn)行適合參考其權(quán)限控制、組卷邏輯與考試狀態(tài)流轉(zhuǎn)等內(nèi)容能有效縮短畢業(yè)設(shè)計(jì)或課程項(xiàng)目的開發(fā)周期。1. 考試系統(tǒng)難的不是答題頁而是交卷那三秒這是一套什么方案拿到「基于微信小程序的考試系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)」這個(gè)題目時(shí)很多人的第一反應(yīng)是「做個(gè)答題頁面還不簡單」。但真正跑過一遍完整流程后你會(huì)發(fā)現(xiàn)這個(gè)系統(tǒng)最容易被演示環(huán)節(jié)擊穿的恰好是交卷那一刻網(wǎng)絡(luò)閃斷導(dǎo)致成績丟、倒計(jì)時(shí)被切后臺(tái)坑掉、題目亂序后答案對(duì)不上、重復(fù)提交產(chǎn)生兩條成績。這套基于微信小程序的考試系統(tǒng)設(shè)計(jì)方案解決的正是「題目展示、計(jì)時(shí)作答、交卷判分、成績留存」這條完整鏈路并且把微信生態(tài)的登錄能力直接復(fù)用省去了傳統(tǒng)網(wǎng)頁考試系統(tǒng)最麻煩的賬號(hào)注冊(cè)與找回密碼環(huán)節(jié)。它適合三類人拿它當(dāng)畢業(yè)設(shè)計(jì)選題、需要在答辯現(xiàn)場完整演示業(yè)務(wù)閉環(huán)的學(xué)生想為內(nèi)部培訓(xùn)、社團(tuán)招新、課程測驗(yàn)快速搭一套輕量考試工具的中小團(tuán)隊(duì)以及準(zhǔn)備做考試類產(chǎn)品原型驗(yàn)證的開發(fā)者。2. 選型與數(shù)據(jù)設(shè)計(jì)考試小程序?yàn)槭裁从迷坪瘮?shù)加文檔庫就夠2.1 三種落地方案的對(duì)比云開發(fā)、自建接口、第三方 BaaS考試系統(tǒng)的技術(shù)選型本質(zhì)上是「服務(wù)器誰養(yǎng)、鑒權(quán)怎么做、數(shù)據(jù)放哪里」三個(gè)問題的權(quán)衡。目前最常見的做法有三種小程序云開發(fā)、自建后端接口、接入第三方 BaaS 平臺(tái)。很多人一上來就選自建接口覺得這樣顯得技術(shù)含量高但如果你是做畢設(shè)或者小范圍內(nèi)部考試云開發(fā)反而是性價(jià)比最高的選擇。方案部署成本開發(fā)量鑒權(quán)實(shí)現(xiàn)適合場景小程序云開發(fā)低無需買服務(wù)器和域名中前端 云函數(shù) 云數(shù)據(jù)庫云函數(shù)上下文直接拿 openid畢設(shè)、小規(guī)模內(nèi)部考試、快速原型自建后端接口高需要服務(wù)器、域名備案、HTTPS高需要寫完整的用戶體系和接口層wx.login 拿 code 換 openid再自簽 token對(duì)數(shù)據(jù)安全、性能有強(qiáng)要求的生產(chǎn)系統(tǒng)第三方 BaaS低接入即用低但業(yè)務(wù)邏輯受平臺(tái)限制使用平臺(tái)賬號(hào)體系原型驗(yàn)證、非核心業(yè)務(wù)我一般會(huì)建議多數(shù)讀者優(yōu)先選云開發(fā)。原因很直接考試系統(tǒng)的核心業(yè)務(wù)是「題庫、試卷、答卷、成績」這四類數(shù)據(jù)的關(guān)系維護(hù)而不是服務(wù)器運(yùn)維。云開發(fā)天然解決了 openid 獲取、鑒權(quán)、數(shù)據(jù)庫讀寫這三個(gè)最耗時(shí)的問題而且微信開發(fā)者工具里可以一鍵部署云函數(shù)調(diào)試起來非常順。自建接口適合的場景是你需要對(duì)成績做防篡改審計(jì)、需要對(duì)接學(xué)?，F(xiàn)有統(tǒng)一身份認(rèn)證、或者預(yù)估同時(shí)在線考試人數(shù)超過千人。如果只是演示閉環(huán)和應(yīng)對(duì)幾十人同時(shí)考云開發(fā)完全夠用。2.2 數(shù)據(jù)表怎么定題目、試卷、答題記錄、成績的四種關(guān)系考試系統(tǒng)的數(shù)據(jù)設(shè)計(jì)是整個(gè)項(xiàng)目的骨架。很多人在寫代碼前不畫數(shù)據(jù)關(guān)系結(jié)果做到答題記錄時(shí)發(fā)現(xiàn)「試卷里的題目」和「題庫里的題目」混在一起改題庫會(huì)把歷史試卷也改掉。這里給出的是一套以文檔型數(shù)據(jù)庫為例的集合劃分換成 MySQL 等關(guān)系型數(shù)據(jù)庫同樣可以按這個(gè)思路建表。集合/表核心字段作用usersopenid、nickname、avatarUrl、createdAt用戶基礎(chǔ)信息openid 是微信生態(tài)唯一標(biāo)識(shí)questionssubjectId、type、content、options、answerIndex、analysis題庫題目與答案分離paperssubjectId、title、questions 快照、durationSeconds、createdAt試卷存的是組卷時(shí)刻的題目快照answersopenid、paperId、questionId、type、value、spendSeconds、submitAt逐題答題記錄用于錯(cuò)題回看和行為分析scoresopenid、paperId、score、totalScore、submitAt成績單一次考試一條記錄這里最關(guān)鍵的設(shè)計(jì)決策是「試卷題目用快照不用關(guān)聯(lián)查詢」。組卷時(shí)把選中題目完整拷貝進(jìn) papers 集合的 questions 字段而不是存題目 ID 數(shù)組、每次考試時(shí)再去題庫里聯(lián)表查。這樣做的直接好處是如果考試進(jìn)行到一半管理員修改了題庫里的某道題已開始考試的學(xué)生拿到的題目不會(huì)變成績也不會(huì)被題庫改動(dòng)污染。代價(jià)是同一道題在數(shù)據(jù)庫里可能有多份拷貝但對(duì)于考試系統(tǒng)這個(gè)體量這點(diǎn)存儲(chǔ)成本完全可接受。2.3 考試狀態(tài)機(jī)從「未開始」到「已交卷」的六個(gè)狀態(tài)考試流程不能只靠前端頁面控制服務(wù)端必須維護(hù)一份狀態(tài)機(jī)否則學(xué)生可以繞過頁面直接調(diào)接口交卷或者重復(fù)交卷刷成績。我在設(shè)計(jì)時(shí)會(huì)把試卷狀態(tài)拆成以下六種前端的按鈕展示和后端的接口校驗(yàn)都圍繞這套狀態(tài)來做。狀態(tài)值含義前端表現(xiàn)draft草稿組卷未完成不可見published已發(fā)布等待開考顯示「開始考試」按鈕ongoing進(jìn)行中有考生正在作答顯示倒計(jì)時(shí)與答題卡submitted已交卷等待批閱等待成績graded已出分顯示成績與錯(cuò)題回顧closed已關(guān)閉只讀狀態(tài)可查看歷史成績狀態(tài)機(jī)的核心價(jià)值在于「交卷接口的冪等性」。當(dāng)同一個(gè)學(xué)生重復(fù)提交試卷時(shí)后端只需要判斷 paperId 對(duì)應(yīng)的狀態(tài)是否已經(jīng)是 submitted 或 graded是就直接返回第一次的成績而不是重新判分、重新寫一條成績記錄。這個(gè)設(shè)計(jì)在弱網(wǎng)環(huán)境下非常重要因?yàn)榭蛻舳丝赡馨l(fā)起了請(qǐng)求、服務(wù)端已經(jīng)處理成功但響應(yīng)包沒回到客戶端學(xué)生以為沒交上又點(diǎn)了一次交卷。沒有狀態(tài)機(jī)做兜底就會(huì)出現(xiàn)「一次考試兩條成績」的翻車現(xiàn)場。3. 小程序端核心實(shí)現(xiàn)倒計(jì)時(shí)、答題卡、交卷的最小可跑代碼3.1 答題頁的數(shù)據(jù)結(jié)構(gòu)與題型歸一化考試系統(tǒng)最常見的題型是單選、多選、判斷、填空。如果為每一種題型單獨(dú)寫一套頁面邏輯代碼會(huì)非常臃腫。我一般會(huì)做一層「題型歸一化」把四種題型統(tǒng)一成一個(gè)答題數(shù)據(jù)結(jié)構(gòu)頁面只負(fù)責(zé)渲染提交時(shí)一律按這個(gè)結(jié)構(gòu)走。// questionTypes.js 題型常量與答題結(jié)構(gòu)歸一化 const QUESTION_TYPES { RADIO: radio, // 單選value 存選中項(xiàng)下標(biāo)如 2 CHECKBOX: checkbox, // 多選value 存選中項(xiàng)下標(biāo)數(shù)組如 [0, 2] JUDGE: judge, // 判斷value 存 0 或 1 FILL: fill // 填空value 存用戶輸入的字符串 } // 每道題的答題結(jié)果統(tǒng)一為以下對(duì)象 // 記錄 spendSeconds 可以用于后續(xù)的答題行為分析也可以在成績頁展示用時(shí) const answerItem { questionId: q_1024, type: QUESTION_TYPES.RADIO, value: 2, spendSeconds: 12 }這里要注意一個(gè)高頻翻車點(diǎn)多選題的 value 必須是數(shù)組且數(shù)組里存的是選項(xiàng)下標(biāo)而不是選項(xiàng)文本。因?yàn)榍岸苏故緯r(shí)可能會(huì)做題目亂序一旦亂序選項(xiàng)下標(biāo)對(duì)應(yīng)的文本就變了如果你存的是文本后續(xù)判分和題目快照對(duì)照時(shí)非常容易錯(cuò)位。判分時(shí)用「題目快照里的 answerIndex 數(shù)組」和「用戶提交的 value 數(shù)組」做集合比較兩個(gè)數(shù)組排序后相等才算對(duì)。填空則要注意去除首尾空格再比對(duì)避免學(xué)生多打一個(gè)空格被判錯(cuò)。3.2 倒計(jì)時(shí)與切后臺(tái)為什么 setInterval 會(huì)「自己停下」倒計(jì)時(shí)是考試小程序里遇到坑最多的模塊。很多初學(xué)者的第一版是用 setInterval 每秒遞減一個(gè)剩余秒數(shù)變量真機(jī)一測就翻車把小程序切到后臺(tái)回個(gè)微信消息再切回來倒計(jì)時(shí)還在走但已經(jīng)比真實(shí)時(shí)間慢了十幾秒。原因是小程序在后臺(tái)運(yùn)行時(shí)JS 定時(shí)器會(huì)被系統(tǒng)掛起等回到前臺(tái)才繼續(xù)執(zhí)行。解法很簡單不要累減變量而是用「絕對(duì)截止時(shí)間戳」做差值。// countdown.js 基于時(shí)間戳的倒計(jì)時(shí)封裝 const DEFAULT_DURATION 1800 // 考試時(shí)長單位秒30分鐘 const GRACE_SECONDS 5 // 寬限秒數(shù)防止用戶在最后一刻誤觸交卷 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刷新一次避免每秒一次的視覺卡頓 }這個(gè)封裝的要點(diǎn)是deadlineTs 不是「剩余多少秒」而是「開考時(shí)間 考試時(shí)長」得到的絕對(duì)時(shí)間戳。開考時(shí)間由服務(wù)端下發(fā)的serverTime計(jì)算不能用本地時(shí)間因?yàn)榭忌謾C(jī)的系統(tǒng)時(shí)間可能不準(zhǔn)。切后臺(tái)再回來時(shí)只需要在頁面的 onShow 生命周期里重新執(zhí)行一次Date.now()與 deadlineTs 的差值計(jì)算倒計(jì)時(shí)自然就校準(zhǔn)了。GRACE_SECONDS 的作用是倒計(jì)時(shí)歸零時(shí)先不強(qiáng)殺進(jìn)入一個(gè) 5 秒的寬限期這 5 秒內(nèi)學(xué)生如果正在點(diǎn)交卷按鈕仍然視為有效提交超過寬限期則強(qiáng)制提交當(dāng)前已答內(nèi)容。3.3 交卷的本地緩存與服務(wù)端判分邊界交卷是整個(gè)系統(tǒng)里最不能出錯(cuò)的環(huán)節(jié)因?yàn)榫W(wǎng)絡(luò)不可靠是常態(tài)但學(xué)生的答題結(jié)果必須可靠。我推薦的做法是「先寫本地緩存再請(qǐng)求服務(wù)端請(qǐng)求成功才清緩存失敗則保留待重試」。這樣即使學(xué)生在考試結(jié)束那一刻斷網(wǎng)成績也不會(huì)靜默丟失。// submitExam.js 交卷核心流程 async function submitExam(paperId, answers) { // 第1步先把答卷寫入本地緩存作為斷網(wǎng)兜底 wx.setStorageSync(pending_${paperId}, { answers, submitAt: Date.now() }) // 第2步調(diào)用云函數(shù)或自建后端接口 try { const res await wx.cloud.callFunction({ name: submitExam, data: { paperId, answers } }) const result res.result if (result.code 0) { // 服務(wù)端確認(rèn)接收后才清理本地緩存 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) { // 網(wǎng)絡(luò)異常時(shí)保留緩存回到頁面提示用戶重試 wx.showToast({ title: 提交失敗已暫存本地待重試, icon: none }) } }交卷后判分放在哪一端取決于你更看重「響應(yīng)速度」還是「結(jié)果可信」。純前端判分的好處是秒出成績演示效果好但如果學(xué)生用抓包工具改了答題數(shù)據(jù)前端判分的結(jié)果就不具備公信力。我在實(shí)際項(xiàng)目中采用的折中方案是前端先本地判分用于秒開成績頁同時(shí)把答案原樣提交給服務(wù)端服務(wù)端異步重新判分并覆蓋成績前端頁面展示的成績以服務(wù)端最終結(jié)果為準(zhǔn)。這樣兼顧了體驗(yàn)和可信度。云函數(shù)的超時(shí)時(shí)間默認(rèn)只有 3 秒如果試卷題量大判分邏輯放在云函數(shù)里很容易超時(shí)這也是為什么把判分拆到客戶端會(huì)更穩(wěn)的原因之一。4. 后端鑒權(quán)與題庫接入從登錄到組卷的完整鏈路4.1 登錄鑒權(quán)wx.login 換 openid 后為什么要再簽一層 token微信小程序的登錄體系已經(jīng)相當(dāng)成熟但很多初學(xué)者容易犯一個(gè)錯(cuò)誤把前端拿到的 openid 當(dāng)成唯一憑證到處用。openid 是用戶的弱隱私標(biāo)識(shí)它出現(xiàn)在前端代碼和請(qǐng)求參數(shù)里一旦被別人截獲就可以偽造身份提交答卷。正確做法是用 openid 換一個(gè)后端簽發(fā)的臨時(shí) token后續(xù)所有接口都校驗(yàn) token。// 云函數(shù) login/index.js登錄并簽發(fā) token const cloud require(wx-server-sdk) cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV }) const db cloud.database() exports.main async (event) { // 云函數(shù)上下文里直接拿 openid不需要前端傳 const { OPENID } cloud.getWXContext() const users db.collection(users) // 用戶不存在時(shí)自動(dòng)注冊(cè) const existed await users.where({ openid: OPENID }).get() if (existed.data.length 0) { await users.add({ data: { openid: OPENID, nickname: 考生, createdAt: Date.now() } }) } // 簽發(fā)臨時(shí) token2小時(shí)過期 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 } }這個(gè)云函數(shù)的邏輯說明小程序端先通過wx.login()拿到 code但云開發(fā)場景下前端不需要傳 code云函數(shù)調(diào)用時(shí)微信會(huì)自動(dòng)注入 openid。sessions 集合用來存有效 token前端每次請(qǐng)求把 token 放在 header 或 data 里后端校驗(yàn)時(shí)去 sessions 集合查這個(gè) token 是否存在且未過期。expiresIn 的單位是秒7200 表示兩小時(shí)實(shí)際項(xiàng)目中可以根據(jù)考試時(shí)長調(diào)整一般設(shè)為考試時(shí)長的 1.5 倍即可。如果自建后端流程是前端用 code 調(diào)微信接口換 openid后端再簽發(fā) token邏輯等價(jià)。4.2 題庫導(dǎo)入Excel 轉(zhuǎn) JSON 時(shí)最容易破壞的三個(gè)字段題庫數(shù)據(jù)是整個(gè)系統(tǒng)的心臟。很多人在搭建題庫時(shí)選擇了人工一條條往數(shù)據(jù)庫里錄入效率極低且容易錯(cuò)。常見做法是用 Excel 維護(hù)題庫再通過腳本批量轉(zhuǎn)成 JSON 導(dǎo)入。這個(gè)轉(zhuǎn)換過程有三個(gè)字段非常容易出錯(cuò)。{ subject: 計(jì)算機(jī)網(wǎng)絡(luò), questions: [ { id: q_1001, type: radio, content: OSI 參考模型共有幾層, options: [4, 5, 6, 7], answerIndex: 3, analysis: OSI 分為物理、數(shù)據(jù)鏈路、網(wǎng)絡(luò)、傳輸、會(huì)話、表示、應(yīng)用七層。 }, { id: q_1002, type: checkbox, content: 以下屬于傳輸層協(xié)議的是, options: [TCP, UDP, IP, HTTP], answerIndex: [0, 1] } ] }第一個(gè)易錯(cuò)字段是 options 的排列順序。Excel 導(dǎo)入時(shí)如果選項(xiàng)列被排序工具重排過前端展示的順序和后端 answerIndex 的對(duì)應(yīng)關(guān)系就會(huì)被打破。第二個(gè)易錯(cuò)字段是答案索引單選用數(shù)字下標(biāo)多選必須用數(shù)組判斷題的 answerIndex 建議統(tǒng)一用 1 表示正確、0 表示錯(cuò)誤不要混用 true/false 和「對(duì)/錯(cuò)」文本。第三個(gè)易錯(cuò)點(diǎn)是題干中的特殊字符比如答案里的英文雙引號(hào)、換行符如果不做轉(zhuǎn)義JSON.parse 會(huì)直接報(bào)錯(cuò)導(dǎo)入腳本必須對(duì)這類字符做預(yù)處理。4.3 組卷策略固定抽題、隨機(jī)抽題、試卷快照組卷是考試系統(tǒng)區(qū)別于普通答題工具的關(guān)鍵功能。一套題庫要能生成多套試卷每套試卷又能被多次考試使用這需要把「組卷」和「考試」做成兩個(gè)獨(dú)立環(huán)節(jié)。// buildPaper.js 組卷函數(shù)固定概率抽題并生成試卷快照 function buildPaper(subjectId, countPerType, shuffle) { // countPerType 示例{ radio: 10, checkbox: 5, judge: 5, fill: 3 } const snapshotQuestions pickQuestions(subjectId, countPerType, shuffle) // 把題目快照整體寫入 paper 記錄 // 后續(xù)修改題庫不影響已生成的試卷 const paper { subjectId, title: subjectId 標(biāo)準(zhǔn)模擬卷, questions: snapshotQuestions, durationSeconds: 1800, createdAt: Date.now() } return db.collection(papers).add({ data: paper }) } // pickQuestions 內(nèi)部邏輯按題型分組后從題庫里隨機(jī)取指定數(shù)量 // shuffle 為 true 時(shí)同時(shí)對(duì)題目順序和每道題的選項(xiàng)順序做亂序 function pickQuestions(subjectId, countPerType, shuffle) { // 從題庫按 subjectId type 過濾每組隨機(jī)取 count 道 // 若題庫題量不足需要提前做完整性校驗(yàn)避免組出一張不夠題的試卷 }組卷的核心邏輯理解countPerType是各題型的題目數(shù)量比如單選題 10 道、多選題 5 道、判斷題 5 道、填空題 3 道。shuffle開關(guān)控制是否亂序亂序時(shí)必須把題目的 answerIndex 一起重新映射這就是前面章節(jié)反復(fù)強(qiáng)調(diào)的坑——洗牌只洗了 options 數(shù)組沒有同步更新答案下標(biāo)判斷題和多選題就會(huì)大面積誤判。試卷快照的意義前面已經(jīng)說過是為了保證成績可復(fù)現(xiàn)。另外還有一個(gè)實(shí)用習(xí)慣組卷時(shí)生成一張考試說明頁把題型分布、每題分值、考試時(shí)長一起展示給學(xué)生這套數(shù)據(jù)也一起寫進(jìn) paper 記錄避免前端寫死。5. 避坑手冊(cè)考試小程序最容易翻車的六個(gè)現(xiàn)場5.1 倒計(jì)時(shí)切后臺(tái)回來后還在走但交卷時(shí)間已超現(xiàn)象考生把小程序切到后臺(tái)回微信消息再切回來頁面倒計(jì)時(shí)顯示還剩 10 分鐘但服務(wù)端校驗(yàn)時(shí)發(fā)現(xiàn)考試已經(jīng)超時(shí)拒絕接收答卷。 原因setInterval 在小程序后臺(tái)被系統(tǒng)掛起回到前臺(tái)才恢復(fù)而且代碼里用的是遞減變量而不是絕對(duì)時(shí)間戳差值。 解決倒計(jì)時(shí)一律基于deadlineTs - Date.now()計(jì)算deadlineTs 存在全局變量或 storage 中頁面的 onShow 生命周期里重新計(jì)算一次剩余時(shí)間并刷新 UI。服務(wù)端同步校驗(yàn)收卷時(shí)間以服務(wù)端時(shí)間為準(zhǔn)絕不信任客戶端上報(bào)的本地時(shí)間。5.2 真機(jī)預(yù)覽請(qǐng)求失敗開發(fā)者工具卻一切正常現(xiàn)象在微信開發(fā)者工具里點(diǎn)擊交卷、加載題庫都正常一換成真機(jī)預(yù)覽接口請(qǐng)求全部報(bào)request:fail url not in domain list。 原因開發(fā)者工具默認(rèn)關(guān)閉了合法域名校驗(yàn)而真機(jī)上微信強(qiáng)制校驗(yàn) request 請(qǐng)求的域名必須在小程序后臺(tái)配置過云開發(fā)調(diào)用走 wx.cloud 系列接口不受此限制自建接口則必須配置合法域名。 解決云開發(fā)場景直接用wx.cloud.callFunction不要手動(dòng)拼 URL。自建接口場景在小程序管理后臺(tái)配置 request 合法域名域名必須備案并支持 HTTPS。開發(fā)者工具里關(guān)閉校驗(yàn)只能用于本地調(diào)試不能作為真機(jī)方案。5.3 主包超過 2MB代碼上傳一直失敗現(xiàn)象代碼寫完后上傳提示主包體積超過 2MB無法提交審核。 原因最常見的體積殺手是題庫數(shù)據(jù)被直接寫在代碼里一個(gè)包含幾百道題帶圖片的 JSON 文件就能占掉大幾百 KB如果還塞了教材配套音頻、圖片素材超限是必然的。 解決題庫數(shù)據(jù)移入云數(shù)據(jù)庫或后端小程序端按需拉取題目不要整個(gè)文件打進(jìn)包里。大體積的靜態(tài)資源用小程序的運(yùn)行時(shí)分包加載或者放到云存儲(chǔ)后按需下載。注意主包體積限制是 2MB整個(gè)小程序總包上限是 20MB分包不是萬能藥資源能走后端就走后端。5.4 交卷時(shí)網(wǎng)絡(luò)閃斷成績靜默丟失現(xiàn)象學(xué)生在考試結(jié)束前最后 10 秒點(diǎn)了交卷頁面一直轉(zhuǎn)圈最后提示網(wǎng)絡(luò)錯(cuò)誤學(xué)生刷新后重新進(jìn)入發(fā)現(xiàn)沒有成績于是又做了一遍數(shù)據(jù)庫里出現(xiàn)兩條答卷記錄。 原因前端直接請(qǐng)求后端斷網(wǎng)時(shí)請(qǐng)求失敗且沒有重試機(jī)制后端接口沒有做冪等同一學(xué)生同一試卷提交多次會(huì)生成多條成績。 解決前端在發(fā)起請(qǐng)求前先把答卷寫入本地緩存請(qǐng)求成功后才清理緩存失敗時(shí)保留緩存并提示用戶重試后端對(duì)openid paperId做唯一約束或重復(fù)提交檢測已經(jīng)交過卷的請(qǐng)求直接返回第一次成績。兩個(gè)措施缺一不可只做前端的緩存換一臺(tái)設(shè)備成績依然會(huì)丟。5.5 題目亂序后答案對(duì)不上多選題翻車最嚴(yán)重現(xiàn)象開啟題目亂序和選項(xiàng)亂序后學(xué)生反饋「我明明選了對(duì)的卻給我判錯(cuò)」其中多選題錯(cuò)得最多。 原因亂序函數(shù)只打亂了 options 數(shù)組的順序沒有同步更新題目的 answerIndex。單選題碰巧首選項(xiàng)相同的還能對(duì)上多選題本身答案就是多個(gè)下標(biāo)錯(cuò)位后幾乎不可能蒙對(duì)。 解決洗牌時(shí)用一個(gè)映射數(shù)組把舊下標(biāo)和新下標(biāo)的關(guān)系保留下來答題和判分時(shí)統(tǒng)一使用「新下標(biāo)」體系。前端 value 永遠(yuǎn)存選項(xiàng)下標(biāo)不存選項(xiàng)文本判分前用題目快照中的 answerIndex 和用戶提交的 value 做排序后比較。5.6 云函數(shù)默認(rèn)超時(shí)太短判分跑到一半被掐斷現(xiàn)象本地調(diào)試云函數(shù)時(shí)一切正常真機(jī)上交卷后頻繁提示「云函數(shù)調(diào)用超時(shí)」考試成績偶爾能存上、偶爾存不上。 原因云函數(shù)的默認(rèn)超時(shí)時(shí)間只有 3 秒。一張卷子 30 道題判分邏輯加寫庫操作在弱網(wǎng)環(huán)境下很容易超過 3 秒而且每次調(diào)用都會(huì)冷啟動(dòng)首次調(diào)用耗時(shí)更高。 解決把耗時(shí)的判分邏輯移到客戶端本地執(zhí)行云函數(shù)只做簡單的數(shù)據(jù)校驗(yàn)和成績落庫或者在小程序云開發(fā)控制臺(tái)把該云函數(shù)的超時(shí)時(shí)間調(diào)大到 10~20 秒如果題目量特別大就改成異步任務(wù)交卷接口先返回「已受理」判分完成后通過訂閱消息或手動(dòng)刷新獲取成績。6. 讓系統(tǒng)經(jīng)得起演示并發(fā)交卷與弱網(wǎng)聯(lián)調(diào)的驗(yàn)證習(xí)慣答辯現(xiàn)場最怕的不是功能沒做完而是演示到交卷那一步突然翻車。我的習(xí)慣是每次改動(dòng)代碼后都按一套標(biāo)準(zhǔn)的測試矩陣在真機(jī)上完整走一遍而不是只在開發(fā)者工具里點(diǎn)兩下就收工。測試場景操作方式通過標(biāo)準(zhǔn)正常交卷完整答完一張卷點(diǎn)擊交卷成績頁秒開數(shù)據(jù)庫成績記錄唯一弱網(wǎng)交卷開發(fā)者工具開啟弱網(wǎng)模擬再點(diǎn)交卷前端提示暫存本地網(wǎng)絡(luò)恢復(fù)后重試成功切后臺(tái)再交卷答到一半切后臺(tái)等 30 秒再回來立即交卷倒計(jì)時(shí)校準(zhǔn)后扣除后臺(tái)時(shí)長交卷正常重復(fù)提交交卷成功后返回頁面再次點(diǎn)交卷后端返回第一次成績不產(chǎn)生新記錄亂序判分開啟亂序后用已知答案的測試賬號(hào)作答得分與人工判卷完全一致驗(yàn)證弱網(wǎng)時(shí)微信開發(fā)者工具的「模擬弱網(wǎng)」只是低配方案真機(jī) 4G 網(wǎng)絡(luò)信號(hào)弱的環(huán)境更容易暴露問題。我在封裝交卷模塊時(shí)習(xí)慣在日志里打印每一步的耗時(shí)如果從點(diǎn)擊交卷到看到成績頁超過 5 秒就說明判分或?qū)憥戽溌酚袃?yōu)化空間。并發(fā)聯(lián)動(dòng)在考試小程序里不好用 curl 直接壓測更實(shí)際的做法是準(zhǔn)備三五個(gè)測試賬號(hào)在同一臺(tái)路由器下同時(shí)交卷看成績是否全部落庫。最后說一個(gè)我自己的教訓(xùn)最初我把判分邏輯完整地寫在云函數(shù)里真機(jī)演示時(shí)連續(xù)三次超時(shí)一度懷疑是網(wǎng)絡(luò)問題后來才發(fā)現(xiàn)是默認(rèn)超時(shí)只有 3 秒冷啟動(dòng)再加幾十道題的判分循環(huán)根本跑不完。把判分挪回客戶端本地執(zhí)行、云函數(shù)只做校驗(yàn)和存儲(chǔ)之后交卷體驗(yàn)才真正穩(wěn)定下來?？荚囅到y(tǒng)這類項(xiàng)目前端交互做得再花哨都不如「倒計(jì)時(shí)不漂移、交卷不丟數(shù)據(jù)、重復(fù)提交不出錯(cuò)」這三個(gè)底線來得實(shí)在。希望你做完這套系統(tǒng)后能在演示現(xiàn)場從容地說一句「你們隨便考我先交卷」這比任何花哨的功能都更能打動(dòng)評(píng)委希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取