微信小程序背单词开发实战：云开发+云函数实现打卡复习闭环

简介：一套基于微信小程序开发的背单词应用源码，面向有英语学习需求的小程序用户，也适合想学习教育类小程序开发的前端人员。压缩包内共54个文件，体积约416KB，主要包括14个js逻辑文件、8个wxml页面结构、9个wxss样式、9个json配置、12张png图片，另有字体和说明文档，目录结构清晰，便于直接导入开发者工具查看。项目内置1000个常用英语词汇，并针对离线场景进行了设计，用户在没有网络时也能打开单词列表进行学习。同时，源码通过微信小程序的播放音频能力完成单词发音，帮助学习者模仿跟读，提升听力和口语记忆效果；从代码组织来看，还引入了数据统计、云数据库等辅助模块，方便二次开发时拓展。目前已有3422人学习下载，对学习者来说可快速构建一个轻便的记词工具，对开发者来说则是一个完整的小程序实战案例，能借鉴其页面划分、数据读取和语音交互的实现思路。

1. 微信小程序背单词的最小闭环长什么样：一周上线一个能打卡的版本

微信小程序里搜“背单词”，排在前面的不是功能最全的，而是“每日打卡、发音跟读、错词本、连续天数”这几件事做得干净的应用。很多想做微信小程序背单词的开发者，精力往往耗在账户体系、复习算法、音频接口这些基础设施上，结果一个月过去页面还没填满。实际上，用微信小程序云开发做后端，原生小程序写页面，一个能背、能复习、能看连续打卡天数的版本一周就能跑通。这篇会把从建表到发布的步骤、参数和踩坑点一并写清楚，适合已经会写小程序基础页面、但没完整碰过数据模型和云开发的人。

2. 选原生小程序还是跨端框架：背单词场景的架构选型和单词表设计

做背单词小程序，第一个要回答的问题不是“用哪个 UI 库”，而是你的目标只针对微信、还是以后要同步输出到其他平台。背单词这类工具，朋友圈分享、群打卡、公众号跳转都依赖微信生态，如果只是为了验证留存和用户习惯，直接用原生小程序就够了。

跨端框架能帮你未来多端复用，但也引入编译链、样式兼容、原生组件适配等问题，前期成本不低。我遇到“要不要上跨端框架”这类犹豫时，通常会劝对方先用原生小程序跑通，把数据模型和接口边界理清楚，将来真要移植，重写页面层也比边想边写省事得多。

2.1 原生小程序 + 云开发：当前起步成本最低的组合

先说服自己为什么不用自建服务器。做背单词最小闭环，你需要的东西是：一个单词表、一个用户进度表、一个能跑定时任务的接口、一个能存音频的存储空间。如果按传统方式，要买域名、买服务器、备案、写后端接口、做鉴权，这套流程走下来已经劝退一多半人。

微信小程序的云开发把这些都变成了平台能力。云数据库是文档型存储，不需要预先建模，改字段非常方便；云函数在微信安全规则内运行，外部接口的密钥不会暴露到客户端；云存储专门放音频、图片；开通后自带免费额度，单人开发的体量基本用不到付费档。

我一般会建议：如果是背单词这种重内容、轻关系的产品，优先选第一行。云开发还有个隐藏优势，就是数据库权限可以配置为“所有用户可读，仅创建者可读写”，公开词库这类基础数据不需要写接口就能从客户端直接读，少一次云函数调用就少一次白屏风险。

2.2 单词集合设计：给复习算法预留字段，后面不用改表

单词集合words的每条记录，我会这样设计：

{ _id: "auto", word: "abandon", phonetic: "/əˈbændən/", pos: "v.", meaning: "放弃；抛弃", example: "He abandoned the car.", exampleTranslation: "他抛弃了那辆车。", level: "CET4", audioFileId: "cloud://env-id/audio/abandon.mp3", status: "ENABLED" }

status字段用来做词库下线，比如某条词义有争议或者例句有误，直接改成DISABLED，不用物理删除。level是查询频率最高的字段，要在云数据库的索引配置里给level和status建联合索引，否则数据量过万后查询会明显变慢。

用户进度单独建一个user_progress集合：

{ _openid: "oXXXX", wordId: "word_id", status: 1, // 0 不认识, 1 认识, 2 已掌握 reviewCount: 3, errorCount: 1, lastReviewAt: 1720000000000, nextReviewAt: 1720086400000 }

_openid是微信自动带的用户标识，不用自己写注册登录。云数据库里_openid是系统字段，通过客户端直接写入时会被自动加上，通过云函数写入时用cloud.getWXContext().OPENID拿到。这里要养成的习惯是：所有用户维度的查询都带上_openid，不然很容易串数据。

很多初学者会把单词和复习计划塞在同一张表里，当时看着省事，一旦要调整复习间隔就得动单词表结构。把词库和用户进度分开，词库是共享资源，进度是个人的私有状态，职责清楚，后面加新功能也容易。

3. 跑通背诵闭环：云函数、页面交互、发音和进度缓存的最少代码

闭环的定义很简单：用户进入小程序，选一个词库，看到单词卡片，点击“认识”或“不认识”，程序记录这次行为，并算出这个单词下一次该什么时候出现。然后循环。所有的设计都围绕这一条链路展开。

3.1 用云函数读写单词表，客户端只拿渲染所需数据

云函数承担两个核心动作：取一组单词、回报学习进度。把这类操作收敛到云函数里，好处是权限和校验都在服务端，后续要加统计埋点也方便。

// cloudfunctions/wordService/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 { OPENID } = cloud.getWXContext() const { action } = event switch (action) { case 'getWords': { const { level, limit } = event const res = await db.collection('words') .where({ level: level || 'CET4', status: 'ENABLED' }) .limit(limit || 20) .get() return { code: 0, data: res.data } } case 'getReviewWords': { const now = Date.now() const progressList = await db.collection('user_progress') .where({ _openid: OPENID, nextReviewAt: _.lte(now), status: _.neq(2) }) .limit(30) .get() const wordIds = progressList.data.map(p => p.wordId) if (wordIds.length === 0) return { code: 0, data: [] } const wordRes = await db.collection('words') .where({ _id: _.in(wordIds) }) .get() return { code: 0, data: wordRes.data } } case 'reportProgress': { const { wordId, status } = event const now = Date.now() const existed = await db.collection('user_progress') .where({ _openid: OPENID, wordId }) .get() if (existed.data.length === 0) { await db.collection('user_progress').add({ data: { wordId, status, reviewCount: 1, errorCount: status === 0 ? 1 : 0, lastReviewAt: now, nextReviewAt: calcNextReview(status, 1, status === 0 ? 1 : 0, now) } }) } else { const rec = existed.data[0] const newReviewCount = rec.reviewCount + 1 const newErrorCount = status === 0 ? rec.errorCount + 1 : rec.errorCount await db.collection('user_progress').where({ _openid: OPENID, wordId }).update({ data: { status, reviewCount: newReviewCount, errorCount: newErrorCount, lastReviewAt: now, nextReviewAt: calcNextReview(status, newReviewCount, newErrorCount, now) } }) } return { code: 0 } } default: return { code: -1, msg: 'unknown action' } } } function calcNextReview(status, reviewCount, errorCount, now) { if (status === 0) return now + 10 * 60 * 1000 const base = [0, 1, 2, 4, 7, 15, 30] const idx = Math.min(reviewCount, base.length - 1) let days = base[idx] if (errorCount >= 3) days = Math.max(1, days - 1) return now + days * 24 * 60 * 60 * 1000 }

代码逻辑说明：getWords负责每日新词，getReviewWords负责到期复习，reportProgress负责把学习结果写回。calcNextReview是简化版记忆间隔：不认识当天 10 分钟后再出现；认识后按 1、2、4、7、15、30 天递增；错词超过 3 次，间隔强制减一天，保证频繁错的单词浮在队列前面。

参数说明：limit默认 20，一屏背 20 个比较合理，太多会造成页面和数据压力；status: _.neq(2)过滤掉已掌握的单词；_.lte(now)取所有到达复习时间的记录，这是整个复习系统的核心查询条件。部署时在开发者工具里右键wordService目录，选择“上传并部署：云端安装依赖”，不是本地安装。

3.2 背诵页面的交互逻辑：认识、不认识、下一张

页面不需要复杂，单词卡片、释义、发音按钮、两个操作按钮，够了。先看数据层：

// pages/study/study.js Page({ data: { list: [], index: 0, total: 0, currentWord: {}, showMeaning: false }, async onLoad(options) { const level = options.level || 'CET4' wx.showLoading({ title: '加载单词' }) const res = await wx.cloud.callFunction({ name: 'wordService', data: { action: 'getWords', level, limit: 20 } }) wx.hideLoading() if (res.result && res.result.code === 0) { const list = res.result.data this.setData({ list, total: list.length, index: 0, currentWord: list[0], showMeaning: false }) } }, toggleMeaning() { this.setData({ showMeaning: !this.data.showMeaning }) }, markKnown() { this._report(this.data.currentWord._id, 1) this._next() }, markUnknown() { this._report(this.data.currentWord._id, 0) this._next() }, _report(wordId, status) { wx.cloud.callFunction({ name: 'wordService', data: { action: 'reportProgress', wordId, status } }) }, _next() { const nextIndex = this.data.index + 1 if (nextIndex >= this.data.total) { wx.showToast({ title: '本组完成', icon: 'success' }) return } this.setData({ index: nextIndex, currentWord: this.data.list[nextIndex], showMeaning: false }) } })

对应 WXML 骨架：

<view class="word-card" wx:if="{{currentWord}}"> <view class="word">{{currentWord.word}}</view> <view class="phonetic">{{currentWord.phonetic}}</view> <view class="meaning" bindtap="toggleMeaning"> {{showMeaning ? currentWord.meaning : '点击查看释义'}} </view> <button size="mini" bindtap="markKnown">认识</button> <button size="mini" bindtap="markUnknown">不认识</button> </view>

这版交互做了两个关键决定。第一，释义默认隐藏，用户先想再点，这是背单词的核心行为，不能一开始就暴露答案。第二，currentWord用单个对象做数据源，而不是把整个列表绑到视图上，这样setData每次只更新一个卡片对象，性能上安全得多。

这里需要留个心眼：markKnown和markUnknown回调里我没有直接给currentWord做乐观跳过，而是先上报再切下一个。顺序上先调_report后_next，防止连续快速点击时上报顺序错乱，导致某个单词的复习状态被覆盖成同组后一个单词的状态。

3.3 单词发音的两种接法：云存储音频和 TTS 代理

背单词没有发音是硬伤，用户会直接卸载。发音有两条路：预置音频或语音合成。

预置音频的做法是提前准备好词库所有单词的 mp3，上传到云存储，播放时把 fileID 转成临时链接：

playSound() { const word = this.data.currentWord if (!word.audioFileId) return wx.cloud.getTempFileURL({ fileList: [word.audioFileId], success: (res) => { const url = res.fileList[0].tempFileURL if (this._audio) this._audio.destroy() this._audio = wx.createInnerAudioContext() this._audio.src = url this._audio.play() } }) }

关键点是getTempFileURL。很多人直接把cloud://开头的 fileID 塞给audio.src，结果真机不出声，因为音频组件要的是 http 地址，不是云存储协议。getTempFileURL返回的链接默认有效期为两个小时，对播放场景够用。

TTS 代理适合词库不能覆盖的单词，比如用户自己导入的生词。常见做法是云函数里调用语音合成服务，把返回的音频写入云存储，得到一个 fileID，之后播放逻辑同上。这样做的好处是客户端永远不接触 TTS 服务的密钥，也绕开了小程序外部请求的域名白名单问题。坏处是首次播放慢，一般要 300-700 毫秒，所以我的建议是：常用词库预置音频，用户导入词走 TTS，命中后缓存住。

3.4 学习进度的本地缓存与云端备份

云开发不代表不需要本地缓存。地铁、电梯这些常见的背单词场景，网络质量很差，页面必须能在弱网下先把上一次的单词显示出来。

const STORAGE_KEY = 'study_cache' function saveLocal(list) { wx.setStorageSync(STORAGE_KEY, { list, savedAt: Date.now() }) } function readLocal() { try { const obj = wx.getStorageSync(STORAGE_KEY) if (obj && Array.isArray(obj.list) && obj.list.length > 0) { return obj.list } } catch (err) {} return [] }

弱网策略我是这样设计的：进页面先读本地缓存立即渲染，同时发起云端请求，云端返回后更新本地缓存和页面。如果用户已经背到第 15 个，云端返回的又是全新一组，不能直接覆盖当前进度，要按下标合并，保留index之前的记录。

进度上报也一样。云函数失败时把待上报的记录存到本地队列，等网络恢复后逐条补报：

const PENDING_KEY = 'pending_reports' function queueReport(wordId, status) { const list = wx.getStorageSync(PENDING_KEY) || [] list.push({ wordId, status, ts: Date.now() }) wx.setStorageSync(PENDING_KEY, list) }

补报操作在app.js的onShow里触发。这里有个细节：补报的ts只做排序用，云端时间以云函数内Date.now()为准，不能用客户端时间戳更新服务端的lastReviewAt，否则用户改系统时间就能刷复习计划。

4. 背单词小程序避坑清单：4 个上线前必查的实际问题

在开发者工具里跑通很容易，真机一跑就“翻车”的往往是这几件事。每一条我都按现象、原因、解决写清楚，照着排一遍能省很多线上事故。

4.1 现象：背诵页拉几百个单词后滑动卡死、界面白屏

原因大概率是setData一次塞了太大的数组。小程序的逻辑层和视图层是分离的，setData每次都要序列化整个数据对象，数组越长序列化越慢。我见过有人把 2000 条单词一次性setData到页面，结果页面直接卡到无响应。

解决方法是三管齐下。第一，请求层限制limit，一页最多 20 个，滚动到底再拉下一组；第二，视图层只绑定currentWord一个对象，列表数据只存内存不渲染；第三，如果确实需要渲染列表（比如单词表页），用wx:for时 key 必须给唯一_id，并且拆成多个小块渲染，不要用一个大scroll-view包所有节点。

// 错误做法：每点一次就 append 全量列表 this.setData({ allWords: this.data.allWords.concat(newWords) }) // 正确做法：只更新当前卡片 this.setData({ currentWord: newWord, index: nextIndex })

把数据量和视图绑定量降下来之后，白屏基本不会再出现。

4.2 现象：iOS 上点发音没声音，Android 正常

原因是 iOS 的静音开关会影响InnerAudioContext的默认行为。手机侧边静音键拨到静音时，小程序的音频默认也静音，用户以为是 bug，其实是开关在起作用。

解决方法是把obeyMuteSwitch显式设为false：

const audio = wx.createInnerAudioContext() audio.obeyMuteSwitch = false audio.src = tempUrl audio.play()

另外还有一个容易忽略的点：页面切到后台时音频还在播。背诵页的onHide里要pause()，onShow时再恢复，不然用户切出去回个消息，返回时单词都播完了，体验很怪。

4.3 现象：用户点“开始学习”后转圈两秒，第一次进入更明显

原因基本是云函数冷启动。云函数长时间没被调用，运行环境需要重新拉起，这过程普遍要几百毫秒到秒级，用户感知就是“卡”。

有两个处理方向。第一个是预热，在app.js的onLaunch里调一个轻量云函数动作，比如获取今日打卡状态，让云函数环境保持热状态；第二个是减少对云函数的依赖，公开词库的读取可以直接走客户端读云数据库，把集合权限设为“所有用户可读”，客户端wx.cloud.database()直接查，省去一次函数调用。写操作再走云函数，冷启动只影响写，不影响读，感知会弱很多。

// app.js 预热 onLaunch() { wx.cloud.callFunction({ name: 'wordService', data: { action: 'ping' } }) }

云函数里加一个case 'ping'直接返回{ code: 0 }，代码量极小，但对冷启动缓解明显。上线初期用户量不大时，这招够用。

4.4 现象：用户在另一台设备打卡后，原设备背诵，打卡天数反而回退

原因几乎必然出在同步逻辑上。常见错误是设备 A 把本地缓存的整个打卡数组原样覆盖到云端，把设备 B 刚写入的新日期冲掉了。打卡这类数据不是“以最后一次写为准”，而是“以最新日期为准”的合并。

我做的是在云端比较日期数组后合并，而不是覆盖：

// 云函数 syncCheckIn const remote = await getUserCheckIn(OPENID) const local = event.days || [] const merged = Array.from(new Set(remote.concat(local))) await saveCheckIn(OPENID, merged)

concat后Set去重，两端的日期都保留，再按升序排序。打卡日期本身是稳定字符串，这种合并不会冲突，比维护lastUpdatedAt简单可靠。核心原则就一句：用户维度的数据，合并不是覆盖。

5. 让用户真正坚持背单词：打卡、错词本和分享的三个留住功能

工具类小程序最大的问题是打开率。背单词属于“今天不做也死不了”的事，用户一旦断了三天，基本就流失了。要让用户留下，不能只靠自律，得靠产品机制。

5.1 连续打卡天数别只存一个数字：按日期快照推导更稳

很多初版设计会在用户表里放一个streak字段，每天打卡streak + 1，断了就清零。这个方案两个致命问题：无法回溯（用户申诉时你拿不出历史），无法处理时区（设备改时间直接刷爆）。

我会在用户表里存一个checkInDays数组，元素是YYYY-MM-DD格式。每天的打卡就是往数组里 push 一个日期，连续天数从数组推导出来：

// 云函数 checkIn/index.js exports.main = async (event) => { const { OPENID } = cloud.getWXContext() const now = new Date() const today = formatDate(now) const db = cloud.database() const userRef = db.collection('users').where({ _openid: OPENID }) const userRes = await userRef.get() const user = userRes.data[0] if (!user) { await db.collection('users').add({ data: { _openid: OPENID, checkInDays: [today] } }) return { code: 0, streak: 1, already: false } } const days = user.checkInDays || [] if (days.includes(today)) { return { code: 0, streak: calcStreak(days, today), already: true } } days.push(today) await userRef.update({ data: { checkInDays: days } }) return { code: 0, streak: calcStreak(days, today), already: false } } function calcStreak(days, today) { const set = new Set(days) let streak = 0 const cursor = new Date(today) while (set.has(formatDate(cursor))) { streak++ cursor.setDate(cursor.getDate() - 1) } return streak } function formatDate(d) { return `${d.getFullYear()}-${String(d.getMonth() + 1).padStart(2, '0')}-${String(d.getDate()).padStart(2, '0')}` }

already字段用来区分“今天已打卡”和“刚打卡”，前端拿到后决定是弹分享引导还是直接显示连续天数。用日期字符串而不是时间戳，是因为日期字符串按天维度做幂等判断，不会被“同一天不同毫秒数”干扰。存一整年也只有 365 个字符串，完全在单条记录可接受范围内。

5.2 错词本的权重计算：错词列表只是入口，复习队列才是核心

很多人做错词本就一个坑：把用户点过“不认识”的单词塞进一个列表，然后让用户去列表里重新背。这种做法忽略了学习曲线，全部错词一起出现，复习压力巨大。

错词本的正确形态是一个带权重的队列。每个单词根据错误次数和复习次数算出下一次出现的时间，到期才出现。用第 3 章云函数里的calcNextReview逻辑，错词会自动分散到未来几天，而不是集中砸在某一天。

复习查询的排序也很重要：

const now = Date.now() const res = await db.collection('user_progress') .where({ _openid: OPENID, nextReviewAt: _.lte(now), status: _.neq(2) }) .orderBy('nextReviewAt', 'asc') .limit(20) .get()

nextReviewAt升序排列，先到期的先背。这个查询是user_progress集合里第二高频的查询，建索引时要把_openid+status+nextReviewAt做成联合索引，不然数据量上来后这个查询会拖慢整个页面。

这里还要提一个比较隐蔽的参数：status: _.neq(2)。已经标记“掌握”的单词不应该再出现在复习队列里。但是用户如果连续三次答错同一个词，应该自动把状态从掌握降级到认识。这个降级判断放在云函数reportProgress里做，每次上报都检查errorCount，超过阈值就把status改回 1。不然会出现用户明明掌握了一个词，却再也复习不到的漏网情况。

5.3 分享卡片和邀请参数：把微信关系链拉进留存

打卡的下一步是分享。分享按钮直接用open-type="share"：

<button open-type="share">邀请好友挑战</button>

页面里实现onShareAppMessage：

// pages/index/index.js Page({ data: { streak: 0 }, onShareAppMessage() { return { title: `我已经连续背单词 ${this.data.streak} 天，敢不敢来挑战`, path: '/pages/index/index?from=share' } } })

from=share这个参数是关键。被分享人点卡片进入小程序后，onLoad的options.from能拿到share，这时候首页可以向云函数上报一条“邀请成功”的记录。后端可以据此做简单的裂变统计：谁邀请了多少人，有多少人转化成了新打卡用户。

群排行的做法要泼一盆冷水：小程序拿群信息的接口现在限制很严，非开放范围拿不到稳定的群标识，所以不要一上来就做“群排行榜”。更稳的是做“好友挑战”，分享时带上邀请人的连续天数，被分享人看到的是一个具体数字，而不是一个空洞的入口。数字本身制造压力，压力带来转化，这是背单词小程序分享链路里性价比最高的设计。

6. 上线前 20 分钟：背单词小程序检查清单，从启动速度到离线兜底一条条过

最后这个检查单不是功能清单，是我每次提审前的习惯动作。照着过一遍，能挡掉大部分真机上的低级问题。

第一，看主包大小。小程序主包上限 2MB，如果我把预置音频放进去，随便几百首 mp3 就超了，所以音频一律走云存储，页面用分包。背单词页属于次核心页面，放到分包里首屏更快：

{ "subpackages": [ { "root": "pkgStudy", "pages": ["pages/study/study"] } ] }

第二，把开发者工具切到弱网模式，进入背单词页。页面应该先出上一次的缓存卡片，再静默更新新词。如果弱网下白屏超过两秒，说明本地缓存兜底没生效，回 3.4 节检查readLocal的调用位置。

第三，真机双端各背一组词。iOS 要拨静音键测发音，确认obeyMuteSwitch已设置；Android 要测返回键退出页面时音频是否停止，避免切后台还在念单词。这一步能挡掉 4.2 节那种最典型的音频问题。

第四，在云开发控制台里核一遍数据库权限。words集合设为“所有用户可读”，user_progress和users集合保持“仅创建者可读”。权限设错了，轻则页面读取失败，重则用户数据裸奔，提审也容易被判违规。

第五，用两个微信号各背 10 个词，然后互相登录对方设备，确认打卡和复习进度是合并而非覆盖。这个测的是 4.4 节说的同步问题，虽然测起来麻烦，但一旦线上出问题，用户找回数据的成本极高。

最后说一个我的习惯：每版上线前，我会把当天刚背过的单词故意答错三次，确认错词本队列里有这个词且排在了前面。这个动作不是为了测功能，而是验证整条数据链路从页面到云函数再到复习查询都是通的。

背单词小程序的核心不是 UI 多精致，而是数据链路多可靠。用户今天背的词，明天该不该复习，后天的连续打卡算不算数，这些底层逻辑跑稳了，界面朴素一点用户也会留下来。希望帮到你。

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