廊坊小程序制作题库：从0到1的实战复盘

去年秋天，一位在廊坊师范学院附近做教培的朋友找到我，说想做个题库小程序，让学生刷题、错题重练、看解析。需求听起来不复杂，但真正动手做，才发现题库类小程序有几个坑必须提前想清楚。这篇文章就把我在廊坊做这个项目的实战过程拆开讲，给同样想做题库的本地朋友一些参考。

一、先想清楚：题库小程序到底解决什么问题

很多人一上来就问「能不能做」，其实更该问「做什么」。题库类小程序的核心不是把题目搬上线，而是三件事：

• 刷题体验：单选、多选、判断、填空，交互要顺手，切题不能卡；
• 错题沉淀：错题自动归集，支持重练，这是留存的关键；
• 数据反馈：正确率、章节掌握度，让学生知道弱在哪。

这位廊坊的客户做的是职业资格考试培训，学员分散在广阳、安次、霸州各地，线下集中难。所以小程序的第一价值是「随时刷」，第二价值是「老师能看到谁没刷」。需求定清楚，后面的技术选型才有依据。

二、技术选型：为什么选微信小程序 + 云开发

题库类应用的特点是「读多写少」，题目数据量大、更新频率低，用户端主要是查询和记录。这种场景，我一般推荐微信小程序原生开发配云开发，理由很实在：

• 不用自己买服务器、配域名、备案，起步成本低；
• 云数据库天然支持分页查询，题库几千道题也扛得住；
• 云函数处理判题、统计，逻辑集中在服务端，前端轻。

对于廊坊本地中小机构来说，预算通常有限，这套方案能把前期投入压到最低。如果后续用户量上来，再迁移到自建后端也不迟，数据结构设计好，迁移成本可控。

三、数据库设计：题库的骨架

题库小程序最容易翻车的地方是数据结构没设计好，后期加功能要重构。我一般拆成四张表：

// 题目表 questions
{
  _id: "q_001",
  categoryId: "cat_01",      // 章节/分类
  type: "single",            // single/multiple/judge/fill
  stem: "题干内容",
  options: ["A选项", "B选项", "C选项", "D选项"],
  answer: [0],               // 正确答案索引数组
  analysis: "解析文本",
  difficulty: 2,             // 1-5
  status: 1                  // 1上架 0下架
}

// 用户答题记录 records
{
  _id: "r_001",
  openid: "o_xxx",
  questionId: "q_001",
  userAnswer: [1],
  isCorrect: false,
  createdAt: 1699999999999
}

注意两点：答案统一用索引数组存，单选多选一套逻辑；答题记录单独存，不要塞进用户表，否则数据量一大就难查。错题本其实是 records 的一个查询视图，不需要单独建表。

四、核心功能实现要点

1. 分页加载与本地缓存

题库动辄上千题，一次性拉取不现实。我的做法是云函数按分类分页返回，前端用本地缓存存最近刷过的题，断网也能看。分页大小控制在 20 条左右，体验和流量都平衡。

2. 判题逻辑放云函数

答案不要下发到前端，否则容易被抓包。前端只提交用户选择，云函数比对答案后返回对错和解析。这样既安全，也方便统一维护判题规则。

3. 错题重练的排序

错题本按「错误次数 + 最近错误时间」排序，优先推反复错的题。这个小细节对留存帮助很大，客户反馈学员明显更愿意回来刷。

五、廊坊本地场景的几个细节

做本地项目，有些细节是通用的，但落地时得贴合实际：

• 机构学员年龄跨度大，中老年学员多，字号要能调大，按钮点击区域要够；
• 部分学员在县城，网络一般，图片解析要压缩，首屏加载控制在 2 秒内；
• 老师端要能批量导入题目，我做了 Excel 模板上传 + 云函数解析，省得一道道录。

这些不是高深技术，但决定了产品好不好用。知码客做廊坊小程序开发这些年，越来越觉得，本地项目的竞争力往往就在这些「不性感」的细节里。

六、上线后的真实数据

这个小程序上线三个月，注册学员 600 多人，日均刷题量稳定在 3000 题次左右，错题重练的使用率超过 40%。客户最满意的是老师端能导出班级正确率报表，直接用于教研。整个项目从需求确认到上线用了五周，费用控制在一万出头，对中小机构来说性价比不错。

题库小程序不难做，难的是把刷题体验做顺、把数据用起来。技术只是工具，想清楚业务闭环才是关键。

如果你也在廊坊，正打算做题库、培训类小程序，或者对 App 开发有想法，欢迎聊聊。我是知码客，专注小程序与 APP 开发，用代码改变生活。