1. 项目概述与需求拆解1.1 这个项目到底要解决什么问题每年考前两个月我都能在校园论坛和编程群里看到大量求助帖要么是四六级单词书太厚背不完要么是背了忘、忘了背、打开手机刷会儿短视频一天就过去了。我之前帮一个学弟做毕业设计的时候他也提到类似困扰最后我们立项做了这个“Python小程序后端 多端前端壳”的英语单词助手。说白了这就是一个帮你把背词这件事变得精准、可量化、带点强迫性质的效率工具。它定位不是像百词斩那样的大而全商业产品而是围绕“四六级真题高频词”做深度记忆管理的助手。核心功能围绕三个词背词、复习、进度追踪。技术上用的是Python做后端算法和数据处理前端使用跨端框架封装成微信小程序和APP壳。这篇博文适合两类人看一类是还在背四六级单词但觉得效率低下的学生想了解一个工具是怎么帮你规划记忆的另一类是有Python基础、想做一个完整的练习项目、从零开始写一个真实应用的开发者。我尽量把接口设计、算法逻辑、踩坑记录都写出来你们照着敲就能跑起来。1.2 为什么选Python做核心而不是其他语言先说结论这个项目里真正难的部分不是UI是词库处理、遗忘算法调度和接口服务而这三块恰好是Python的强项。词库处理需要处理大量文本清洗、词频统计、音标和例句组合Python的字符串处理能力和丰富的库比如jieba分词、pandas数据整理能让我在一晚上就完成从原始词表到结构化词条的加工。如果用Java写同样的数据处理代码量至少多一倍。遗忘曲线调度算法需要频繁操作时间戳、计算日期差、生成任务序列Python的datetime和内置逻辑太顺滑了。而且产品定位是轻量级工具不需要高并发撑起百万用户Python在后端性能上完全够用还能省下大量的编译和部署成本。前端选型上我没有直接用Python写APP界面因为Python做移动端UI比如Kivy的体验和生态都相对小众实际跑起来卡顿明显。我采用的是“Python后端 uni-app前端”的组合方式Python侧只负责业务逻辑、数据和算法前端通过HTTP接口调用这样既能发挥Python的特长又避免了在移动UI上跟Python的短板较劲。这种方式也是目前个人开发者做跨端工具很常见的思路。1.3 整体技术路线和系统架构我把整个系统分成三块来看每一块职责非常分明数据层SQLite数据库存储单词、用户信息、复习记录。开发阶段用SQLite零配置部署到服务器后再迁移MySQL也不麻烦。算法服务层Python写核心的遗忘曲线调度、每日任务生成、单词推荐逻辑对外暴露一组RESTful API。表现层微信小程序和APP共用一套前后端分离代码。利用uni-app框架同时编译到微信小程序、H5和Android iOS端最大化复用。整个数据流是这样的用户前端点击“开始学习” - 请求后端获取当日单词列表 - 后端根据用户的记忆参数计算要推送哪些词 - 前端展示单词卡片 - 用户点击“认识”或“模糊” - 前端把结果回传后端 - 后端更新记忆参数并安排下一轮复习时间。这样的架构有一个好处算法和数据是核心资产可以随时更换前端今天挂小程序明天挂APP甚至以后做Web端Python服务端完全不用动。对初学者来说这也是很好的练手项目每一块的边界都很清晰不会学着学着就一锅粥。2. 词库构建与核心记忆算法的设计逻辑2.1 词库数据从哪来、怎么清洗成标准结构我做词库时没有用那种几千页的全量词典而是聚焦真题高频词。原则是优先搞到真实考试出现频次高的词而不是按字母表顺序背一本词汇书。我当时从几个公开的学习资源站下载了四六级历年真题的词汇表格式有txt也有excel里面包含单词、音标、中文释义部分词条带例句。这些文件非常杂乱有的行出现乱码有的释义里混着多个学科意思有的词重复出现。我用Python写了一个清洗脚本做三件事统一编码把所有乱码字符过滤掉统一转成UTF-8。去重和排序按频次倒序排列把同一个词不同时态比如run/ran/running统一归并到原型。补全必要字段缺失音标或短语释义的词条调用一个免费的词典API去补充。清洗后的词条结构我是这样定义的word_id自增主键方便关联用户记录。word_text单词本体比如abandon。phonetic音标没有就填空。meaning_cn中文释义我只保留在四六级语境下最常用的两个意思避免释义过长干扰记忆。example_sentence真题例句没有例句的用短例句替代。这一步对记忆效果影响极大干巴巴背单词的遗忘速度远远高于带语境背单词。frequency真题出现次数作为后续任务派发的权重依据。我把清洗后的数据导成了一个JSON文件。第一版词库大约收录了四级核心词2300个、六级核心词1800个完全覆盖真题高频区间。实际使用中这个量级对个人工具足够背完已经是滚瓜烂熟的状态。2.2 记忆算法不是简单按顺序背而是按遗忘曲线推这是整个项目里最核心的技术点。我用的是一套简化的艾宾浩斯遗忘曲线调度策略它模拟了人对记忆的遗忘速率刚学过的知识在20分钟后忘记40%左右一天后忘记70%左右所以复习节奏必须是“短频快”起步然后逐步拉长间隔。在代码层面我为每个用户和每个单词之间维护一套记忆参数repetitions这个单词已经被正确回忆的次数。interval当前距离下次复习的时间间隔天。ease_factor难度系数初始值是2.5回答越熟练值越高下次间隔就越长。next_review_time下一次该复习的时间戳。每做完一次测试“认识”和“模糊”对参数的影响完全不同。如果是认识repetitions加1interval按公式增长第一次间隔1天第二次3天第三次7天逐步放大ease_factor微调提升如果模糊或完全忘了repetitions直接归零interval回到1天单词会重新进入短期密集复习队列并且进入“待强化清单”我每天额外安排10个这种词混进当日任务里。实际设计每日任务队列时我用了优先级排序规则是所有next_review_time早于当前时间的单词必须进入今天的复习队列。新词每天最多安排20个优先安排真题频次高的词。系统会控制今天总单词量上限在60个左右防止用户产生畏难心理直接弃用。这套算法逻辑写起来不复杂核心代码就几十行但效果比那种“每天固定背20个、按列表顺序翻页”的老式背词法好太多。它确保了每个单词在你快要忘掉的时候“恰到好处”地出现在你眼前。2.3 记忆算法的核心实现代码示例下面这段代码是任务生成和参数更新的核心我做了简化但逻辑是完整的你们可以直接跑import datetime import json class MemorizationEngine: def __init__(self, user_id): self.user_id user_id # 每个用户维护一份记忆参数实际开发存数据库这里为演示用字典 self.memory_map {} self.load_user_memory() def load_user_memory(self): # 从数据库或文件读取该用户的记忆记录 pass def next_interval(self, repetitions): # 简化的间隔计算第1次复习隔1天第2次隔2天之后按2的指数增长 if repetitions 0: return 1 elif repetitions 1: return 2 else: return min(2 ** (repetitions - 1), 30) def update_after_review(self, word_id, is_familiar): current self.memory_map.get(word_id, {repetitions: 0, interval: 1, next_review_time: None}) if is_familiar: current[repetitions] 1 current[interval] self.next_interval(current[repetitions]) else: current[repetitions] 0 current[interval] 1 current[next_review_time] ( datetime.datetime.now() datetime.timedelta(dayscurrent[interval]) ).strftime(%Y-%m-%d %H:%M:%S) self.memory_map[word_id] current self.save_user_memory() def get_today_tasks(self, word_list, new_word_count20, daily_limit60): # 先把到期的复习词拉出来 now_str datetime.datetime.now().strftime(%Y-%m-%d %H:%M:%S) review_tasks [ wid for wid, mem in self.memory_map.items() if mem[next_review_time] and mem[next_review_time] now_str ] # 再补上新词直到达到每日上限 new_tasks [ item[word_id] for item in word_list if item[word_id] not in self.memory_map ][:new_word_count] total_tasks review_tasks new_tasks if len(total_tasks) daily_limit: # 如果复习词太多优先保证复习新词顺延到明天 total_tasks review_tasks[:daily_limit] return total_tasks这里面的一个关键点在于update_after_review决定了每个单词未来的出现间隔。用生活化例子解释这就像一个养花的人对不同植物设置了不同的浇水频率有的花三天浇一次有的花一周浇一次系统精确记录每盆花的状态到时间自动提醒而不会所有花一把抓地每天浇水。3. 基于Python的后端服务与接口设计3.1 选FastAPI还是Flask我的理由写这个项目后端时我在Flask和FastAPI之间犹豫过一阵。Flask更简单、上手快我最早做练习时就用它写过留言板。但考虑到这个项目的实际需求——需要异步处理用户并发请求、需要自动生成接口文档方便前端同学对接、需要对参数进行校验——我最后选了FastAPI。FastAPI对现代Python特性支持好自带OpenAPI接口文档调试的时候浏览器打开/docs就能看到所有接口和参数格式前端开发可以省掉大量来回沟通的时间。对个人项目来说这一点体验提升很明显。安装命令很简单pip install fastapi uvicorn sqlalchemy运行服务时我用的是uvicorn main:app --host 0.0.0.0 --port 8000这样手机和其他设备也能通过局域网IP访问到服务。3.2 核心API接口设计我设计的接口不多就四个核心端点前端只需要会这几个就能跑起来。POST /api/login接收前端传的openid或者用户名完成注册或登录返回一个user_id。我第一版没有做复杂的JWT鉴权直接返回user_id方便开发和调试。GET /api/word/daily?user_idxxx获取某用户当天的单词任务列表。返回内容包含单词本体内核、音标、释义、例句以及每个单词的复习状态。POST /api/review接收用户复习单词后的反馈参数是user_id、word_id、is_familiar布尔值表示认识或模糊。这个接口会调用记忆引擎更新参数。GET /api/progress?user_idxxx返回用户的整体学习进度包括已学单词数、掌握率、连续打卡天数。我遇到一个问题有的前端同学反馈说列表接口返回的字段太多了朋友的小程序端和APP端对数据结构的期望不完全一致。后来我统一把接口返回格式规范成这种结构{ code: 0, message: success, data: { task_list: [], review_count: 10, new_word_count: 5 } }前端只需要判断code是否为0然后直接取data字段用这比返回裸JSON要规范得多也方便后续增加错误码和提示信息。3.3 数据库表结构怎么设计才算合理数据库我用的是SQLite起步设计了三张表逻辑非常清晰。words表存词库静态数据word_id、word_text、phonetic、meaning_cn、example_sentence、frequency。这张表基本只做查询不频繁更新。users表存用户基础信息user_id、nickname、created_at。第三张表是灵魂表review_records它记录每个用户和每个单词之间的交互历史字段包括record_id、user_id、word_id、is_familiar、review_time、interval_days。每次用户点击“认识”或“模糊”就往这张表里插一条记录。为什么单独建这个表而不是把所有信息塞进用户表因为后期我要看学习趋势曲线比如某用户这周掌握率是70%上周是50%有了原始数据才能做出统计分析。如果只存最新的记忆参数历史趋势全丢了无法评估学习效果。我给review_records表的user_id和review_time字段加了索引后续查询量大了之后这个优化很重要。没有索引时用户连续学习一个月后查询今天任务的SQL会越来越慢我当时被这个问题困扰过半天加完索引直接快了20多倍。4. 前端小程序与APP壳的实现与对接4.1 前端页面结构和核心交互设计前端我用的是uni-app写完一套代码可以同时构建微信小程序、H5和Android/iOS平台。说实话不同端之间会有一些细节差异但核心页面逻辑完全能共用。界面设计我参考了那些做得好的背词产品总共设计了四个主要页面首页今日任务卡片顶部显示连续打卡天数和今日目标词数中间是一个大卡片显示单词和音标点击翻面显示释义和例句下方两个按钮分别是“认识”和“模糊”。复习日历页用日历形式展示最近30天的复习量让用户直观看到自己每天背了什么哪天断了。单词列表页展示所有已学单词按掌握程度排序点开可以查看详细释义和记忆状态。我的页面显示总体进度、正确率和设置选项。页面数量不多但每一个都要做到信息密度合理。比如今日任务卡片我特意没有设置太多花哨的转场效果因为背单词核心场景是快速过卡花哨动画反而拖慢节奏。4.2 前端如何正确调用后端接口前端对接是新手最容易出错的地方主要集中在网络请求这块。我用uni-app封装了一个简单的request.js文件核心逻辑是设置基础URL和超时时间并统一处理后端返回的code状态。基础URL在开发阶段我把手机和电脑设在同一局域网直接填电脑的IP比如http://192.168.1.100:8000。部署上线后再把域名填到这里。一个我必须提醒的坑小程序模式里不能直接请求http://明文协议的地址。在微信小程序官方规定中请求必须走HTTPS或是已在后台配置的合法白名单域名。因此本地开发时我是在开发者工具里勾选了“不校验合法域名”选项真机调试时会暂时关闭该功能。等部署到云服务器之后我配置了HTTPS证书正式环境就不存在这个问题。APP端相对宽松可以走HTTP明文协议但建议上线时也换HTTPS否则一些应用商店审核可能会卡壳。前端向/api/review提交反馈的核心逻辑是这样的submitReview(wordId, isFamiliar) { uni.request({ url: getApp().globalData.baseUrl /api/review, method: POST, data: { user_id: this.userId, word_id: wordId, is_familiar: isFamiliar }, success: (res) { if (res.data.code 0) { this.loadNextWord(); } else { uni.showToast({ title: 提交失败请重试, icon: none }); } }, fail: () { uni.showToast({ title: 网络错误, icon: none }); } }); }这个请求方法里的loadNextWord会调用下一个单词的加载逻辑。我注意到不少新手会把单词切换逻辑放在前端本地下一张卡片直接从当前列表读取这样会导致一个问题如果用户中途退出前端本地状态还没同步到后端下次打开就会重复显示已背过的词。所以我特意让前端始终以后端返回的task_list为准每次刷新都重新获取避免状态不一致。4.3 编译与多端适配的注意点用uni-app开发时每个平台都有各自的坑。我整理了一下微信小程序端样式百分比布局需要测试因为有些机型屏幕宽度不同卡片太长会被截断。建议核心卡片使用rpx单位。APP端真机调试需要安装HBuilderX打包工具调试时用USB连接比较稳定。我第一次用WiFi连接真机调试时经常出现请求超时后来改为USB连接就解决了。H5端如果只是做预览H5比较方便但要注意跨域问题需要在后端加上跨域响应头。我比较推荐先把小程序端调通再去适配其他端。因为小程序审核和测试流程最标准化而且现在用户使用场景也最广泛。APP壳我是在小程序稳定之后才打包测试的省去了很多同时排查多端问题的麻烦。5. 部署细化与实战问题排查清单5.1 本地局域网调试真实记录我第一阶段做的是局域网调试。电脑上运行uvicorn服务手机装好打包出来的小程序开发版或APP测试包通过局域网连接电脑的8000端口。这一步常见的故障有几种后端启动时绑定了127.0.0.1手机根本访问不到。解决方法是启动参数写--host 0.0.0.0。电脑防火墙拦截了8000端口的入站请求。需要在防火墙的高级设置里添加入站规则允许Python进程通过或者临时关闭防火墙测试阶段可行正式环境不建议。手机和电脑不在同一网段。如果一个是公司网络一个是手机热点那自然连不上需要都接入同一个路由器或热点。5.2 常见问题排查速查表我把开发到上线过程中遇到的典型问题整理成了清单新同学直接对照查就能解决大部分问题。问题现象可能原因解决方案小程序真机预览白屏HTTPS域名未配置小程序后台配置合法域名使用云开发环境或购买HTTPS证书后端收到请求但前端总是超时CORS跨域未配置FastAPI中添加CORSMiddleware允许指定来源点击“认识”后单词不刷新前端本地列表索引混乱改用后端接口返回的task_id当作唯一键复习日历显示天数不对时区问题前端发送当前时间戳后端统一转成北京时间处理用户登录后学习记录丢失Unicode字符串匹配不一致前端传的openid和后端记录的是同一条数据确保编码一致每日任务数量不对记忆引擎参数未初始化检查memory_map中是否缺少默认值初始化逻辑5.3 部署到云服务器的一些建议当项目从本地搬到云服务器后有几个事情必须做数据持久化和稳定运行。我用的是最基础的方式购买一台云服务器配置1核2G足够了把代码通过git上传到服务器然后安装Python环境和依赖包。我用的是Caddy或Nginx做反向代理把域名流量转发到本地的8000端口。这样外部用户走HTTPS域名访问不再需要暴露门的底层IP。后端进程的管理我用的是supervisor好处是服务崩溃后会自动重启还能统一查看日志。不要把uvicorn直接用nohup后台挂着万一进程被系统杀掉你就得手动重启非常麻烦。数据库方面SQLite在几百个用户量级是完全够用的我的最大并发测试到50人同时使用时无压力。如果以后真的要扩展到更大用户量可以平滑迁移到MySQL。全局搜一遍代码中所有关于sqlite3的操作换成mysql.connector或者ORM改动成本并不高。6. 体验优化与功能扩展的个人心得6.1 用户反馈是优化的一手素材项目上线后我最深刻的印象来自一批真实用户的反馈。有个同学跟我说她看到单词卡片上有例句之后记忆速度明显变快了因为生词一旦放到具体的真题句子里就变得立体了。受这个启发我把例句展示放在了比释义更靠前的位置。还有一个用户反馈说每天60个词上限还是有点多背到40个时已经开始“瞟一眼就当认识”。我后来把对话改成在学习过程中检测正确率如果用户连续5个词都选择“认识”系统会弹出确认提示“你确实认识这个词吗”这很大程度上拦截了“假熟”现象。6.2 功能扩展的几个方向如果你们想在这个项目基础上继续做深我有几个明确可落地的思路增加听力模式调用Python的文本转语音库生成单词和例句的音频前端播放做成“听音拼词”模式对四六级听力板块帮助很大。增加数据可视化把用户的学习曲线用图表展示今天学了多少、预测多久以后会遗忘这对用户粘性提升非常明显。增加社交模块PK背词正确率、好友周榜等功能。技术难度不高但能大幅增加复购和活跃。我个人最推荐先做数据可视化因为我的后端已经有了review_records表中的历史数据差的只是前端图表库和几个统计接口。这块做出来产品整体质感会提升一大截。6.3 最后再分享两个小技巧第一个是给多用例的关键永远不要让用户感觉在填表。我在记录用户学习交互时只留了两个按钮不做复杂的自定义用户不需要选择“模糊认识是百分之多少”。一旦交互变重人就会产生负担背词这个行为本身就容易放弃再增加这种“学习成本”就完全违背了产品初衷。第二个是在实际开发中怎么处理Python后端的并发问题。FastAPI天然支持异步我在/api/review接口里用了async定义协程这样即使多个用户同时提交复习记录后端也不会阻塞。数据库连接操作要注意不要用同步阻塞的写法优先选异步驱动的库否则性能瓶颈很容易卡在数据库操作上。这个项目整体做完对我来说最大的收获是明白了一个道理工具类产品功能不需要多但每一个环节都要对准用户的实际痛点。能不能在用户快要遗忘时及时推回这个词用户体验差距非常大。如果有同学用我这套架构做得更好欢迎一起交流改进。
Python+遗忘曲线：从零构建四六级高频词记忆小程序后端
1. 项目概述与需求拆解1.1 这个项目到底要解决什么问题每年考前两个月我都能在校园论坛和编程群里看到大量求助帖要么是四六级单词书太厚背不完要么是背了忘、忘了背、打开手机刷会儿短视频一天就过去了。我之前帮一个学弟做毕业设计的时候他也提到类似困扰最后我们立项做了这个“Python小程序后端 多端前端壳”的英语单词助手。说白了这就是一个帮你把背词这件事变得精准、可量化、带点强迫性质的效率工具。它定位不是像百词斩那样的大而全商业产品而是围绕“四六级真题高频词”做深度记忆管理的助手。核心功能围绕三个词背词、复习、进度追踪。技术上用的是Python做后端算法和数据处理前端使用跨端框架封装成微信小程序和APP壳。这篇博文适合两类人看一类是还在背四六级单词但觉得效率低下的学生想了解一个工具是怎么帮你规划记忆的另一类是有Python基础、想做一个完整的练习项目、从零开始写一个真实应用的开发者。我尽量把接口设计、算法逻辑、踩坑记录都写出来你们照着敲就能跑起来。1.2 为什么选Python做核心而不是其他语言先说结论这个项目里真正难的部分不是UI是词库处理、遗忘算法调度和接口服务而这三块恰好是Python的强项。词库处理需要处理大量文本清洗、词频统计、音标和例句组合Python的字符串处理能力和丰富的库比如jieba分词、pandas数据整理能让我在一晚上就完成从原始词表到结构化词条的加工。如果用Java写同样的数据处理代码量至少多一倍。遗忘曲线调度算法需要频繁操作时间戳、计算日期差、生成任务序列Python的datetime和内置逻辑太顺滑了。而且产品定位是轻量级工具不需要高并发撑起百万用户Python在后端性能上完全够用还能省下大量的编译和部署成本。前端选型上我没有直接用Python写APP界面因为Python做移动端UI比如Kivy的体验和生态都相对小众实际跑起来卡顿明显。我采用的是“Python后端 uni-app前端”的组合方式Python侧只负责业务逻辑、数据和算法前端通过HTTP接口调用这样既能发挥Python的特长又避免了在移动UI上跟Python的短板较劲。这种方式也是目前个人开发者做跨端工具很常见的思路。1.3 整体技术路线和系统架构我把整个系统分成三块来看每一块职责非常分明数据层SQLite数据库存储单词、用户信息、复习记录。开发阶段用SQLite零配置部署到服务器后再迁移MySQL也不麻烦。算法服务层Python写核心的遗忘曲线调度、每日任务生成、单词推荐逻辑对外暴露一组RESTful API。表现层微信小程序和APP共用一套前后端分离代码。利用uni-app框架同时编译到微信小程序、H5和Android iOS端最大化复用。整个数据流是这样的用户前端点击“开始学习” - 请求后端获取当日单词列表 - 后端根据用户的记忆参数计算要推送哪些词 - 前端展示单词卡片 - 用户点击“认识”或“模糊” - 前端把结果回传后端 - 后端更新记忆参数并安排下一轮复习时间。这样的架构有一个好处算法和数据是核心资产可以随时更换前端今天挂小程序明天挂APP甚至以后做Web端Python服务端完全不用动。对初学者来说这也是很好的练手项目每一块的边界都很清晰不会学着学着就一锅粥。2. 词库构建与核心记忆算法的设计逻辑2.1 词库数据从哪来、怎么清洗成标准结构我做词库时没有用那种几千页的全量词典而是聚焦真题高频词。原则是优先搞到真实考试出现频次高的词而不是按字母表顺序背一本词汇书。我当时从几个公开的学习资源站下载了四六级历年真题的词汇表格式有txt也有excel里面包含单词、音标、中文释义部分词条带例句。这些文件非常杂乱有的行出现乱码有的释义里混着多个学科意思有的词重复出现。我用Python写了一个清洗脚本做三件事统一编码把所有乱码字符过滤掉统一转成UTF-8。去重和排序按频次倒序排列把同一个词不同时态比如run/ran/running统一归并到原型。补全必要字段缺失音标或短语释义的词条调用一个免费的词典API去补充。清洗后的词条结构我是这样定义的word_id自增主键方便关联用户记录。word_text单词本体比如abandon。phonetic音标没有就填空。meaning_cn中文释义我只保留在四六级语境下最常用的两个意思避免释义过长干扰记忆。example_sentence真题例句没有例句的用短例句替代。这一步对记忆效果影响极大干巴巴背单词的遗忘速度远远高于带语境背单词。frequency真题出现次数作为后续任务派发的权重依据。我把清洗后的数据导成了一个JSON文件。第一版词库大约收录了四级核心词2300个、六级核心词1800个完全覆盖真题高频区间。实际使用中这个量级对个人工具足够背完已经是滚瓜烂熟的状态。2.2 记忆算法不是简单按顺序背而是按遗忘曲线推这是整个项目里最核心的技术点。我用的是一套简化的艾宾浩斯遗忘曲线调度策略它模拟了人对记忆的遗忘速率刚学过的知识在20分钟后忘记40%左右一天后忘记70%左右所以复习节奏必须是“短频快”起步然后逐步拉长间隔。在代码层面我为每个用户和每个单词之间维护一套记忆参数repetitions这个单词已经被正确回忆的次数。interval当前距离下次复习的时间间隔天。ease_factor难度系数初始值是2.5回答越熟练值越高下次间隔就越长。next_review_time下一次该复习的时间戳。每做完一次测试“认识”和“模糊”对参数的影响完全不同。如果是认识repetitions加1interval按公式增长第一次间隔1天第二次3天第三次7天逐步放大ease_factor微调提升如果模糊或完全忘了repetitions直接归零interval回到1天单词会重新进入短期密集复习队列并且进入“待强化清单”我每天额外安排10个这种词混进当日任务里。实际设计每日任务队列时我用了优先级排序规则是所有next_review_time早于当前时间的单词必须进入今天的复习队列。新词每天最多安排20个优先安排真题频次高的词。系统会控制今天总单词量上限在60个左右防止用户产生畏难心理直接弃用。这套算法逻辑写起来不复杂核心代码就几十行但效果比那种“每天固定背20个、按列表顺序翻页”的老式背词法好太多。它确保了每个单词在你快要忘掉的时候“恰到好处”地出现在你眼前。2.3 记忆算法的核心实现代码示例下面这段代码是任务生成和参数更新的核心我做了简化但逻辑是完整的你们可以直接跑import datetime import json class MemorizationEngine: def __init__(self, user_id): self.user_id user_id # 每个用户维护一份记忆参数实际开发存数据库这里为演示用字典 self.memory_map {} self.load_user_memory() def load_user_memory(self): # 从数据库或文件读取该用户的记忆记录 pass def next_interval(self, repetitions): # 简化的间隔计算第1次复习隔1天第2次隔2天之后按2的指数增长 if repetitions 0: return 1 elif repetitions 1: return 2 else: return min(2 ** (repetitions - 1), 30) def update_after_review(self, word_id, is_familiar): current self.memory_map.get(word_id, {repetitions: 0, interval: 1, next_review_time: None}) if is_familiar: current[repetitions] 1 current[interval] self.next_interval(current[repetitions]) else: current[repetitions] 0 current[interval] 1 current[next_review_time] ( datetime.datetime.now() datetime.timedelta(dayscurrent[interval]) ).strftime(%Y-%m-%d %H:%M:%S) self.memory_map[word_id] current self.save_user_memory() def get_today_tasks(self, word_list, new_word_count20, daily_limit60): # 先把到期的复习词拉出来 now_str datetime.datetime.now().strftime(%Y-%m-%d %H:%M:%S) review_tasks [ wid for wid, mem in self.memory_map.items() if mem[next_review_time] and mem[next_review_time] now_str ] # 再补上新词直到达到每日上限 new_tasks [ item[word_id] for item in word_list if item[word_id] not in self.memory_map ][:new_word_count] total_tasks review_tasks new_tasks if len(total_tasks) daily_limit: # 如果复习词太多优先保证复习新词顺延到明天 total_tasks review_tasks[:daily_limit] return total_tasks这里面的一个关键点在于update_after_review决定了每个单词未来的出现间隔。用生活化例子解释这就像一个养花的人对不同植物设置了不同的浇水频率有的花三天浇一次有的花一周浇一次系统精确记录每盆花的状态到时间自动提醒而不会所有花一把抓地每天浇水。3. 基于Python的后端服务与接口设计3.1 选FastAPI还是Flask我的理由写这个项目后端时我在Flask和FastAPI之间犹豫过一阵。Flask更简单、上手快我最早做练习时就用它写过留言板。但考虑到这个项目的实际需求——需要异步处理用户并发请求、需要自动生成接口文档方便前端同学对接、需要对参数进行校验——我最后选了FastAPI。FastAPI对现代Python特性支持好自带OpenAPI接口文档调试的时候浏览器打开/docs就能看到所有接口和参数格式前端开发可以省掉大量来回沟通的时间。对个人项目来说这一点体验提升很明显。安装命令很简单pip install fastapi uvicorn sqlalchemy运行服务时我用的是uvicorn main:app --host 0.0.0.0 --port 8000这样手机和其他设备也能通过局域网IP访问到服务。3.2 核心API接口设计我设计的接口不多就四个核心端点前端只需要会这几个就能跑起来。POST /api/login接收前端传的openid或者用户名完成注册或登录返回一个user_id。我第一版没有做复杂的JWT鉴权直接返回user_id方便开发和调试。GET /api/word/daily?user_idxxx获取某用户当天的单词任务列表。返回内容包含单词本体内核、音标、释义、例句以及每个单词的复习状态。POST /api/review接收用户复习单词后的反馈参数是user_id、word_id、is_familiar布尔值表示认识或模糊。这个接口会调用记忆引擎更新参数。GET /api/progress?user_idxxx返回用户的整体学习进度包括已学单词数、掌握率、连续打卡天数。我遇到一个问题有的前端同学反馈说列表接口返回的字段太多了朋友的小程序端和APP端对数据结构的期望不完全一致。后来我统一把接口返回格式规范成这种结构{ code: 0, message: success, data: { task_list: [], review_count: 10, new_word_count: 5 } }前端只需要判断code是否为0然后直接取data字段用这比返回裸JSON要规范得多也方便后续增加错误码和提示信息。3.3 数据库表结构怎么设计才算合理数据库我用的是SQLite起步设计了三张表逻辑非常清晰。words表存词库静态数据word_id、word_text、phonetic、meaning_cn、example_sentence、frequency。这张表基本只做查询不频繁更新。users表存用户基础信息user_id、nickname、created_at。第三张表是灵魂表review_records它记录每个用户和每个单词之间的交互历史字段包括record_id、user_id、word_id、is_familiar、review_time、interval_days。每次用户点击“认识”或“模糊”就往这张表里插一条记录。为什么单独建这个表而不是把所有信息塞进用户表因为后期我要看学习趋势曲线比如某用户这周掌握率是70%上周是50%有了原始数据才能做出统计分析。如果只存最新的记忆参数历史趋势全丢了无法评估学习效果。我给review_records表的user_id和review_time字段加了索引后续查询量大了之后这个优化很重要。没有索引时用户连续学习一个月后查询今天任务的SQL会越来越慢我当时被这个问题困扰过半天加完索引直接快了20多倍。4. 前端小程序与APP壳的实现与对接4.1 前端页面结构和核心交互设计前端我用的是uni-app写完一套代码可以同时构建微信小程序、H5和Android/iOS平台。说实话不同端之间会有一些细节差异但核心页面逻辑完全能共用。界面设计我参考了那些做得好的背词产品总共设计了四个主要页面首页今日任务卡片顶部显示连续打卡天数和今日目标词数中间是一个大卡片显示单词和音标点击翻面显示释义和例句下方两个按钮分别是“认识”和“模糊”。复习日历页用日历形式展示最近30天的复习量让用户直观看到自己每天背了什么哪天断了。单词列表页展示所有已学单词按掌握程度排序点开可以查看详细释义和记忆状态。我的页面显示总体进度、正确率和设置选项。页面数量不多但每一个都要做到信息密度合理。比如今日任务卡片我特意没有设置太多花哨的转场效果因为背单词核心场景是快速过卡花哨动画反而拖慢节奏。4.2 前端如何正确调用后端接口前端对接是新手最容易出错的地方主要集中在网络请求这块。我用uni-app封装了一个简单的request.js文件核心逻辑是设置基础URL和超时时间并统一处理后端返回的code状态。基础URL在开发阶段我把手机和电脑设在同一局域网直接填电脑的IP比如http://192.168.1.100:8000。部署上线后再把域名填到这里。一个我必须提醒的坑小程序模式里不能直接请求http://明文协议的地址。在微信小程序官方规定中请求必须走HTTPS或是已在后台配置的合法白名单域名。因此本地开发时我是在开发者工具里勾选了“不校验合法域名”选项真机调试时会暂时关闭该功能。等部署到云服务器之后我配置了HTTPS证书正式环境就不存在这个问题。APP端相对宽松可以走HTTP明文协议但建议上线时也换HTTPS否则一些应用商店审核可能会卡壳。前端向/api/review提交反馈的核心逻辑是这样的submitReview(wordId, isFamiliar) { uni.request({ url: getApp().globalData.baseUrl /api/review, method: POST, data: { user_id: this.userId, word_id: wordId, is_familiar: isFamiliar }, success: (res) { if (res.data.code 0) { this.loadNextWord(); } else { uni.showToast({ title: 提交失败请重试, icon: none }); } }, fail: () { uni.showToast({ title: 网络错误, icon: none }); } }); }这个请求方法里的loadNextWord会调用下一个单词的加载逻辑。我注意到不少新手会把单词切换逻辑放在前端本地下一张卡片直接从当前列表读取这样会导致一个问题如果用户中途退出前端本地状态还没同步到后端下次打开就会重复显示已背过的词。所以我特意让前端始终以后端返回的task_list为准每次刷新都重新获取避免状态不一致。4.3 编译与多端适配的注意点用uni-app开发时每个平台都有各自的坑。我整理了一下微信小程序端样式百分比布局需要测试因为有些机型屏幕宽度不同卡片太长会被截断。建议核心卡片使用rpx单位。APP端真机调试需要安装HBuilderX打包工具调试时用USB连接比较稳定。我第一次用WiFi连接真机调试时经常出现请求超时后来改为USB连接就解决了。H5端如果只是做预览H5比较方便但要注意跨域问题需要在后端加上跨域响应头。我比较推荐先把小程序端调通再去适配其他端。因为小程序审核和测试流程最标准化而且现在用户使用场景也最广泛。APP壳我是在小程序稳定之后才打包测试的省去了很多同时排查多端问题的麻烦。5. 部署细化与实战问题排查清单5.1 本地局域网调试真实记录我第一阶段做的是局域网调试。电脑上运行uvicorn服务手机装好打包出来的小程序开发版或APP测试包通过局域网连接电脑的8000端口。这一步常见的故障有几种后端启动时绑定了127.0.0.1手机根本访问不到。解决方法是启动参数写--host 0.0.0.0。电脑防火墙拦截了8000端口的入站请求。需要在防火墙的高级设置里添加入站规则允许Python进程通过或者临时关闭防火墙测试阶段可行正式环境不建议。手机和电脑不在同一网段。如果一个是公司网络一个是手机热点那自然连不上需要都接入同一个路由器或热点。5.2 常见问题排查速查表我把开发到上线过程中遇到的典型问题整理成了清单新同学直接对照查就能解决大部分问题。问题现象可能原因解决方案小程序真机预览白屏HTTPS域名未配置小程序后台配置合法域名使用云开发环境或购买HTTPS证书后端收到请求但前端总是超时CORS跨域未配置FastAPI中添加CORSMiddleware允许指定来源点击“认识”后单词不刷新前端本地列表索引混乱改用后端接口返回的task_id当作唯一键复习日历显示天数不对时区问题前端发送当前时间戳后端统一转成北京时间处理用户登录后学习记录丢失Unicode字符串匹配不一致前端传的openid和后端记录的是同一条数据确保编码一致每日任务数量不对记忆引擎参数未初始化检查memory_map中是否缺少默认值初始化逻辑5.3 部署到云服务器的一些建议当项目从本地搬到云服务器后有几个事情必须做数据持久化和稳定运行。我用的是最基础的方式购买一台云服务器配置1核2G足够了把代码通过git上传到服务器然后安装Python环境和依赖包。我用的是Caddy或Nginx做反向代理把域名流量转发到本地的8000端口。这样外部用户走HTTPS域名访问不再需要暴露门的底层IP。后端进程的管理我用的是supervisor好处是服务崩溃后会自动重启还能统一查看日志。不要把uvicorn直接用nohup后台挂着万一进程被系统杀掉你就得手动重启非常麻烦。数据库方面SQLite在几百个用户量级是完全够用的我的最大并发测试到50人同时使用时无压力。如果以后真的要扩展到更大用户量可以平滑迁移到MySQL。全局搜一遍代码中所有关于sqlite3的操作换成mysql.connector或者ORM改动成本并不高。6. 体验优化与功能扩展的个人心得6.1 用户反馈是优化的一手素材项目上线后我最深刻的印象来自一批真实用户的反馈。有个同学跟我说她看到单词卡片上有例句之后记忆速度明显变快了因为生词一旦放到具体的真题句子里就变得立体了。受这个启发我把例句展示放在了比释义更靠前的位置。还有一个用户反馈说每天60个词上限还是有点多背到40个时已经开始“瞟一眼就当认识”。我后来把对话改成在学习过程中检测正确率如果用户连续5个词都选择“认识”系统会弹出确认提示“你确实认识这个词吗”这很大程度上拦截了“假熟”现象。6.2 功能扩展的几个方向如果你们想在这个项目基础上继续做深我有几个明确可落地的思路增加听力模式调用Python的文本转语音库生成单词和例句的音频前端播放做成“听音拼词”模式对四六级听力板块帮助很大。增加数据可视化把用户的学习曲线用图表展示今天学了多少、预测多久以后会遗忘这对用户粘性提升非常明显。增加社交模块PK背词正确率、好友周榜等功能。技术难度不高但能大幅增加复购和活跃。我个人最推荐先做数据可视化因为我的后端已经有了review_records表中的历史数据差的只是前端图表库和几个统计接口。这块做出来产品整体质感会提升一大截。6.3 最后再分享两个小技巧第一个是给多用例的关键永远不要让用户感觉在填表。我在记录用户学习交互时只留了两个按钮不做复杂的自定义用户不需要选择“模糊认识是百分之多少”。一旦交互变重人就会产生负担背词这个行为本身就容易放弃再增加这种“学习成本”就完全违背了产品初衷。第二个是在实际开发中怎么处理Python后端的并发问题。FastAPI天然支持异步我在/api/review接口里用了async定义协程这样即使多个用户同时提交复习记录后端也不会阻塞。数据库连接操作要注意不要用同步阻塞的写法优先选异步驱动的库否则性能瓶颈很容易卡在数据库操作上。这个项目整体做完对我来说最大的收获是明白了一个道理工具类产品功能不需要多但每一个环节都要对准用户的实际痛点。能不能在用户快要遗忘时及时推回这个词用户体验差距非常大。如果有同学用我这套架构做得更好欢迎一起交流改进。
