微信答题考试小程序源码实战：从跑通到避坑的完整指南

简介：这份资源是面向微信小程序开发者与计算机相关专业学生的答题考试系统设计源码，适合作为课程设计、毕业设计或小程序全栈练习的参考项目，帮助读者理解从界面交互到业务逻辑再到数据存储的完整实现路径。压缩包共收录2029个文件，整体约29.63MB，其中JavaScript文件1749个，承担核心业务逻辑与页面交互；JSON文件190个，多用于页面配置与项目参数；另有Markdown文档43个、HTML与CSS等少量文件，辅助说明项目结构与样式组织。目前已有1050人学习下载，说明该方案在同类选题中具备一定参考热度。源码覆盖用户界面设计、答题逻辑、考试流程与数据存储等多个模块，目录层级清晰，便于按功能检索与二次开发，读者可据此快速搭建答题考试类小程序原型，并在此基础上调整题库管理、成绩统计等环节，减少从零起步的试错成本。

1. 从一份答题考试小程序源码说起：它到底能跑通什么

如果你手头正好有一份基于微信小程序的答题考试系统源码，第一件该做的事不是急着改 UI，而是先判断它能不能跑通「登录 → 抽题 → 作答 → 判分 → 记录」这条主链路。我见过太多人拿到源码后卡在appid没换、云函数没部署、题库表结构对不上，折腾半天连首页都进不去。这份源码的核心价值在于：它把考试类小程序最常被问到的几个模块——微信登录获取手机号、单选/多选/判断题渲染、倒计时交卷、成绩落库——都串成了一条可复现的流程。适合两类人：一是课程设计需要交一个完整可演示系统的学生，二是想拿现成骨架改造成企业内训、认证刷题工具的开发者。技术栈是 JavaScript 加 TypeScript 混合，前端原生小程序，后端常见做法是 Node.js 或云开发。下面我按「先跑起来、再改得动、最后避坑」的顺序拆一遍。

2. 环境搭建与首次运行：把源码从压缩包跑到真机预览

2.1 目录结构与技术栈确认

拿到源码先别打开开发者工具，用编辑器扫一眼根目录。典型的答题考试小程序工程会包含这几个部分：miniprogram/放页面和组件，cloudfunctions/或server/放后端逻辑，project.config.json记录项目配置，package.json管依赖。如果看到.ts文件和tsconfig.json，说明用了 TypeScript，编译环节不能跳过。

先确认后端路线：源码里如果有cloudfunctions且app.js里调用了wx.cloud.init，那就是云开发路线；如果看到request封装和baseUrl配置，那就是自建后端路线。两条路线的启动步骤差别很大，选错了会一直报网络错误。

2.2 导入项目与依赖安装

打开微信开发者工具，选择「导入项目」，目录指向源码根目录。工具会自动读取project.config.json，但 appid 通常还是作者的测试号，必须换成你自己的。没有 appid 可以用测试号，但测试号不支持云开发和获取手机号，这点后面避坑章节会细说。

# 进入源码根目录，安装依赖 cd answer-exam-miniprogram npm install # 如果是 TypeScript 工程，先编译一次 npm run tsc # 或者 npx tsc

npm install拉的是package.json里声明的依赖，常见的有wx-server-sdk（云开发）、express（自建后端）、moment之类的时间处理库。TypeScript 工程必须跑一次编译，否则开发者工具加载的是旧的.js产物，你改了.ts却不生效，会以为是玄学。编译命令看package.json的scripts字段，不同作者命名不一样，有的是build，有的是tsc。

2.3 后端配置与数据库初始化

云开发路线：在开发者工具里点「云开发」，开通环境，把环境 ID 填到app.js的wx.cloud.init({ env: '你的环境ID' })。然后在云开发控制台新建集合，答题系统一般需要questions（题库）、records（答题记录）、users（用户）三个集合。

// app.js 中云开发初始化片段 App({ onLaunch() { if (!wx.cloud) { console.error('请使用 2.2.3 或以上的基础库'); return; } wx.cloud.init({ env: 'your-env-id', // 替换成自己的云环境 ID traceUser: true }); } });

env填错会报-501000环境不存在；traceUser设为 true 后可以在云开发控制台看到用户访问记录，调试阶段建议开着。自建后端路线则要改baseUrl，本地调试时填http://localhost:3000，但真机预览时 localhost 不通，得换成局域网 IP 或已备案域名，这是新手最容易翻车的地方。

2.4 真机预览与首屏验证

点「预览」生成二维码，用微信扫码。首屏应该出现登录按钮或直接进入首页。如果卡在白屏，先看开发者工具的 Console 有没有报错，再看 Network 里请求是否 404 或超时。能进首页后，走一遍完整答题流程：选一套题、作答、交卷、看成绩。这条链路通了，说明源码的基本骨架是完整的，后面改起来才有底。

3. 核心模块拆解：登录、抽题、判分三条链路怎么改

3.1 微信登录与获取手机号

答题考试系统通常要求实名或绑定手机号，微信小程序获取手机号的能力是核心。注意，获取手机号必须用button组件的open-type="getPhoneNumber"，不能直接调 API。

// 页面中获取手机号的按钮回调 Page({ getPhoneNumber(e) { if (e.detail.errMsg !== 'getPhoneNumber:ok') { // 用户拒绝授权 wx.showToast({ title: '需要授权才能考试', icon: 'none' }); return; } // code 传给后端换取手机号 wx.request({ url: `${baseUrl}/api/getPhone`, method: 'POST', data: { code: e.detail.code }, success(res) { // 后端返回手机号，存入全局或本地 wx.setStorageSync('phone', res.data.phone); } }); } });

e.detail.code是动态令牌，有效期很短，必须立刻传给后端，由后端用access_token去换真实手机号。前端拿不到明文手机号，这是微信的隐私设计。常见坑是：测试号不支持获取手机号，必须用已认证的企业主体小程序；另外code只能用一次，重复使用会报错。登录态一般用wx.login拿code换openid，再配合手机号做用户唯一标识。

3.2 题库数据结构与抽题逻辑

题库集合的字段设计直接决定后面判分和统计能不能做。我一般会要求至少这几个字段：_id、type（单选/多选/判断）、stem（题干）、options（选项数组）、answer（正确答案）、score（分值）、category（分类）。

// 云函数中按分类随机抽题 const cloud = require('wx-server-sdk'); cloud.init(); const db = cloud.database(); exports.main = async (event) => { const { category, count } = event; const res = await db.collection('questions') .aggregate() .match({ category }) // 按分类过滤 .sample({ size: count }) // 随机抽取 count 道 .end(); return res.list; };

match是过滤条件，sample是随机抽样，size控制抽题数量。如果题库量小，sample性能没问题；题库上万时建议加索引或改用预生成试卷的方式。判断题的options可以固定为['正确', '错误']，判分时统一比较answer字段。多选题的answer建议存数组，判分时先排序再比较，避免顺序不同导致误判。

3.3 判分逻辑与成绩落库

判分可以在前端做，也可以在后端做。前端判分响应快，但容易被篡改；后端判分安全，但每次交卷都要请求。课程设计类项目前端判分够用，正式考试建议后端判。

// 前端判分示例 function calcScore(questions, userAnswers) { let total = 0; questions.forEach((q, i) => { const ua = userAnswers[i]; if (q.type === 'multiple') { // 多选：排序后比较 const correct = [...q.answer].sort().join(','); const user = [...(ua || [])].sort().join(','); if (correct === user) total += q.score; } else { if (q.answer === ua) total += q.score; } }); return total; }

userAnswers建议用对象存，key 是题目_id，value 是用户选择，这样不依赖题目顺序。成绩落库时把openid、score、duration、submitTime一起写入records集合，方便后面做排行榜和错题本。注意并发交卷的情况，后端落库前最好查一次是否已有记录，避免重复提交。

4. 避坑与常见问题排查：那些让你怀疑人生的报错

4.1 获取手机号报「该小程序不支持」

现象：点获取手机号按钮，回调里errMsg返回不支持。原因：测试号或未认证的个人主体小程序没有这个权限。解决：换成已认证的企业主体小程序，或者在开发阶段先用wx.login的openid做临时用户标识，把手机号功能留到上线前再接。

4.2 云函数调用报「-501000 环境不存在」

现象：调用云函数时控制台报环境不存在。原因：wx.cloud.init里的env填的不是当前账号下的环境 ID，或者环境被删了。解决：去云开发控制台复制正确的环境 ID，注意区分测试环境和正式环境。如果用了多个环境，建议把环境 ID 抽到配置文件里，别硬编码在app.js。

4.3 真机预览请求 localhost 失败

现象：开发者工具里接口正常，真机上所有请求失败。原因：真机访问的是手机自己的 localhost，不是你的电脑。解决：本地调试时把baseUrl换成电脑的局域网 IP，比如http://192.168.1.100:3000，并确保手机和电脑在同一网络。上线前必须换成已备案的 HTTPS 域名，微信小程序正式环境不允许 HTTP。

4.4 多选题判分总是错

现象：用户选对了但判分显示错误。原因：数组顺序不一致，['A','B']和['B','A']直接比较不相等。解决：判分前对两个数组都排序再转字符串比较，或者用集合的方式判断包含关系。这个坑血泪经验，我见过不止一个项目栽在这。

4.5 TypeScript 改了不生效

现象：修改.ts文件后开发者工具没变化。原因：没有重新编译，工具加载的还是旧的.js。解决：每次改完.ts跑一次npm run tsc，或者在开发者工具里开启「编译 TypeScript」选项。更省事的做法是配tsc --watch，保存即编译。

5. 进阶技巧：用错题本和排行榜把答题系统做出留存

5.1 错题本的实现思路

错题本是答题系统里最能提升用户粘性的功能。实现方式很简单：每次交卷后，把用户答错的题目_id追加到users集合的wrongList字段里，去重后存储。查询时用db.command.in批量拉取题目详情。

// 交卷后更新错题本 const _ = db.command; await db.collection('users').where({ openid }).update({ data: { wrongList: _.addToSet(_.each(wrongIds)) // 自动去重追加 } });

addToSet配合each可以批量追加并去重，比手动查重再更新省事得多。错题本页面按分类分组展示，用户可以选择「只练错题」，这时候抽题逻辑从questions集合换成按wrongList里的 ID 拉取。

5.2 排行榜的两种做法

排行榜分实时榜和历史榜。实时榜用云开发的聚合查询按score倒序取前 50，注意要加submitTime范围过滤，否则会把历史数据混进来。历史榜建议每天凌晨跑一个定时云函数，把当天成绩汇总到rankings集合，查询时直接读汇总表，避免每次全表扫描。

// 实时排行榜聚合查询 const res = await db.collection('records') .aggregate() .match({ submitTime: _.gte(todayStart) }) .sort({ score: -1, duration: 1 }) // 分数相同用时短者靠前 .limit(50) .end();

duration升序作为第二排序条件，能解决同分排名的问题。如果要做「我的排名」，再查一次当前用户的分数在集合中的位置，用count统计比它高的记录数加一即可。

5.3 一个我常做的验证习惯

每次改完判分逻辑或抽题逻辑，我不会只点一遍界面就完事。我会在云函数里写一个临时的测试入口，构造几组边界数据——全对、全错、多选漏选、超时未交——跑一遍看分数和记录是否符合预期。这个习惯帮我拦下过好几次「看起来正常但边界全错」的翻车。从那以后我每次动判分相关代码，都强制走一遍边界用例，希望帮到你。

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