云开发在线考试系统实战：从组卷到自动判分完整指南

如果你在搜索引擎里看到“云开发考试用qwe123”这种标题，我猜你不是在找一个会被人吐槽的弱密码，而是在找一套能快速上手的在线考试系统。qwe123只是项目初始化时随手写的管理员演示密码，真正有价值的是后面两个字：云开发。简单说，这是一套基于微信云开发/腾讯云开发技术的在线答题与考试方案，把题库管理、试卷组卷、在线答题、自动判分、成绩记录全部放到云端，前端跑在小程序里，后端业务用云函数实现。你不用买服务器、不用配域名、不用管HTTPS证书，一个前端项目甚至一个人就能从零把它搭起来。适合企业内部培训考核、学校社团测验、技能竞赛预选，以及想用小程序做答题工具的开发者。

我自己拿到这套方案后，第一时间就把管理员侧的默认密码从qwe123改掉了，然后开始梳理题目表、试卷表、考试记录表怎么设计。整个过程踩了不少坑，尤其是数据库权限和判分边界这两个地方，最容易被新手忽略。这篇文章就把我实际搭建“云开发考试系统”的完整思路写出来，包括为什么选云开发、数据库怎么建模、云函数判分怎么写、以及上线前必须处理的几个问题。也顺手聊两句大家搜过的那两个问题：Taro init有没有云开发版本，以及ThinkPHP6做阿里云点播与云开发是什么关系。

1. 先把“云开发考试系统”拆开看：它在帮谁解决什么问题

1.1 从标题里的 qwe123 说起，真实的项目往往是这么长出来的

我相信大部分做项目的朋友都干过一件类似的事：本地联调时图省事，后台管理员账号直接写admin，密码写qwe123。项目跑起来了，截图发群里，标题就叫“云开发考试用qwe123”。这个标题听上去有点随意，但它背后反映了一个很真实的开发者心理：赶快把流程跑通，细节后面再补。

如果你只是改了默认密码就开始接需求，那大概率会把一个本来很轻的考试系统做成重后端。结果就是：题目存MySQL、登录用Session、判分写一个Java接口、成绩导出再做报表，最后发现从零到能考试至少要两周。而用云开发，逻辑发生了根本变化：用户身份用什么解决？小程序调用云函数时可以直接取到openid，不需要你设计注册接口。题目和成绩放哪？云数据库。自动判分和组卷放哪？云函数。文件上传和封面图？云存储。剩下的工作基本就是页面和业务规则了。

所以我对这类项目的判断是：它不是考你后端有多强，而是考你能不能抛开“老一套”，用更短路径把核心功能交付出来。这里的核心功能是什么？很简单：登录无感知、组卷不乱抽、交卷能判分、成绩可导出。

1.2 哪些场景真正适合用这套“云开发考试”方案

很多人会把考试系统分成两类：严肃考试，比如资格考试、职业技能考试；轻量考试，比如部门培训、社团答题、周末题库PK。

前一类对安全、监控、防作弊、高并发都有要求，明显不适合用免费额度开发的小程序Demo来扛。但第二类场景恰恰是云开发最擅长的。

我实践下来，以下场景可以直接复用这套方案：

• 公司新员工入职培训后的小测，需要自动阅卷并让HR看到成绩；
• 高校社团搞线上知识竞赛，学生扫码进入，倒计时结束自动交卷；
• 连锁门店做产品知识考核，店长发布试卷，店员各自答题；
• 学校教师想定期给学生布置一套选择题练习，但不想买商业考试系统；
• 个人开发者想做一个答题类小程序，用来验证流量或者作为App的功能模块。

这些场景有一个共同特点：单场考试人数通常只有几十到几百人，题目总量在200到2000题之间，逻辑简单、时间固定、判分标准明确。技术选型如果去搞一台2核4G的云服务器，装MySQL加Redis再部署一个管理后台，完全是杀鸡用牛刀。

1.3 为什么我建议用小程序而不是网页承载考试

先别急着写代码，先想清楚一个问题：考试这个小程序到底要跑在哪。

我见过一些团队用H5页面做考试，用户收到链接后打开浏览器答题，看起来很通用，但马上会遇到登录态要自己维护、微信内浏览器调用无痕登录麻烦、安卓和iOS布局容易错位等问题。如果再做更多操作，比如拍照上传、一键复制考题给错题本，网页的体验也要费很多工夫。

小程序的好处是身份天然隔离。用户在微信里点开小程序，云开发就能拿到他的openid，整场考试不需要输入姓名学号。尤其是云开发版本下，一个 wx.cloud.init 就能打通前后端，用户感觉不到任何注册登录的存在，体验非常顺。我在公司的线下培训考核中实际用过一次，学员扫码后只等了一秒就进入了试场，后台自动记录到每个openid对应的成绩，这让管理员非常省心。

所以这套系统非常适合作为“扫码即考”的轻量考试承载层。

2. 为什么我建议用云开发而不是先买服务器：与 ThinkPHP6 方案的一次对比

2.1 ThinkPHP6 + 阿里云点播的常见技术路径

我看到热搜里有一个问题：thinkphp6 开发阿里云点播。搜索这类词的人，多半是把考试系统想成了一个传统的Web项目：前端页面提交数据，PHP控制器接收，使用阿里云点播SDK上传视频课程、生成播放凭证，再把题库写在MySQL表里。

传统做法确实成熟。用一个ThinkPHP6项目做考试系统时，你一般会做四件事：

一是安装 aliyun/vod 相关SDK，在PHP里用AccessKey调用点播接口；二是把用户答题记录存到MySQL，忙的时候再把高频统计写进Redis；三是在每次请求时验证Session或Token，确认用户已经登录；四是部署到服务器，处理好Nginx、PHP-FPM、HTTPS证书这些环境。

用PHP做点播的代码通常长这样：

php复制// 以 ThinkPHP6 控制器方法为例
public function uploadAuth()
{
    $client = new DefaultAcsClient(
        EasyCloud::getProfile() // 配置Region、AccessKeyId、AccessKeySecret
    );
    $request = new CreateUploadVideoRequest();
    $request->setTitle('培训视频');
    $request->setFileName('test.mp4');

    $response = $client->getAcsResponse($request);
    return json([
        'uploadAuth' => $response->UploadAuth,
        'uploadAddress' => $response->UploadAddress,
        'videoId' => $response->VideoId,
    ]);
}

这套路径当然能跑通。难点在于，你需要在项目里处理很多和“考试”关系不大的事：服务器宕机怎么办、HTTPS证书过期怎么办、PHP进程内存够不够、Redis缓存要不要加、接口被刷了怎么防。对一个小型考试系统来说，这些运维成本比业务本身还高。

2.2 云开发把哪些环节真正省掉了

用云开发再造这套考试系统，我第一感受是：以前那些启动项目前必须做的“准备工作”几乎全没了。

不需要自己部署环境。云函数就是一个Node.js或TypeScript运行环境，代码传上去就能跑；云数据库就是文档型数据库，一个集合对应一张表；用户身份由平台提供，微信侧调用云函数时自动注入openid。

也不需要配置HTTPS合法域名。小程序调用云函数使用的是 wx.cloud.callFunction，不走普通request接口，所以不需要在小程序后台给自己域名加白名单。这一点在团队里如果之前没接触过云开发，很容易卡住。

举个我自己跑通的例子。考试系统的核心后端只用了四个云函数：createPaper负责组卷、getPaper负责从题库抽题并把答案字段遮掉后返回给小程序端、submitExam负责接收答题内容并自动判分、getMyResult负责查成绩。从云函数开发到前端联调，第一天就把骨架全部跑通了。如果换成ThinkPHP6项目，我得先装Composer依赖、建数据库、配置 .env，再写路由，至少多花一天。

2.3 云开发与ThinkPHP6如何选择，我给自己归纳的决策清单

云开发不是银弹。在技术选型这个事上，我给自己定了一个判断标准：

如果你的系统只有内部几百人用，业务逻辑基本是增删改查加简单判分，那云开发绝对省成本。如果你有大量异步任务、复杂MySQL事务、多系统对接，且数据要长期做复杂报表分析，那传统PHP项目依然更合适。

我把两者放在一起做了张表：

所以我给那位搜“thinkphp6 开发阿里云点播”的朋友的建议是：如果只是想在考试系统里加入视频题，那你真正需要的是点播服务，而不是因为要用点播服务就把整个后端迁移到PHP。云端一体化的方案在中小规模场景里更划算。

3. 数据库怎么设计才能撑起一场考试：题库、试卷、记录一次讲清

3.1 题库集合question：答案为什么要用数组而不是字符串

考试系统的地基不是代码，而是数据模型。我用云数据库设计了三个核心集合：question（题目）、paper（试卷）、exam_record（考试记录）。先把题目集合讲清楚。

云开发数据库的集合可以理解为MongoDB风格的JSON文档，一条题目存储成一条记录。我实际用的核心字段如下：

json复制{
  "_id": "q_1001",
  "type": "single",
  "category": "云开发基础",
  "content": "在微信云开发中，获取用户唯一标识的字段是？",
  "options": {
    "A": "openid",
    "B": "userInfo.nickName",
    "C": "session_key",
    "D": "appid"
  },
  "answer": ["A"],
  "analysis": "openid是用户在当前小程序内的唯一标识。",
  "difficulty": 1,
  "status": "enabled"
}

很多第一次做题库的人会把answer设计成字符串"A"或者"ABCD"，只有单选题还勉强够用，一旦出现多选和判断，字符串解析会让你想骂人。我在项目里统一把answer设计成数组，单选就是["A"]，多选就是["A","C","D"]，判断题的选项固定用A（正确）、B（错误），answer同样是一个数组。

options也用JSON对象而不是字符串数组来存。原因是前端渲染时可以直接按key取值，不需要关心数组下标被切错的问题。以后要抽题、换选项顺序、支持图片选项，都会好处理很多。

3.2 试卷集合paper：固定题和随机组卷怎么共存

题库建好之后就是试卷。试卷表示“一场考试”，至少需要记录考试名称、考试时长、总分、及格线、题目范围、状态。

我设置的paper集合长这样：

json复制{
  "_id": "paper_202501",
  "title": "2025年度产品知识模拟考试",
  "duration": 30,
  "totalScore": 100,
  "passScore": 60,
  "startAt": "2025-02-01 09:00:00",
  "endAt": "2025-02-01 18:00:00",
  "paperRule": {
    "categories": ["产品知识", "安全规范"],
    "singleCount": 12,
    "multiCount": 3,
    "judgeCount": 5,
    "singleScore": 5,
    "multiScore": 10,
    "judgeScore": 2
  },
  "status": "published"
}

注意这里的 paperRule，这是成套出题的关键。平时经常有老师说“给我出一套20题的卷子，12道单选、5道多选、3道判断，尽量别和上次重复”。没经验的人会在题库里随机手选20题，然后写进题目ID数组。这种方案可以做，但每套卷子都要手工维护一个questionIds数组，特别麻烦。

我后来改成了“规则组卷”模式：paper里存的是各种题型的数量、分值、分类范围，云函数根据规则临时从题库抽题，再把抽到的题目ID固化到考试记录里。这样既能保证卷面符合要求，也能防止考试中途题库被改动导致考生看到不同的题。

3.3 考试记录集合exam_record：成绩、答题快照和防重复交卷

考试记录是第三个集合，也是事务最集中的地方。用户开始一场考试时，我先创建一条记录，状态为doing；用户交卷后，云函数更新这条记录，把答案快照、得分情况、用时都写进去。

记录结构示例：

json复制{
  "_id": "record_8001",
  "openid": "oX-abc123",
  "paperId": "paper_202501",
  "startAt": 1738300000000,
  "submitAt": 1738301800000,
  "durationUsed": 1200,
  "status": "submitted",
  "score": 85,
  "answers": [
    {
      "questionId": "q_1001",
      "userAnswer": ["A"],
      "correct": true,
      "gainScore": 5
    },
    {
      "questionId": "q_1002",
      "userAnswer": ["B", "D"],
      "correct": false,
      "gainScore": 0
    }
  ]
}

考试记录里务必存答题快照，不要只在分数上写个85。不然考生想复查错题时，管理员根本不知道当时他的选项是什么。answer是云函数判分后返回给用户看的完整数组，包含了每一题的用户答案、是否正确、得分，这样前端不用再反向查题库去拼结果。

防重复交卷也靠这条记录。考试开始后，状态是doing，交卷时把status从doing改成submitted。由于考试端用户可能误触两次提交按钮，云函数里必须通过记录状态或事务来挡住第二次提交，否则同一场考试会出现两条成绩。我后面会详细讲事务写法。

3.4 数据库权限设置：绝不能让小程序端直接读到答案字段

这一步是决定性的一环。

云开发数据库默认的权限如果设置不当，终端用户直接通过控制台或者越权调用就能把题目答案全部拉走。我的原则是：凡是涉及answer的集合，都不要对客户端开放可读权限；小程序端只通过云函数拿“脱敏后的题目”。

在云开发控制台的数据库权限里，我把题库和考试记录集合都设成“所有用户不可读写”，或者使用自定义安全规则，仅允许云函数访问。云函数在小程序端通过 cloud.database() 调用时，属于服务端权限，不受这些客户端权限限制。用户能接触到的，只有云函数返回的JSON结果。

客户端只调getPaper接口拿到的题目结构里，answer字段已经被过滤掉。这样即使有人抓包也只会看到题目、选项和分值，看不到正确结果。

4. 核心代码实战：组卷、交卷、自动判分怎么落地

4.1 组卷云函数：只给题目不出答案

很多人写组卷时习惯直接在前端查题库，这非常危险。前端一旦能查题库，想要完整题库就只是时间问题。所以我在小程序端不开放题库集合，而是通过云函数获取试卷和题目。

这是一个getPaper云函数的简化版本：

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 { paperId, openid } = event
  const wxContext = cloud.getWXContext()
  const uid = openid || wxContext.OPENID

  // 1. 查询试卷基础信息
  const paperRes = await db.collection('paper').doc(paperId).get()
  const paper = paperRes.data

  // 2. 如果试卷没有设置固定问题列表，则按规则随机抽题
  const now = Date.now()
  const rule = paper.paperRule || {}
  const query = {
    status: 'enabled'
  }
  if (rule.categories && rule.categories.length) {
    query.category = _.in(rule.categories)
  }

  // 3. 按题型分别抽题
  const singleQuestionRes = await db.collection('question')
    .where({ ...query, type: 'single' })
    .limit(rule.singleCount || 0)
    .get()
  const multiQuestionRes = await db.collection('question')
    .where({ ...query, type: 'multi' })
    .limit(rule.multiCount || 0)
    .get()
  const judgeQuestionRes = await db.collection('question')
    .where({ ...query, type: 'judge' })
    .limit(rule.judgeCount || 0)
    .get()

  const questions = [
    ...singleQuestionRes.data,
    ...multiQuestionRes.data,
    ...judgeQuestionRes.data
  ]

  // 4. 返回给前端的题目必须去掉answer和analysis
  const safeQuestions = questions.map(q => {
    const { answer, analysis, ...rest } = q
    return {
      ...rest,
      options: q.options
    }
  })

  // 5. 创建考试记录
  const recordRes = await db.collection('exam_record').add({
    data: {
      openid: uid,
      paperId,
      status: 'doing',
      startAt: now,
      score: -1,
      answers: []
    }
  })

  return {
    recordId: recordRes._id,
    paper: {
      _id: paper._id,
      title: paper.title,
      duration: paper.duration,
      totalScore: paper.totalScore,
      passScore: paper.passScore,
      endAt: paper.endAt
    },
    questions: safeQuestions,
    serverTime: now
  }
}

有几个细节值得注意：第2步按规则查题库时，我没有直接支持“完全不按分类随机抽”的写法，如果要全题库随机，可以去掉where条件再按limit抽取。为了保证考试已开始且未过期，真实项目里一定要判断 now 是否在 startAt 和 endAt 区间。很多Demo不判断这个，考生明天还没到考试时间，就能先把题目刷走。

4.2 提交判分云函数：一次性判断单选、多选和判断题

交卷判分是整个系统最核心的业务代码。我的设计思路是：把所有判分逻辑放在同一个云函数里，把题目正确答案也全查出来，然后逐题比对。

先写一个统一的判断函数：

js复制function isAnswerCorrect(question, userAnswer) {
  if (!Array.isArray(userAnswer)) return false
  if (!Array.isArray(question.answer)) return false

  // 单选题、判断题：唯一答案
  if (question.type === 'single' || question.type === 'judge') {
    return userAnswer.length === 1 && userAnswer[0] === question.answer[0]
  }

  // 多选题：必须完全匹配，顺序不影响结果
  if (question.type === 'multi') {
    if (userAnswer.length !== question.answer.length) return false
    const sortedUser = [...userAnswer].sort().join(',')
    const sortedRight = [...question.answer].sort().join(',')
    return sortedUser === sortedRight
  }

  return false
}

如果业务上定义“多选题漏选得半分”，可以把错判逻辑改成分值折算。多数模拟考试里，多选漏选不给分，所以这里直接按照完全匹配判断。

云函数接收用户答案时的数据格式，我规定为数组，比如用户选A就传 ["A"]，选A和C就传 ["A", "C"]。为了不暴露答案，云函数在交卷时需要重新查询paper，再根据每道题的questionId找到正确选项进行比对。

提交判分的云函数如下：

js复制const cloud = require('wx-server-sdk')
cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV })
const db = cloud.database()

exports.main = async (event) => {
  const { recordId, paperId, answers } = event
  const wxContext = cloud.getWXContext()
  const openid = wxContext.OPENID

  // 使用事务，防止并发重复提交
  const transaction = await db.startTransaction()

  try {
    const recordRes = await transaction.collection('exam_record').doc(recordId).get()
    const record = recordRes.data

    // 已交卷则直接返回，防止重复判分
    if (record.status === 'submitted') {
      await transaction.rollback()
      return { code: 1, msg: '该试卷已交卷' }
    }

    // 查询试卷和题目
    const paperRes = await transaction.collection('paper').doc(paperId).get()
    const paper = paperRes.data

    let totalScore = 0
    const detail = []
    const userAnswerMap = (answers || []).reduce((map, item) => {
      map[item.questionId] = item.userAnswer
      return map
    }, {})

    for (const q of paper.questions || []) {
      const userAnswer = userAnswerMap[q._id]
      const correct = isAnswerCorrect(q, userAnswer)
      const gainScore = correct ? (q.score || 0) : 0
      totalScore += gainScore
      detail.push({
        questionId: q._id,
        userAnswer: userAnswer || [],
        correct,
        gainScore
      })
    }

    // 更新考试记录
    await transaction.collection('exam_record').doc(recordId).update({
      data: {
        status: 'submitted',
        submitAt: Date.now(),
        score: totalScore,
        detail
      }
    })

    await transaction.commit()
    return {
      code: 0,
      score: totalScore,
      pass: totalScore >= (paper.passScore || 60),
      detail
    }
  } catch (err) {
    await transaction.rollback()
    throw err
  }
}

这段代码非常实用。用事务可以避免用户连点两次提交带来的重复扣分问题。很多考试系统在刚上线时都会遇到“我点了一下没反应，又点了一下，结果出现两条考试记录”的问题，事务加上状态判断可以从源头解决。

这里还有一个容易忽略的问题：paper里需要保存一套“本次考试实际使用的题目快照”。否则考试结束以后，如果题库里的某道题被管理员下架或改答案，考生成绩就会莫名其妙变化。所以无论组卷时用的是固定questionIds还是临时抽题，都建议在发卷时把抽到的题目整体快照到paper集合，或者直接把题目完整字段存到考试记录里。我实际生产项目里使用的方式是把题目完整快照写到record里或者一份paper_snapshot集合，判分时只读快照不读实时题库。

4.3 小程序端：倒计时到点自动交卷的写法和记录恢复

考试终究要落到前端页面。前端最少需要有这样几块：进入页面调getPaper拿题、渲染单选题和多选题组件、倒计时、用户点交卷或时间到自动交卷。

我使用原生小程序实现一个大概的想法：

js复制Page({
  data: {
    recordId: '',
    paper: {},
    questions: [],
    answers: {},
    remainSeconds: 0,
    currentIndex: 0
  },

  async onLoad(options) {
    const paperId = options.paperId
    const res = await wx.cloud.callFunction({
      name: 'getPaper',
      data: { paperId }
    })
    const { recordId, paper, questions, serverTime } = res.result
    this.setData({
      recordId,
      paper,
      questions,
      remainSeconds: paper.duration * 60
    })
    this.startCountdown()
  },

  startCountdown() {
    this.timer = setInterval(() => {
      const remain = this.data.remainSeconds - 1
      this.setData({ remainSeconds: remain })
      if (remain <= 0) {
        clearInterval(this.timer)
        this.submitExam()
      }
    }, 1000)
  },

  onChooseAnswer(e) {
    const { index, value } = e.currentTarget.dataset
    this.setData({ [`answers[${index}]`]: value })
  },

  async submitExam() {
    const { recordId, paper, questions, answers } = this.data
    const answerList = questions.map((q, i) => {
      return {
        questionId: q._id,
        userAnswer: answers[i] || []
      }
    })

    const res = await wx.cloud.callFunction({
      name: 'submitExam',
      data: {
        recordId,
        paperId: paper._id,
        answers: answerList
      }
    })

    if (res.result.code === 0) {
      wx.redirectTo({
        url: `/pages/result/result?recordId=${recordId}`
      })
    }
  },

  onUnload() {
    if (this.timer) clearInterval(this.timer)
  }
})

这里的answers我用数组下标来保存每一题的答案。单选时value是一个字符串，保存前包成数组；多选时value传入一个数组。真机上最重要的是：用户如果中途退出，下次进入时要能恢复未交卷的recordId，而不是重新创建新记录。所以onLoad里加一个逻辑，先去查询自己有没有doing状态的记录，有就直接继续答题，没有才调getPaper。

用服务器返回的serverTime来校准剩余时间更严谨，不能只靠本地时间，因为用户可能改手机时间。倒计时建议从云函数返回的endTime减去serverTime计算，这样更接近真实规定时长。上面示例为了易懂只用了本地计数，你可以在进阶版本里替换。

4.4 现在来回答热搜问题：tarojs init 有没有云开发版本？

如果你用的是 Taro 做多端小程序，并且搜过“tarojs init有没有云开发版本”，这里直接说结论：官方提供给 init 命令的模板里没有直接叫“cloud-development”或“云开发”的选项。我当时第一次执行 taro init 时也愣了一下，看到 React、Vue、Nerv 这些模板，以为是不是需要先选带云开发的后台模板。

不是的。Taro只是个编译框架，云开发是小程序能力，两者可以分开理解。你用 taro init 创建普通项目后，在代码里同样可以使用微信小程序的云能力。需要的配置步骤大概是：

第一步，在 project.config.json 中配置 cloudfunctionRoot，指定云函数目录：

json复制{
  "miniprogramRoot": "dist/",
  "cloudfunctionRoot": "cloudfunctions/"
}

第二步，在入口文件初始化云开发环境：

ts复制import Taro from '@tarojs/taro'

Taro.cloud.init({
  env: 'your-env-id',
  traceUser: true
})

第三步，需要的时候调用云函数：

ts复制const res = await Taro.cloud.callFunction({
  name: 'getPaper',
  data: {
    paperId: 'paper_202501'
  }
})

也就是说，云开发版本不是靠 taro init 选的，而是你给小程序的 project.config.json 加一个云函数目录、在代码里多写一行 Taro.cloud.init 就变出来的。如果你是 Taro3，Taro.cloud 已经带类型声明，和 wx.cloud 用法基本一致。但如果你主要想编译到 H5，那 H5 端没有 wx.cloud，需要用 Web 端的 CloudBase JS SDK 做兼容，到时候再引入云开发身份认证那一套。

Taro本身不限制云开发的使用场景，它的模板系统和云开发是正交的。理解了这一点，你就不用再去搜“云开发版本模板”了，直接在你的项目里接云开发即可。

5. 我踩过的坑：弱口令、数据库权限、判分边界和云函数超时

5.1 qwe123这类的默认密码，上线前必须改干净

这个坑几乎是所有自用项目第一次暴露在真实用户面前时都会踩的。本地开发图方便，管理端登录账号固定为admin，密码固定为qwe123，上线后因为赶时间没有改，结果用户在浏览器或者小程序端很容易就能猜中。

在云开发考试系统里，管理员角色也是放在某个admin集合中的。我建议不要再存明文密码，至少用盐值加哈希的方式存储。云函数端可以引入Node.js的crypto模块，对密码做sha256或scrypt处理。如果你的管理端只是给内部使用，更省心的方法是把管理员openid写死到环境变量或白名单集合，用户能登录小程序就代表经过微信身份验证，不一定需要再输密码。至少，绝对不要让qwe123出现在生产环境。

5.2 collection权限设置错了，你在客户端裸奔

考试系统的用户是普通考生，不是防止逆向的程序员，但一旦你把错误数据返回给客户端，普通用户中的聪明人很容易发现字段异常。

我在早期Demo里把question集合的权限设为“所有用户可读”，然后前端直接调数据库读取题目列表。这意味着所有小程序用户只要构造一个 wx.cloud.database().collection('question').get() 调用，就能把数据库里所有题目的answer字段拉出来。这不叫考试，叫开卷题库。

正确做法是题目集合权限设为不开放给客户端，所有读写都走云函数。学习云开发时很多人不重视权限，是因为自己只有一个管理端在操作，看不到外部威胁。一旦发布上线，权限规则就是第一道安全屏障，务必要把客户端数据库权限调到最严格。

5.3 多选题判断顺序不一致，答案错判得分

这个坑非常隐蔽。用数组保存多选答案时，不同端、不同用户操作后，数组顺序可能不一致。比如用户先点A再点C，得到["A","C"]；另一个用户先点C再点A，得到["C","A"]。如果判分时直接比较数组下标，即使两个都对也会变成一错一对。

正解就是比较前先排序，或者用Set比较。我在云函数里使用 sort().join(',') 把答案序列化后比较，这样用户选择顺序就不影响判分结果了。判断单选题时也要注意用户答案必须是一个数组。如果前端不小心传了一个纯字符串，要主动转成数组。前端在小程序设置答案时，多选每一项的checked状态更新也要记得同步维护数组，否则会出现选了C但数组里只有A的问题。

5.4 云函数冷启动导致超时

云函数的冷启动是小程序开发里很常见的问题。考试交卷瞬间，如果同时几十人提交，云函数发生了冷启动，某些请求可能超时。我遇到过几次：本地开发没有感觉，一到集中考试结束的时间点，云函数日志里就能看到几个 FunctionTimeOut。

后来我会做几件事优化：

• 查询题目快照时一次性查全，不要在循环里逐题get；
• 数据库和判分计算尽量在同一个云函数内完成，避免多次调用带来的时延；
• 如果是低频使用，可以在考试开始前创建一条预热请求；
• 必要情况下把云函数的超时时间在 config.json 里调到10秒左右，默认5秒偶发不够用；
• 交卷接口的请求体不要太大。如果一场考试有100道题，每次传100个题的答案数据还好，但如果还有大段做题轨迹JSON，就很可能超过内存和请求体限制。

5.5 用户重复点击交卷导致记录被覆盖

前端按钮没有加防重复点击时，用户在网络卡顿时会反复点击交卷按钮。每个请求都会调用云函数，如果不做状态判断，后面的请求可能会把前面已经算好的总成绩覆盖成0分，或者又新增一条考试记录。

我在云函数中使用了事务和status状态判断，当记录已是submitted时直接返回“已交卷”。同时前端在第一次点击后立即把按钮设为loading状态，避免用户在等待期间反复触发。这两个措施叠加后，重复交卷的问题基本消失。

5.6 数据库日期与统计口径不一致导致成绩无法导出

考试记录里如果直接用本地时间字符串，不同手机的系统时间会有偏差。我实际开发中遇到过考生提前开始考试、交卷时间比服务器时间早的情况。

所以发卷和交卷的时间统一以云函数执行时的服务器时间为准。小程序端传上来的时间只做展示，不参与状态判断。成绩导出时，管理员看到的开始时间、答题时长、交卷时间，全部以服务器时间字段为准。这样避免了因为时区、手机时间改乱导致的脏数据。

6. 同一套代码还能做什么：向练习、竞赛与音视频题扩展

做完基础考试系统后，我并没有马上收工，而是把这套云开发的数据库模型和云函数逻辑继续用在了其他几个场景中。你会发现，考试只是答题场景的一个特殊形态，把“固定时间、一次交卷、严格判分”改成“随时练习、多次作答、记录错题”，就变成了练习系统；把题目变成活动和抽奖问题，就变成了留资问卷。

扩展一：练习模式。只需要给question增加一个 mode 字段，比如exam/exercise。练习模式的记录不设考试开始时间和paperId，用户可以反复刷题，答题完成后生成错题本，云函数只判分不限制次数。

扩展二：视频题。如果要让考试中出现视频题目，比如播放一段员工操作视频后再答题，可以在题目中增加一个media字段，里面放置视频文件ID。如果团队已经使用阿里云点播，那么视频上传和播放鉴权部分确实可以沿用ThinkPHP6生成凭证的方式，但不需要让PHP业务去维护考试流程。考试流程依然交给云开发，只有在播放视频、获取播放凭证时才请求PHP服务。这样职责更清晰，也避免把一个轻量考试系统拉成一个单体PHP应用。

扩展三：成绩数据看板。云开发数据库支持通过HTTP API或定时触发器把成绩记录导出，也可以直接在云函数里聚合统计平均分、及格率、每道题错误率。尤其每道题错误率这个指标，对出题老师非常有价值。你可以看到哪些题错的过多，说明题目表述不清或者知识点没讲透，方便后续调整培训和题库。

我走到这一步的体会是，云开发考试系统的难点并不在于云函数怎么写，而在于从传统“服务器+数据库+登录注册”的思路里跳出来，接受新的产品设计方式。数据库权限、接口边界、数据快照、防重复提交，这些才是真正决定系统能不能稳定跑下去的关键。用云开发做中小型考试系统，最大的收益不是省了服务器钱，而是把注意力放