简介这是一套面向微信小程序初学者与全栈练手开发者的在线答题项目源码采用微信原生小程序搭配云开发TCB架构适合想快速掌握小程序前端交互与云端一体化开发、并需要一个完整可运行案例的人群。压缩包共75个文件约6.06MB以35个png与4个jpg截图、10个wxss样式、10个json配置、8个js逻辑、6个wxml模板为主另含gitignore与README说明覆盖页面结构、样式与云函数调用等关键部分。已有221人学习下载。项目围绕答题场景实现了题目展示、答案提交、成绩计算与排行榜等模块目录中可见index、details、rank、history、test、result等页面以及后台题目管理与题库相关截图便于读者理解数据存储、云函数鉴权与成绩统计的落地方式也可作为二次开发与课程设计的参考骨架。1. 云开发答题小程序为什么“零后端”反而让架构决策更致命很多人第一次听到“微信原生小程序 云开发”做答题应用第一反应是这不就是不用买服务器、不用写接口的省事方案吗我一开始也这么想直到某次帮一个团队排查线上问题——他们的答题小程序在活动开始三分钟后集体卡死用户点选项没反应排行榜数据错乱。翻车原因不是代码写得多烂而是他们把“云开发等于零架构”当成了默认前提所有逻辑都堆在页面里数据库权限设成了“所有人可写”。云开发确实把运维成本压到了接近零但它没有帮你做任何架构决策。答题类小程序的核心链路——题库加载、计时、判分、排行榜、防重复提交——每一个环节在云开发模式下都有完全不同的实现约束。这篇文章面向的是打算用原生小程序加云开发落地答题应用的开发者不管你是要做一个内部培训考核工具还是一个轻量级的知识竞赛我会把选型理由、目录结构、云函数设计、数据库权限、性能边界和踩坑记录全部拆开讲清楚让你能直接照着复现一套可用的架构。2. 答题小程序的技术选型原生小程序加云开发到底省掉了什么2.1 为什么不用 uni-app 或 Taro 转译方案常见做法是先纠结跨端框架。如果你的答题小程序只跑在微信里原生小程序加云开发的组合在调试链路上最短。转译框架多一层编译云开发的原生 API 调用需要额外适配出了问题排查路径变长。我一般会建议答题场景交互不复杂页面数量通常在 5 到 8 个之间原生写法完全撑得住而且云开发的小程序端 SDK 在原生环境下调用最直接不需要额外封装。另一个实际考量是包体积。答题小程序如果带题库缓存和排行榜主包容易逼近 2MB 限制。原生小程序配合分包加载和云开发按需拉取控制起来更精细。转译框架生成的运行时代码会额外占用几十到上百 KB在临界状态下这就是压死骆驼的最后一根稻草。2.2 云开发替代了哪些传统后端组件传统答题系统后端至少需要一台应用服务器处理请求、一个数据库存题库和成绩、一个缓存层做排行榜、一个定时任务做数据清理。云开发把这四样分别映射到云函数、云数据库、云数据库的聚合查询和定时触发器。映射关系清楚了架构就不会乱。传统组件云开发对应答题场景用途应用服务器云函数判分、提交答案、生成排行榜数据库云数据库文档型题库、用户答题记录、成绩缓存云数据库聚合 索引实时排行榜查询定时任务定时触发器清理过期答题会话、归档成绩需要留意的是云数据库是文档型数据库不是关系型。题库如果设计成嵌套文档查询和更新会比关系型麻烦。我一般会把题目和选项拆成独立集合用 questionId 关联避免单文档过大导致读写性能下降。2.3 最小可运行的项目目录结构下面是我常用的目录骨架直接照着建就能跑通基础链路。project-root/ ├── miniprogram/ │ ├── app.js │ ├── app.json │ ├── pages/ │ │ ├── index/ # 答题首页 │ │ ├── quiz/ # 答题页 │ │ └── result/ # 成绩页 │ ├── utils/ │ │ └── request.js # 云函数调用封装 │ └── components/ │ └── question-card/ # 题目卡片组件 ├── cloudfunctions/ │ ├── submitAnswer/ # 提交答案并判分 │ ├── getRanking/ # 获取排行榜 │ └── initQuiz/ # 初始化答题会话 └── project.config.json这个结构的关键在于所有写操作走云函数小程序端只做展示和交互。很多翻车案例都是因为图省事在小程序端直接调db.collection().add()结果权限一开就收不住。2.4 云函数与小程序端的分工边界一个原则凡是涉及判分、写成绩、改排行榜的操作全部放云函数。小程序端只负责渲染题目、收集用户选择、调用云函数。这样做的好处是判分逻辑不暴露在客户端用户改不了答案也绕不过计时。// cloudfunctions/submitAnswer/index.js const cloud require(wx-server-sdk) cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV }) const db cloud.database() exports.main async (event) { const { OPENID } cloud.getWXContext() const { sessionId, questionId, selectedOption } event // 1. 校验会话是否有效且未过期 const session await db.collection(sessions) .where({ _id: sessionId, openid: OPENID, status: active }) .get() if (session.data.length 0) { return { code: 4001, msg: 会话无效或已结束 } } // 2. 拉取题目正确答案 const question await db.collection(questions) .doc(questionId) .get() const isCorrect question.data.answer selectedOption // 3. 写入答题记录 await db.collection(answers).add({ data: { openid: OPENID, sessionId, questionId, selectedOption, isCorrect, createdAt: db.serverDate() } }) return { code: 0, data: { isCorrect } } }这段代码里三个关键点用cloud.getWXContext()拿 OPENID 而不是从客户端传防止伪造先校验会话状态再判分防止过期会话继续提交用db.serverDate()写时间戳避免客户端时间不准。参数sessionId和questionId由小程序端传入但openid永远不信任客户端。3. 题库设计与云数据库权限文档型数据库的建模取舍3.1 题目集合的字段设计与索引策略题库集合的设计直接决定后续查询效率。我一般用这样的字段结构// 题目文档示例 { _id: auto-generated, category: 安全知识, // 分类用于筛选 type: single, // 题型single / multiple stem: 以下哪项属于..., // 题干 options: [ { key: A, text: 选项A内容 }, { key: B, text: 选项B内容 } ], answer: A, // 正确答案 difficulty: 2, // 难度等级 1-5 order: 10 // 排序权重 }索引方面category和difficulty建组合索引用于按分类和难度抽题。order建单字段索引用于排序。注意云数据库的索引需要在控制台手动创建代码里不会自动生成。很多新手不知道这一点数据量上来后查询慢得离谱还以为是云函数冷启动的问题。3.2 数据库权限的四种模式与答题场景选择云数据库权限有四种仅创建者可读写、所有用户可读仅创建者可写、所有用户可读、所有用户不可读写。答题场景下题库集合应该设为“所有用户可读仅管理端可写”——但云开发没有独立的管理端所以实际做法是设为“所有用户不可读写”然后通过云函数来读取。这样小程序端无法直接查题库必须走云函数防止答案泄露。用户答题记录集合设为“仅创建者可读写”这样每个用户只能看到自己的记录。排行榜集合设为“所有用户可读”但写入只能通过云函数。这个权限组合是我踩过坑之后固定下来的早期把题库设为所有用户可读结果有人直接在小程序端遍历题库把答案全拉走了。3.3 用云函数做安全读取的完整示例// cloudfunctions/getQuestions/index.js const cloud require(wx-server-sdk) cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV }) const db cloud.database() const _ db.command exports.main async (event) { const { category, count 10 } event // 使用聚合查询随机抽取指定数量的题目 const result await db.collection(questions) .aggregate() .match({ category: category }) .sample({ size: count }) .end() // 返回时剔除 answer 字段防止答案泄露到客户端 const safeQuestions result.list.map(item { const { answer, ...rest } item return rest }) return { code: 0, data: safeQuestions } }这里用aggregate().sample()做随机抽题比先查全部再随机效率高。关键操作是返回前剔除answer字段——这个动作必须在云函数里做不能指望客户端过滤。参数count控制抽题数量建议不超过 20因为单次云函数返回数据量有限制题目文本较长时容易超。3.4 答题会话的状态管理答题会话是容易被忽略的一环。用户开始答题时创建一个 session 文档记录开始时间、题目列表、当前进度。提交答案时更新 session 状态。会话过期时间建议设为 30 分钟通过定时触发器清理。// cloudfunctions/initQuiz/index.js const cloud require(wx-server-sdk) cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV }) const db cloud.database() exports.main async (event) { const { OPENID } cloud.getWXContext() const { category, questionIds } event // 检查是否有未完成的会话 const existing await db.collection(sessions) .where({ openid: OPENID, status: active }) .get() if (existing.data.length 0) { return { code: 0, data: { sessionId: existing.data[0]._id, resumed: true } } } const session await db.collection(sessions).add({ data: { openid: OPENID, category, questionIds, currentIndex: 0, status: active, startedAt: db.serverDate(), expireAt: new Date(Date.now() 30 * 60 * 1000) } }) return { code: 0, data: { sessionId: session._id, resumed: false } } }这段逻辑处理了断点续答如果用户中途退出再进来直接返回已有会话而不是新建。expireAt字段配合定时触发器做清理避免无效会话堆积。4. 判分、计时与排行榜云函数里的核心链路实现4.1 判分逻辑为什么必须放云函数判分放云函数的原因不只是防作弊。答题场景中多选题的判分规则、部分分规则、时间加成规则都可能变化。如果这些逻辑写在小程序端每次调整都要发版审核。放云函数里改完直接生效不需要走小程序审核流程。这个灵活性在运营活动中特别重要。4.2 服务端计时的实现与客户端时间校准计时是答题小程序最容易出问题的地方。客户端计时可以被用户修改系统时间绕过所以必须服务端计时。做法是在 session 里记录startedAt每次提交答案时计算已用时间。// 在 submitAnswer 云函数中增加计时校验 const session await db.collection(sessions).doc(sessionId).get() const startedAt session.data.startedAt.getTime() const now Date.now() const elapsed Math.floor((now - startedAt) / 1000) const timeLimit session.data.timeLimit || 600 // 默认10分钟 if (elapsed timeLimit) { await db.collection(sessions).doc(sessionId).update({ data: { status: expired } }) return { code: 4002, msg: 答题超时 } }客户端展示倒计时只是为了用户体验真正的超时判断在云函数里。两边时间可能有几秒偏差所以服务端判断时留 5 秒缓冲避免用户刚好在最后一秒提交被判超时。4.3 排行榜的实时聚合查询排行榜用云数据库聚合查询实现按正确题数和用时排序。// cloudfunctions/getRanking/index.js const cloud require(wx-server-sdk) cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV }) const db cloud.database() const $ db.command.aggregate exports.main async (event) { const { sessionId, limit 50 } event const result await db.collection(answers) .aggregate() .match({ sessionId: sessionId }) .group({ _id: $openid, correctCount: $.sum($.cond({ if: $isCorrect, then: 1, else: 0 })), totalTime: $.sum($elapsed) }) .sort({ correctCount: -1, totalTime: 1 }) .limit(limit) .end() return { code: 0, data: result.list } }聚合的group阶段按 openid 分组统计正确数和总用时。排序规则是先按正确数降序再按用时升序。limit控制返回条数建议不超过 100否则聚合查询可能超时。如果数据量大需要给sessionId和openid建组合索引。4.4 防重复提交与幂等处理用户快速点击提交按钮可能触发多次云函数调用。处理方式是在 answers 集合里对openid sessionId questionId建唯一索引重复插入会失败云函数捕获错误后返回已提交状态。try { await db.collection(answers).add({ data: answerData }) } catch (err) { if (err.errCode -502001) { // 唯一索引冲突 return { code: 0, msg: 已提交, data: { isCorrect: null } } } throw err }唯一索引需要在云开发控制台手动创建代码里无法声明。这个坑我踩过本地测试没问题上线后并发一高就出现重复记录排行榜数据翻倍。5. 避坑与排查答题小程序上线后最容易翻车的五个点5.1 云函数冷启动导致首题加载慢现象用户点开始答题后第一题加载要等 2 到 3 秒后续题目正常。原因是云函数冷启动首次调用需要初始化运行环境。解决办法是设置定时触发器每 5 分钟调用一次轻量级预热函数保持云函数活跃。另一个做法是在小程序启动时提前调用一个空操作的云函数把冷启动时间藏在用户阅读规则说明的阶段。5.2 数据库查询默认返回 20 条限制现象题库明明有 100 题抽题时只返回 20 题。原因是云数据库小程序端查询默认 limit 是 20云函数端默认是 100。解决方式是在查询时显式设置.limit()但注意云函数单次返回数据量上限是 1MB题目文本多时不要一次拉太多。我一般分页拉取每页 50 条。5.3 聚合查询在数据量超过五千条后明显变慢现象排行榜查询从 200ms 涨到 3 秒以上。原因是聚合查询没有走索引全表扫描。解决方式是在answers集合上建sessionId openid组合索引并且把聚合的match阶段放在最前面减少后续阶段处理的数据量。如果数据量持续增长考虑把排行榜结果缓存到独立集合定时更新而不是实时聚合。5.4 云函数超时设置不合理导致判分丢失现象用户提交答案后偶尔没有记录也没有报错。原因是云函数默认超时时间是 3 秒判分逻辑里如果有多次数据库操作可能超时被终止。解决方式是在云函数配置里把超时时间调到 10 到 20 秒同时优化逻辑减少不必要的查询。判分这种关键操作宁可多等几秒也不能丢数据。5.5 小程序端直接操作数据库导致权限失控现象上线后发现有人刷成绩。原因是开发阶段图方便在小程序端直接调用了db.collection(answers).add()权限设成了所有用户可写。解决方式是所有写操作迁移到云函数数据库权限收紧到“所有用户不可读写”只允许云函数通过管理端权限访问。这个改动越早做越好后期迁移成本很高。6. 从能跑到好用答题小程序的性能调优与数据验证6.1 用云开发控制台的慢查询日志定位瓶颈云开发控制台提供数据库慢查询日志可以按耗时排序。我一般会关注超过 500ms 的查询逐个分析是否走了索引。答题场景中最常见的慢查询是排行榜聚合和题库随机抽题。前者通过加索引和缓存解决后者通过预生成题目列表解决——在创建 session 时就把题目 ID 列表固定下来后续按 ID 逐个拉取避免每次随机抽题都做聚合。6.2 答题数据的一致性校验脚本上线后需要定期校验数据一致性。我写了一个云函数检查每个 session 的答题记录数是否等于题目数以及是否有重复记录。// cloudfunctions/checkConsistency/index.js const cloud require(wx-server-sdk) cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV }) const db cloud.database() exports.main async () { const sessions await db.collection(sessions) .where({ status: finished }) .limit(100) .get() const issues [] for (const session of sessions.data) { const answers await db.collection(answers) .where({ sessionId: session._id }) .count() const expected session.questionIds.length if (answers.total ! expected) { issues.push({ sessionId: session._id, expected, actual: answers.total }) } } return { code: 0, data: { checked: sessions.data.length, issues } } }这个脚本每次跑 100 个会话避免云函数超时。发现不一致的记录后人工介入排查是并发写入问题还是逻辑漏洞。6.3 用体验评分数据反推优化优先级小程序后台的体验评分里性能评分和请求耗时直接相关。我一般会盯着两个指标首次渲染时间和云函数调用平均耗时。首次渲染超过 2 秒优先检查主包体积和首屏数据请求是否串行。云函数平均耗时超过 800ms优先检查数据库查询是否走了索引。这两个指标改善后用户完成率通常会有明显提升。6.4 一个被低估的技巧预生成题目快照答题过程中如果题库被修改正在答题的用户可能遇到题目内容变化。解决办法是在创建 session 时把题目内容快照存到 session 文档里。这样即使用题库后续更新当前会话不受影响。代价是 session 文档会变大但答题场景中单个 session 的题目数量有限通常不超过 50 题文档大小可控。这个做法我是在一次线上事故后加上的——运营在活动期间修改了一道题的选项导致已开始答题的用户提交后判分错误。快照机制虽然简单但能避免这类玄学问题。我现在的习惯是任何答题类项目先把 session 快照和唯一索引建好再写业务逻辑。这两个东西后期补的代价远大于前期加上的成本。希望帮到你。本文还有配套的精品资源点击获取
