提起四六级备考多数人第一反应是“背单词”而背单词这件事最怕的就是三天打鱼两天晒网。我自己大学时也用过不少单词 App功能五花八门但真到考前还是没记住几个。后来走上开发这条路就萌生了一个想法能不能自己做一个基于微信小程序的四六级词汇学习平台把词库、学习计划、测试、数据统计都装进去不用下载安装扫码就能用顺便还能把源码、文档、调试这套完整流程走一遍。这个项目从需求梳理到上线前后改了四版踩了不少坑也沉淀了一套比较完整的做法。如果你正打算做类似的小程序项目或者想找一个包含源码、文档、调试记录的实战案例参考这篇内容应该能帮你省下不少时间。整个平台的核心其实不复杂用户在微信里打开小程序选择四级或六级词库按计划每天学习一组单词系统根据记忆曲线安排复习支持单词测试、错题记录、学习进度统计。听起来简单真正做起来涉及的东西却不少——词库数据结构怎么设计、复习算法怎么定参数、前端页面怎么承载多种交互、后端接口怎么和前端对齐、真机调试时有哪些坑这些我都会在下面展开讲。1. 项目整体设计与思路拆解1.1 为什么选微信小程序而不是 App四六级词汇学习这个场景有很强的碎片化特征。用户可能在食堂排队时掏出手机刷一组单词也可能在图书馆坐下来做一套测试。小程序天然契合这种场景无需安装、打开即用、用完即走而且微信的社交关系链可以为后续的“好友对战背单词”“打卡排行榜”等功能提供天然的传播基础。相比之下原生 App 需要下载、安装、注册对备考学生来说门槛偏高。技术上微信小程序也足够支撑这种工具类项目。页面结构不复杂核心交互集中在单词卡片、列表、图表、答题界面原生小程序框架完全可以胜任。我第一版也纠结过要不要上 uni-app 或者 Taro 做跨端后来想明白一个问题目标用户就在微信生态里跨端的意义不大反而会引入一层编译转换的复杂度。用原生小程序做调试方便文档齐全遇到问题搜到的答案也更多对个人开发者来说试错成本最低。1.2 整体架构前端、后端、词库三线并行这个项目不是纯前端的小程序而是完整的前后端分离结构。我把它分成三条线第一条线是微信小程序前端负责单词展示、用户交互、本地缓存、请求后端接口。第二条线是后端服务负责词库数据管理、用户学习记录、复习计划计算、测试结果存储。第三条线是词库数据本身这是整个项目的灵魂——四六级词汇量在 4000 到 6000 左右怎么整理、怎么分类、怎么打标签直接决定了用户的学习体验。词库我最初想直接爬第三方数据后来考虑到版权和数据准确性改为人工校对加公开词表整理的方式每个单词包含拼写、音标、中文释义、例句、词频等级、考试年份标签等字段。整理词库是最枯燥但最值得投入的部分因为后续所有功能都建立在数据之上数据质量差功能做得再花哨也没用。1.3 技术选型时的对比与取舍这里有一个实际对比我当时列了一张表方案优势劣势结论原生微信小程序调试直接、文档全、性能好只能在微信生态使用选定uni-app一套代码多端发布复杂交互调试麻烦备选TaroReact 语法友好编译链条长问题排查难放弃云开发免运维、上手快数据迁移和定制能力有限部分使用自建后端可控性强、可定制算法需要服务器、域名、备案选定后端我最终选了自建 Node.js 服务搭配 MySQL 数据库。原因有两个一是复习算法和统计逻辑需要频繁调整自建服务改起来灵活二是项目做出来之后我想开源源码加文档加调试记录一起放出去自建后端对学习者来说更有参考价值。云开发虽然省事但业务逻辑和数据模型都绑在平台上别人拿去学习时很多东西看不透。2. 核心功能拆解与数据模型设计2.1 功能清单从背单词到模拟测试需求评审之后我把功能收敛成五个模块第一个是词库选择与学习计划。用户进入小程序后先选择四级还是六级词库再设定每日学习量比如每天 20 个新词系统自动计算预计完成天数并生成学习日历。第二个是单词学习卡片。这是最核心的交互页面采用卡片式布局正面显示单词和音标用户点击后翻转显示释义、例句、词根词缀。支持左滑认识、右滑不认识滑动结果实时上报后端。第三个是复习模块。基于艾宾浩斯遗忘曲线每天除了新词学习还需要完成对应的复习任务。复习队列的生成逻辑是后端计算前端只需要告诉后端“今天完成了哪些学习动作”。第四个是测试模块。包括词义选择题、拼写填空题、听音辨义三种题型。测试结束后生成成绩单错词自动进入错题本后续根据错误次数调整复习权重。第五个是个人中心与统计。展示学习天数、累计词汇量、连续打卡记录、每日学习时长用折线图和柱状图呈现趋势。2.2 词库数据结构别把字段设计得太简单词库表的设计看起来不复杂但字段多寡决定了后续扩展空间。我最终设计的单词表核心字段包括id、word、phonetic_uk、phonetic_us、definition_cn、definition_en、example_sentence、example_translation、root_affix、tags、difficulty、frequency_level、source_grade、created_at。这里特别说明一下 difficulty 和 frequency_level 两个字段。difficulty 是一个 1 到 5 的整数值代表单词的认知难度我根据词频和经验给每个单词打了初值后续用户答题正确率会反过来修正这个值。frequency_level 对应四级核心词、四级高频词、六级核心词、六级超纲词这类标签用于筛选不同的学习范围。tags 字段用逗号分隔可以标记“真题 2023 阅读”“听力高频”“写作推荐”等属性方便用户按场景过滤。2.3 学习进度与记忆状态机用户的每一个单词学习状态不是简单的“学过/没学过”而是一个状态机。我定义了五种状态未学习、学习中、已熟悉、需复习、已掌握。状态之间的迁移由两个因素驱动用户主动操作认识/不认识、答对/答错和时间因素距离上次复习的间隔。数据库里对应一张 user_word_status 表字段包括 user_id、word_id、status、review_count、error_count、last_review_at、next_review_at、memory_score。memory_score 是一个 0 到 100 的数值代表记忆强度每次复习都会更新它。这里我想特别说一句很多人做背单词功能时只记“对错”两个状态这是不够的。没有记忆强度这个连续值复习算法很难做精细调度测试题也知道该怎么选题。3. 关键模块实现与实操过程3.1 单词卡片的滑动交互实现单词卡片的滑动效果是前端最直观的体验点。小程序原生的 movable-area 和 movable-view 可以实现基本的拖动但要做到“左滑认识、右滑不认识”并且带阻尼和位移阈值判断需要自己处理触摸事件。我用 touchstart、touchmove、touchend 三个事件实现了整套交互。touchend 时判断横向位移是否超过屏幕宽度的四分之一如果超过则触发对应方向的操作。这里有一个关键参数——阻尼系数我实测下来 0.6 比较合适位移距离等于手指移动距离乘以 0.6既不会显得太肉也不会让卡片太飘。卡片翻转用的是 CSS 3D 变换微信小程序对 transform-style: preserve-3d 和 backface-visibility 的支持在基础库 2.9.0 之后已经比较完善。需要注意的一点是卡片正反面要用两个绝对定位的 view 叠加不能只给一个 view 做 180 度旋转否则内容不会跟着翻转。3.2 艾宾浩斯遗忘曲线复习算法参数怎么定复习算法是整个项目含金量最高的部分我直接说结论不要试图完全复刻论文里的复杂模型先用简化版跑通再逐步调参。我采用的是一种类 SM-2 算法核心公式是interval previous_interval × factor其中 factor 由用户本次复习的表现决定用户反应factor说明完全不记得1.0重置间隔模糊但能猜对1.5小幅延长正确但犹豫2.0正常增长快速正确2.5大幅延长第一次复习间隔固定为 1 天第二次为 3 天之后按照 above 规则计算。我设了一个上限interval 最大不超过 60 天避免单词长期不出现导致遗忘。这里有一个容易忽略的细节factor 不应该是固定值而应该根据单词的 difficulty 做修正。难度为 5 的单词即便用户答对了factor 也只取 1.5防止“一次答对就以为掌握了”。这个修正我用一个偏移量实现adjusted_factor base_factor × (1.1 - difficulty × 0.02)。数字看起来不起眼但用在一千个单词的队列上复习节奏会平滑很多。3.3 测试模块与答题逻辑测试模块的三种题型里词义选择题最容易实现拼写填空题对输入校验要求高听音辨义需要提前准备音频资源。音频资源我用了微信小程序的 wx.createInnerAudioContext 接口音频文件放在对象存储上URL 通过接口返回。拼写填空题有一个交互细节容易踩坑用户输入时要关闭拼写检查和自动纠错否则系统会把用户拼错但想要输入的单词“好心”地纠正。微信小程序的 input 组件没有直接暴露关闭自动纠错的参数我的做法是在 input 外层加 form通过 bindinput 拿到原始输入值自己做判空和字母过滤。测试结果生成时我会记录每道题的答题时长。答题时间小于 1.5 秒且答对说明这个单词可能是“瞬时记忆”我会降低它的 memory_score 涨幅答题时间大于 10 秒但答对说明单词掌握还不够牢固复习间隔会缩短。这个策略是实测之后加进去的能让错题判断更准确。3.4 个人中心与数据统计实现统计页面用到了 echarts 的微信小程序版本图表需要的不是炫酷而是信息清楚。我选择了三个图表近 30 天学习单词数柱状图、遗忘曲线拟合线图、词性掌握分布饼图。柱状图用于反馈每日学习量是否达标线图让用户直观看到自己记忆曲线和标准遗忘曲线的差距饼图帮助用户发现哪类词性是自己薄弱项。数据统计的接口设计要注意性能。前端每次进入个人中心就拉全量数据会非常慢用户学了两百天之后几十万条学习记录一次拉回来必然卡顿。我的方案是后端做聚合按天维度返回统计结果前端拿到的数据量恒定在 30 条到 90 条之间渲染速度完全没问题。这个“后端聚合、前端展示”的思路在真实项目里面对所有统计类需求几乎都适用。4. 后端服务与接口设计4.1 接口鉴权与用户身份微信小程序登录流程是标准的 wx.login 换取 code再把 code 传到后端后端通过 code 换 openid。这个过程在微信官方文档里有明确描述我提一个容易忽略的点code 是临时凭证有效期为 5 分钟且只能使用一次。开发调试时经常刷新页面如果 code 重复提交会失败前端要做好防重处理。用户表我加了两个冗余字段来提升体验nickname 和 avatar_url。用户首次登录时默认为“微信用户”和默认头像用户可以在个人中心修改。这里不做强制绑定微信昵称头像的原因是微信在 2022 年后调整了用户信息授权策略前端不能直接通过 getUserInfo 拿头像昵称必须使用头像昵称填写能力这个能力和我们自己的用户体系打通需要额外适配。4.2 核心接口定义一览整个端到端接口我梳理出了 12 个最核心的几个如下POST /api/auth/login 登录接口参数是 code返回 token 和用户信息。 GET /api/words/daily 获取今日学习单词参数是 type四级/六级、count数量返回单词列表和今日任务 ID。 POST /api/words/review 提交单词学习结果参数是 word_id、actionrecognize/unrecognize、duration返回下一个单词 ID。 GET /api/review/queue 获取今日复习队列。 POST /api/review/submit 提交复习结果参数包含 word_id、quality、duration后端计算新的 next_review_at。 POST /api/quiz/submit 提交测试答案后端返回成绩和错题列表。 GET /api/stats/overview 获取统计概览。接口设计上我遵循一个原则前端只传“发生了什么”不传“怎么处理”。比如学习结果提交前端只传 word_id 和 action至于这个 action 该怎么影响 memory_score、该安排哪天的复习全部由后端计算。这样前端逻辑简单后续调整算法时不需要发版小程序。4.3 词库数据的三层校验词库数据是项目的生命线但纯人工整理不可能保证 100% 准确。我建立了三层校验机制第一层是脚本校验写了一个 Node.js 脚本遍历词库 JSON检查必填字段是否完整、音标是否包含非法字符、释义是否为空第二层是接口校验后端启动时加载词库数据校验单词是否重复、例句是否包含目标单词第三层是用户反馈校验用户在学习界面对异常内容可以长按举报举报数据落到专门的表里定时人工处理。三层校验跑下来还是挺有用的。第一版词库里有 37 个单词的例句明显不包含目标单词本身比如例句里用的是变形词这类问题就是脚本校验跑出来的。如果不是提前做校验用户遇到这种错误数据会直接质疑平台的专业性。5. 调试实录与问题排查5.1 微信开发者工具调试的关键面板微信开发者工具的调试能力非常强但新手上手容易只看 console 面板。根据这个项目的实际调试经历我建议优先掌握三个面板第一个是 Network 面板查看请求耗时和返回数据结构。注意要用真机调试模式查看模拟器上的网络环境和真实手机差别很大。我遇到过一个问题模拟器请求只要 200 毫秒真机上却要 1.5 秒原因是在真机上走的是真实 4G 网络后端接口没有做数据压缩。后来我在后端统一加了 gzip 压缩真机耗时降到 400 毫秒。第二个是 Storage 面板查看本地缓存。小程序的缓存策略需要特别小心不能把所有数据都放本地也不能什么都不放。我的策略是词库元数据显示时优先请求接口但把最近七天的学习记录缓存在本地本地缓存作为接口失败时的兜底方案而不是数据来源。第三个是 Wxml 面板调试样式和布局。这个面板可以查看组件的最终渲染结果对于层级覆盖、fixed 定位失效这类问题能直接看到原因。5.2 真机调试与抓包技巧真机调试最烦的问题就是接口报错但在开发者工具里看不出来。这里我推荐一个小技巧用微信开发者工具的“真机调试 2.0”模式手机上打开调试页面电脑端可以看到全部 console 日志和网络请求。但有个限制真机调试时手机和电脑必须在同一局域网且手机不能走代理。如果你想看更底层的请求数据可以用抓包工具。移动端小程序抓包Charles 是常用选择。具体做法是手机和电脑连同一个 Wi-Fi手机设置 HTTP 代理指向电脑 IP端口 8888然后在 Charles 上开启 SSL Proxying安装证书到手机。这样就能看到小程序发出的每个 HTTPS 请求的具体内容包括请求头、参数、返回值。注意微信小程序的请求默认是校验域名合法性的正式域名需要在小程序后台配置 request 合法域名本地调试可以勾选“不校验合法域名”选项。5.3 我踩过的五个典型的坑调试过程中我踩了十几个坑这里挑五个最有代表性的记录下来。第一个坑是安卓端音频自动播放失败。iOS 上可以自动播放安卓上不行必须在用户 touch 事件之后调用 play。解决办法是进入听音辨义页面时弹一个“点击开始测试”的按钮用户点击后再初始化音频上下文。第二个坑是 Canvas 绘制图表在真机上模糊。原因是 canvas 的像素比没有适配需要在绘制前设置 canvas.width 为逻辑宽度乘以设备像素比也就是 windowWidth × pixelRatio绘制完再通过 style 属性把显示尺寸拉回来。第三个坑是 setData 的数据量过大导致页面卡顿。小程序 setData 是逻辑层和渲染层之间的数据传递数据量过大会引起卡顿。我一开始把完整的学习计划列表一次性 setData后来改成只传当前页可见的数据配合上拉加载卡顿问题彻底解决。第四个坑是复习队列的并发重复提交。用户快速连续点击“认识/不认识”时如果上一次请求还没返回上一次的结果就会覆盖到新一次的记录上。我加了 throttle 逻辑点击后 200 毫秒内不允许再次点击。第五个坑是时间格式化在部分安卓机型上出现 NaN。原因是 iOS 支持“2024-05-01 10:00:00”这种格式安卓部分机型只支持“2024/05/01 10:00:00”。统一用 replace 把横杠换成斜杠就解决。我去抓包调试时发现有些请求返回的 401 是因为用户 token 过期。按理说 token 过期应该静默刷新但第一版我只做了提示用户重新登录体验很差。后来加了 token 续期机制请求返回 401 时自动调用刷新接口拿到新 token 重放原请求。这个优化对连续学习场景帮助很大用户不会学着学着突然被打断。6. 部署上线与后续扩展6.1 上线流程与审核注意事项微信小程序上线前需要完成认证个人开发者也可以注册但个人主体无法开通支付、无法使用附近的店等能力。对于词汇学习平台这种纯内容工具个人主体足够用。上线审核时特别注意两点第一类目选择要选“教育 教育信息服务”第二页面里不能出现测试账号、测试数据、明显的开发提示文案。审核被拒最常见的原因是类目不一致或者页面存在测试内容。我第一版提交审核时没有注意到个人中心页还留着“管理员登录”的入口被驳回了。后来把管理员入口隐藏到未登录状态不可见的位置并调整了类目描述第二次就通过了。6.2 后续扩展方向项目跑通之后扩展的方向其实很多。可以做的第一个方向是好友学习对战微信小程序天然的社交能力是 App 比不了的。第二个方向是智能生词本根据用户的历史错误记录自动从题库中推荐适合的单词生成个性化学习包。第三个方向是真题阅读训练将历年阅读真题中的单词标注出来点击即可查看词义和加入了生词本这个功能对备考用户的价值非常大。关于这份项目的源码和文档我特别整理了完整的部署文档包括环境要求、数据库建表 SQL、后端启动步骤、小程序前端配置说明、接口文档Swagger 格式以及常见问题排查指南。文档要写得好不只是为了让别人能跑起来更是对自己项目的一次复盘——很多当时做得“顺手”的地方回过头来记录下来才发现原来有那么多隐藏的设计决策。如果是我自己拿到这份项目去学习我会建议按这个顺序入手先看文档里的运行环境和部署步骤把项目跑起来再对照接口文档逐个接口测试了解数据流然后研究复习算法的实现尝试自己改一个参数看看效果变化最后才是看前端的交互代码理解页面逻辑。调试这件事只有跑在真实环境里踩过坑才能真正变成自己的经验。
微信小程序四六级词汇学习平台：从词库设计到艾宾浩斯复习算法实战
提起四六级备考多数人第一反应是“背单词”而背单词这件事最怕的就是三天打鱼两天晒网。我自己大学时也用过不少单词 App功能五花八门但真到考前还是没记住几个。后来走上开发这条路就萌生了一个想法能不能自己做一个基于微信小程序的四六级词汇学习平台把词库、学习计划、测试、数据统计都装进去不用下载安装扫码就能用顺便还能把源码、文档、调试这套完整流程走一遍。这个项目从需求梳理到上线前后改了四版踩了不少坑也沉淀了一套比较完整的做法。如果你正打算做类似的小程序项目或者想找一个包含源码、文档、调试记录的实战案例参考这篇内容应该能帮你省下不少时间。整个平台的核心其实不复杂用户在微信里打开小程序选择四级或六级词库按计划每天学习一组单词系统根据记忆曲线安排复习支持单词测试、错题记录、学习进度统计。听起来简单真正做起来涉及的东西却不少——词库数据结构怎么设计、复习算法怎么定参数、前端页面怎么承载多种交互、后端接口怎么和前端对齐、真机调试时有哪些坑这些我都会在下面展开讲。1. 项目整体设计与思路拆解1.1 为什么选微信小程序而不是 App四六级词汇学习这个场景有很强的碎片化特征。用户可能在食堂排队时掏出手机刷一组单词也可能在图书馆坐下来做一套测试。小程序天然契合这种场景无需安装、打开即用、用完即走而且微信的社交关系链可以为后续的“好友对战背单词”“打卡排行榜”等功能提供天然的传播基础。相比之下原生 App 需要下载、安装、注册对备考学生来说门槛偏高。技术上微信小程序也足够支撑这种工具类项目。页面结构不复杂核心交互集中在单词卡片、列表、图表、答题界面原生小程序框架完全可以胜任。我第一版也纠结过要不要上 uni-app 或者 Taro 做跨端后来想明白一个问题目标用户就在微信生态里跨端的意义不大反而会引入一层编译转换的复杂度。用原生小程序做调试方便文档齐全遇到问题搜到的答案也更多对个人开发者来说试错成本最低。1.2 整体架构前端、后端、词库三线并行这个项目不是纯前端的小程序而是完整的前后端分离结构。我把它分成三条线第一条线是微信小程序前端负责单词展示、用户交互、本地缓存、请求后端接口。第二条线是后端服务负责词库数据管理、用户学习记录、复习计划计算、测试结果存储。第三条线是词库数据本身这是整个项目的灵魂——四六级词汇量在 4000 到 6000 左右怎么整理、怎么分类、怎么打标签直接决定了用户的学习体验。词库我最初想直接爬第三方数据后来考虑到版权和数据准确性改为人工校对加公开词表整理的方式每个单词包含拼写、音标、中文释义、例句、词频等级、考试年份标签等字段。整理词库是最枯燥但最值得投入的部分因为后续所有功能都建立在数据之上数据质量差功能做得再花哨也没用。1.3 技术选型时的对比与取舍这里有一个实际对比我当时列了一张表方案优势劣势结论原生微信小程序调试直接、文档全、性能好只能在微信生态使用选定uni-app一套代码多端发布复杂交互调试麻烦备选TaroReact 语法友好编译链条长问题排查难放弃云开发免运维、上手快数据迁移和定制能力有限部分使用自建后端可控性强、可定制算法需要服务器、域名、备案选定后端我最终选了自建 Node.js 服务搭配 MySQL 数据库。原因有两个一是复习算法和统计逻辑需要频繁调整自建服务改起来灵活二是项目做出来之后我想开源源码加文档加调试记录一起放出去自建后端对学习者来说更有参考价值。云开发虽然省事但业务逻辑和数据模型都绑在平台上别人拿去学习时很多东西看不透。2. 核心功能拆解与数据模型设计2.1 功能清单从背单词到模拟测试需求评审之后我把功能收敛成五个模块第一个是词库选择与学习计划。用户进入小程序后先选择四级还是六级词库再设定每日学习量比如每天 20 个新词系统自动计算预计完成天数并生成学习日历。第二个是单词学习卡片。这是最核心的交互页面采用卡片式布局正面显示单词和音标用户点击后翻转显示释义、例句、词根词缀。支持左滑认识、右滑不认识滑动结果实时上报后端。第三个是复习模块。基于艾宾浩斯遗忘曲线每天除了新词学习还需要完成对应的复习任务。复习队列的生成逻辑是后端计算前端只需要告诉后端“今天完成了哪些学习动作”。第四个是测试模块。包括词义选择题、拼写填空题、听音辨义三种题型。测试结束后生成成绩单错词自动进入错题本后续根据错误次数调整复习权重。第五个是个人中心与统计。展示学习天数、累计词汇量、连续打卡记录、每日学习时长用折线图和柱状图呈现趋势。2.2 词库数据结构别把字段设计得太简单词库表的设计看起来不复杂但字段多寡决定了后续扩展空间。我最终设计的单词表核心字段包括id、word、phonetic_uk、phonetic_us、definition_cn、definition_en、example_sentence、example_translation、root_affix、tags、difficulty、frequency_level、source_grade、created_at。这里特别说明一下 difficulty 和 frequency_level 两个字段。difficulty 是一个 1 到 5 的整数值代表单词的认知难度我根据词频和经验给每个单词打了初值后续用户答题正确率会反过来修正这个值。frequency_level 对应四级核心词、四级高频词、六级核心词、六级超纲词这类标签用于筛选不同的学习范围。tags 字段用逗号分隔可以标记“真题 2023 阅读”“听力高频”“写作推荐”等属性方便用户按场景过滤。2.3 学习进度与记忆状态机用户的每一个单词学习状态不是简单的“学过/没学过”而是一个状态机。我定义了五种状态未学习、学习中、已熟悉、需复习、已掌握。状态之间的迁移由两个因素驱动用户主动操作认识/不认识、答对/答错和时间因素距离上次复习的间隔。数据库里对应一张 user_word_status 表字段包括 user_id、word_id、status、review_count、error_count、last_review_at、next_review_at、memory_score。memory_score 是一个 0 到 100 的数值代表记忆强度每次复习都会更新它。这里我想特别说一句很多人做背单词功能时只记“对错”两个状态这是不够的。没有记忆强度这个连续值复习算法很难做精细调度测试题也知道该怎么选题。3. 关键模块实现与实操过程3.1 单词卡片的滑动交互实现单词卡片的滑动效果是前端最直观的体验点。小程序原生的 movable-area 和 movable-view 可以实现基本的拖动但要做到“左滑认识、右滑不认识”并且带阻尼和位移阈值判断需要自己处理触摸事件。我用 touchstart、touchmove、touchend 三个事件实现了整套交互。touchend 时判断横向位移是否超过屏幕宽度的四分之一如果超过则触发对应方向的操作。这里有一个关键参数——阻尼系数我实测下来 0.6 比较合适位移距离等于手指移动距离乘以 0.6既不会显得太肉也不会让卡片太飘。卡片翻转用的是 CSS 3D 变换微信小程序对 transform-style: preserve-3d 和 backface-visibility 的支持在基础库 2.9.0 之后已经比较完善。需要注意的一点是卡片正反面要用两个绝对定位的 view 叠加不能只给一个 view 做 180 度旋转否则内容不会跟着翻转。3.2 艾宾浩斯遗忘曲线复习算法参数怎么定复习算法是整个项目含金量最高的部分我直接说结论不要试图完全复刻论文里的复杂模型先用简化版跑通再逐步调参。我采用的是一种类 SM-2 算法核心公式是interval previous_interval × factor其中 factor 由用户本次复习的表现决定用户反应factor说明完全不记得1.0重置间隔模糊但能猜对1.5小幅延长正确但犹豫2.0正常增长快速正确2.5大幅延长第一次复习间隔固定为 1 天第二次为 3 天之后按照 above 规则计算。我设了一个上限interval 最大不超过 60 天避免单词长期不出现导致遗忘。这里有一个容易忽略的细节factor 不应该是固定值而应该根据单词的 difficulty 做修正。难度为 5 的单词即便用户答对了factor 也只取 1.5防止“一次答对就以为掌握了”。这个修正我用一个偏移量实现adjusted_factor base_factor × (1.1 - difficulty × 0.02)。数字看起来不起眼但用在一千个单词的队列上复习节奏会平滑很多。3.3 测试模块与答题逻辑测试模块的三种题型里词义选择题最容易实现拼写填空题对输入校验要求高听音辨义需要提前准备音频资源。音频资源我用了微信小程序的 wx.createInnerAudioContext 接口音频文件放在对象存储上URL 通过接口返回。拼写填空题有一个交互细节容易踩坑用户输入时要关闭拼写检查和自动纠错否则系统会把用户拼错但想要输入的单词“好心”地纠正。微信小程序的 input 组件没有直接暴露关闭自动纠错的参数我的做法是在 input 外层加 form通过 bindinput 拿到原始输入值自己做判空和字母过滤。测试结果生成时我会记录每道题的答题时长。答题时间小于 1.5 秒且答对说明这个单词可能是“瞬时记忆”我会降低它的 memory_score 涨幅答题时间大于 10 秒但答对说明单词掌握还不够牢固复习间隔会缩短。这个策略是实测之后加进去的能让错题判断更准确。3.4 个人中心与数据统计实现统计页面用到了 echarts 的微信小程序版本图表需要的不是炫酷而是信息清楚。我选择了三个图表近 30 天学习单词数柱状图、遗忘曲线拟合线图、词性掌握分布饼图。柱状图用于反馈每日学习量是否达标线图让用户直观看到自己记忆曲线和标准遗忘曲线的差距饼图帮助用户发现哪类词性是自己薄弱项。数据统计的接口设计要注意性能。前端每次进入个人中心就拉全量数据会非常慢用户学了两百天之后几十万条学习记录一次拉回来必然卡顿。我的方案是后端做聚合按天维度返回统计结果前端拿到的数据量恒定在 30 条到 90 条之间渲染速度完全没问题。这个“后端聚合、前端展示”的思路在真实项目里面对所有统计类需求几乎都适用。4. 后端服务与接口设计4.1 接口鉴权与用户身份微信小程序登录流程是标准的 wx.login 换取 code再把 code 传到后端后端通过 code 换 openid。这个过程在微信官方文档里有明确描述我提一个容易忽略的点code 是临时凭证有效期为 5 分钟且只能使用一次。开发调试时经常刷新页面如果 code 重复提交会失败前端要做好防重处理。用户表我加了两个冗余字段来提升体验nickname 和 avatar_url。用户首次登录时默认为“微信用户”和默认头像用户可以在个人中心修改。这里不做强制绑定微信昵称头像的原因是微信在 2022 年后调整了用户信息授权策略前端不能直接通过 getUserInfo 拿头像昵称必须使用头像昵称填写能力这个能力和我们自己的用户体系打通需要额外适配。4.2 核心接口定义一览整个端到端接口我梳理出了 12 个最核心的几个如下POST /api/auth/login 登录接口参数是 code返回 token 和用户信息。 GET /api/words/daily 获取今日学习单词参数是 type四级/六级、count数量返回单词列表和今日任务 ID。 POST /api/words/review 提交单词学习结果参数是 word_id、actionrecognize/unrecognize、duration返回下一个单词 ID。 GET /api/review/queue 获取今日复习队列。 POST /api/review/submit 提交复习结果参数包含 word_id、quality、duration后端计算新的 next_review_at。 POST /api/quiz/submit 提交测试答案后端返回成绩和错题列表。 GET /api/stats/overview 获取统计概览。接口设计上我遵循一个原则前端只传“发生了什么”不传“怎么处理”。比如学习结果提交前端只传 word_id 和 action至于这个 action 该怎么影响 memory_score、该安排哪天的复习全部由后端计算。这样前端逻辑简单后续调整算法时不需要发版小程序。4.3 词库数据的三层校验词库数据是项目的生命线但纯人工整理不可能保证 100% 准确。我建立了三层校验机制第一层是脚本校验写了一个 Node.js 脚本遍历词库 JSON检查必填字段是否完整、音标是否包含非法字符、释义是否为空第二层是接口校验后端启动时加载词库数据校验单词是否重复、例句是否包含目标单词第三层是用户反馈校验用户在学习界面对异常内容可以长按举报举报数据落到专门的表里定时人工处理。三层校验跑下来还是挺有用的。第一版词库里有 37 个单词的例句明显不包含目标单词本身比如例句里用的是变形词这类问题就是脚本校验跑出来的。如果不是提前做校验用户遇到这种错误数据会直接质疑平台的专业性。5. 调试实录与问题排查5.1 微信开发者工具调试的关键面板微信开发者工具的调试能力非常强但新手上手容易只看 console 面板。根据这个项目的实际调试经历我建议优先掌握三个面板第一个是 Network 面板查看请求耗时和返回数据结构。注意要用真机调试模式查看模拟器上的网络环境和真实手机差别很大。我遇到过一个问题模拟器请求只要 200 毫秒真机上却要 1.5 秒原因是在真机上走的是真实 4G 网络后端接口没有做数据压缩。后来我在后端统一加了 gzip 压缩真机耗时降到 400 毫秒。第二个是 Storage 面板查看本地缓存。小程序的缓存策略需要特别小心不能把所有数据都放本地也不能什么都不放。我的策略是词库元数据显示时优先请求接口但把最近七天的学习记录缓存在本地本地缓存作为接口失败时的兜底方案而不是数据来源。第三个是 Wxml 面板调试样式和布局。这个面板可以查看组件的最终渲染结果对于层级覆盖、fixed 定位失效这类问题能直接看到原因。5.2 真机调试与抓包技巧真机调试最烦的问题就是接口报错但在开发者工具里看不出来。这里我推荐一个小技巧用微信开发者工具的“真机调试 2.0”模式手机上打开调试页面电脑端可以看到全部 console 日志和网络请求。但有个限制真机调试时手机和电脑必须在同一局域网且手机不能走代理。如果你想看更底层的请求数据可以用抓包工具。移动端小程序抓包Charles 是常用选择。具体做法是手机和电脑连同一个 Wi-Fi手机设置 HTTP 代理指向电脑 IP端口 8888然后在 Charles 上开启 SSL Proxying安装证书到手机。这样就能看到小程序发出的每个 HTTPS 请求的具体内容包括请求头、参数、返回值。注意微信小程序的请求默认是校验域名合法性的正式域名需要在小程序后台配置 request 合法域名本地调试可以勾选“不校验合法域名”选项。5.3 我踩过的五个典型的坑调试过程中我踩了十几个坑这里挑五个最有代表性的记录下来。第一个坑是安卓端音频自动播放失败。iOS 上可以自动播放安卓上不行必须在用户 touch 事件之后调用 play。解决办法是进入听音辨义页面时弹一个“点击开始测试”的按钮用户点击后再初始化音频上下文。第二个坑是 Canvas 绘制图表在真机上模糊。原因是 canvas 的像素比没有适配需要在绘制前设置 canvas.width 为逻辑宽度乘以设备像素比也就是 windowWidth × pixelRatio绘制完再通过 style 属性把显示尺寸拉回来。第三个坑是 setData 的数据量过大导致页面卡顿。小程序 setData 是逻辑层和渲染层之间的数据传递数据量过大会引起卡顿。我一开始把完整的学习计划列表一次性 setData后来改成只传当前页可见的数据配合上拉加载卡顿问题彻底解决。第四个坑是复习队列的并发重复提交。用户快速连续点击“认识/不认识”时如果上一次请求还没返回上一次的结果就会覆盖到新一次的记录上。我加了 throttle 逻辑点击后 200 毫秒内不允许再次点击。第五个坑是时间格式化在部分安卓机型上出现 NaN。原因是 iOS 支持“2024-05-01 10:00:00”这种格式安卓部分机型只支持“2024/05/01 10:00:00”。统一用 replace 把横杠换成斜杠就解决。我去抓包调试时发现有些请求返回的 401 是因为用户 token 过期。按理说 token 过期应该静默刷新但第一版我只做了提示用户重新登录体验很差。后来加了 token 续期机制请求返回 401 时自动调用刷新接口拿到新 token 重放原请求。这个优化对连续学习场景帮助很大用户不会学着学着突然被打断。6. 部署上线与后续扩展6.1 上线流程与审核注意事项微信小程序上线前需要完成认证个人开发者也可以注册但个人主体无法开通支付、无法使用附近的店等能力。对于词汇学习平台这种纯内容工具个人主体足够用。上线审核时特别注意两点第一类目选择要选“教育 教育信息服务”第二页面里不能出现测试账号、测试数据、明显的开发提示文案。审核被拒最常见的原因是类目不一致或者页面存在测试内容。我第一版提交审核时没有注意到个人中心页还留着“管理员登录”的入口被驳回了。后来把管理员入口隐藏到未登录状态不可见的位置并调整了类目描述第二次就通过了。6.2 后续扩展方向项目跑通之后扩展的方向其实很多。可以做的第一个方向是好友学习对战微信小程序天然的社交能力是 App 比不了的。第二个方向是智能生词本根据用户的历史错误记录自动从题库中推荐适合的单词生成个性化学习包。第三个方向是真题阅读训练将历年阅读真题中的单词标注出来点击即可查看词义和加入了生词本这个功能对备考用户的价值非常大。关于这份项目的源码和文档我特别整理了完整的部署文档包括环境要求、数据库建表 SQL、后端启动步骤、小程序前端配置说明、接口文档Swagger 格式以及常见问题排查指南。文档要写得好不只是为了让别人能跑起来更是对自己项目的一次复盘——很多当时做得“顺手”的地方回过头来记录下来才发现原来有那么多隐藏的设计决策。如果是我自己拿到这份项目去学习我会建议按这个顺序入手先看文档里的运行环境和部署步骤把项目跑起来再对照接口文档逐个接口测试了解数据流然后研究复习算法的实现尝试自己改一个参数看看效果变化最后才是看前端的交互代码理解页面逻辑。调试这件事只有跑在真实环境里踩过坑才能真正变成自己的经验。