那年做毕设选题的时候我选的是“基于微信小程序的交通规则系统”。身边不少人觉得这个题目太常见、太简单——无非是题库列表、答题页面、错题本再加上一个模拟考试页面做完就差不多了。真正动手之后才发现这个项目最麻烦的地方根本不在界面而在三件事情上题目数据怎么管、考试过程怎么不出乱子、用户练完题之后能不能形成学习闭环。如果你只是搭了几个页面把几十道题写死在代码里那确实很快。但只要把场景换成“真实考生用手机反复练习、随时中断、模拟考试、再看错题”整个系统的复杂度马上就不一样了。这篇文章我想把这类交通规则小程序从选题到落地过程中最容易被忽略的部分拆开讲一遍。不是抄功能清单而是回答一个问题为什么很多同类系统看起来什么都有用起来却不像一个正经的考试学习工具1. 先搞清楚交通规则小程序真正处理的是“考场流程”不是题目列表1.1 为什么很多人会低估这个项目交通规则系统本质上是一套“考试练习工具”。它的核心用户场景并不复杂用户打开小程序选择科目或章节做练习答完看解析参加模拟考试限时交卷得到分数把做错的题收集起来反复练习。听起来很直接对吧但问题在于答题不是一个孤立动作而是一连串状态的组合。用户做第 10 题的时候前面 9 题的答案还在内存里用户考试考到一半切出去回了个微信回来之后倒计时还在不在用户交卷时网络断了他这道题的答题结果会不会丢……这些才是真正决定一个系统好不好的地方。很多人一上来就写页面先做个题目列表再做个答题页然后发现数据放不下、状态理不清、考试流程各种异常最后整个项目退化成“一个能看题的静态页面”。1.2 把考场的规则翻译成程序的状态变化我们可以把线下考场的流程仔细想一遍你会发现它其实是一条严格的状态链入场确定考生身份分配座位对应小程序的登录和用户识别发卷考生拿到一份符合规则的试卷对应随机组卷答题边写边记录题号之间跳转不会覆盖已有答案对应答题状态保存交卷时间到或主动交卷系统判分对应交卷和计分逻辑复盘考完看错在哪下次不要再错对应错题本和解析。如果程序里的状态和这个流程对不上用户就会觉得“别扭”。比如答了 20 题回到第 1 题刚才选的答案没了比如考试还有 3 分钟切到后台再回来直接显示“考试结束”——这些都是状态丢失造成的问题。所以我的建议是先不要把“页面”摆在第一位先把“考试状态机”理清楚。什么时候是“练习中”什么时候是“考试中”什么时候“已交卷”什么时候“错题复习中”这些状态之间怎么切换才是系统的核心骨架。1.3 先确认你的边界题库规模、题型数量、是否需要后台开始设计之前有几件事要提前想清楚否则后期返工成本很高题库从哪来是自己收集整理还是调用第三方 API还是由管理员在后台录入这个决定决定了数据表怎么设计。题目量级多大如果只有几十道题写死在本地 JSON 里也能接受如果上千道题就必须走服务端接口和分页加载。题型有哪些判断题、单选题、多选题的判分逻辑完全不同尤其是多选题错选、漏选都不得分不能和单选题共用一套判分。需不需要模拟考试如果需要就必须处理计时、交卷、分数统计这是比练习更复杂的一块。这些看起来是在做“需求分析”实际上是在定系统的复杂度天花板。先把边界划清楚后面写代码就不会反复推翻。2. 题库数据结构是地基别急着写页面2.1 题目表的基本字段设计在常见实践里一套交通规则小程序的题目数据至少要包含这些字段字段说明id题目唯一标识主键category_id所属分类比如科目一、科目四或章节type题型1 判断题2 单选题3 多选题question题干文本options选项列表建议用 JSON 数组存储answer标准答案判断题存 true/false选择题存选项下标或标识analysis题目解析difficulty难度等级用于组卷权重分配status是否启用下线的题不要出现在练习里version题目版本用于后续更新同步这里最容易踩坑的是选项的存储方式。新手最常见的做法是建 20 个字段比如option_a、option_b、option_c……这很不好扩展。如果哪天题型改成不定项或者选项图标换成图片这套表就要大改。更合理的做法是把选项存成一个 JSON 数组例如[ { key: A, text: 红灯亮时 }, { key: B, text: 绿灯亮时 }, { key: C, text: 黄灯闪烁时 }, { key: D, text: 以上都不对 } ]这样前端渲染时直接遍历数组新题型也只是多传一项不用改表结构。答案字段则存[A]或[B, C]这样的数组判断题可以简单存true或false。2.2 难点不在存储而在更新和导入交通规则题目的一个特点是它会过时。交通法规如果调整题目答案可能变化。如果你把题目写死在代码里发布一次就要重新审核、重新上架用户还得更新版本才能看到新题。所以这里更建议采用服务端拉取的方式。管理员在后台维护题目小程序端请求分类列表和题目列表本地可以缓存一部分但以服务端数据为准。题目导入也是一个容易被忽视的问题。常见的导入格式是 Excel 或 JSON。你可能会遇到选项列错位、判断题答案格式不统一、题干里有多余空格、答案解析里带了特殊字符等问题。稳妥的做法是导入时做一次数据清洗并在导入前先导出模板确保格式一致。对于个人开发者来说如果不想做后台管理系统也可以用一个简单的管理接口或者用数据库管理工具直接维护题目表。但不管哪种方式题目表一定要有 version 字段或 update_time 字段否则你无法判断本地缓存是不是已经过期。2.3 题目标注分类、难度、组卷权重很多交通规则系统里的题目不是凭空混在一起抽的而是按规则组卷。比如科目一考试里道路交通安全法律法规、交通信号、安全行车常识等分类各占一定比例。要让模拟考试更接近真实场景题目表需要保存category_id和difficulty。组卷时按照比例去各分类里随机抽取。比如总共 100 题法规类抽 40 题交通信号类抽 30 题安全文明类抽 30 题。如果某一个分类下题目数量不够程序要能提前发现并提示而不是组卷到一半突然发现没题可用。3. 考试逻辑从“能出题”到“不能出乱子”3.1 随机组卷与判分逻辑模拟考试是这类小程序里最有“工程感”的部分。表面上只是随机出题、限制时间、交卷判分但每一环都有细节。随机组卷的核心不是“随机”而是“可控的随机”。你要保证题目不重复、各分类比例符合设定、难度分布不能忽高忽低。同时同一用户连续两次模拟考试最好不要抽出完全一样的卷子这就涉及本地去重或按时间窗口过滤。判分逻辑更不能马虎判断题用户选项和标准答案一致得分单选题用户选项等于唯一答案得分多选题答案集合和标准答案完全一致才算对少选、多选、错选都不得分。在实现上多选题不能用简单的等值比较尤其要注意选项顺序。用户选“A、C”和选“C、A”应该视为同一组答案。常见做法是先把用户答案排序再和标准答案排序后比较。3.2 最容易出问题的三个关键时刻从工程经验看考试流程最容易出问题的不是答题过程而是三个边缘时刻第一个切后台。用户考试中途切到微信聊天再回来倒计时应该暂停还是继续不同产品逻辑不同。常见做法是记录一个考试开始时间戳每次回到页面时用服务器时间或本地时间计算剩余时长。如果用户长时间切走要给提示或自动交卷避免“边查资料边考试”。第二个交卷瞬间。用户在最后几秒点交卷如果网络刚好波动请求超时了前后端状态不一致就会出现“前端显示已交卷、后端没收到任何答题记录”的问题。比较稳妥的做法是本地先保存答卷数据再尝试提交提交成功后才标记为“已交卷”如果失败提示用户重新提交。第三个多选判分。多选少选、漏选、错选都不得分这是常识。但很多新手在存答案时用join(,)拼接成字符串再接一个字符串相等判断结果用户选的顺序一变就误判。这个在前面也提到了简单一个排序就能解决但确实非常常见。3.3 模拟考试中断的兜底方案考试中断是移动端应用逃不开的问题。不管是因为内存不足被回收、用户主动退出还是网络断开都要有一个兜底方案。兜底方案一般分三层草稿箱机制用户在答题过程中每答完一题就把当前答题状态写入本地缓存包括当前题号、已答题目、剩余时间、开始时间。回到页面时先读缓存恢复现场。断点续考如果用户中途退出模拟考试再次进入时询问是否继续上次未完成的考试如果用户选择放弃才清除缓存并记为一次无效考试。交卷重试提交失败时保留本地答卷提供“重新提交”按钮并在网络恢复后自动提交一次。这三层听起来不难但很多人会跳过。原因通常是“反正考试时间不长退出就退出吧”。问题是用户不这么想他做了一半天因为一个误触退出回来发现试卷空了很可能直接卸载小程序。注意本地缓存一定要区分“练习模式”和“正式考试模式”。练习模式的缓存可以随意覆盖正式考试模式的缓存要谨慎处理避免误清。4. 学习记录、错题本与统计让系统真正有“学习价值”4.1 登录与用户识别的常见误区小程序里做用户识别绕不开wx.login。这个接口会换取一个临时凭证后端再用凭证去微信服务端换取 openid。openid 就是用户在这个小程序里的唯一标识。很多新手会犯一个错想把用户的昵称和头像存下来于是直接在页面里调用wx.getUserProfile或用button open-typechooseAvatar等能力。这里要注意微信的规则一直在调整而且不同版本的基础库行为不一样。如果这个信息只是用来展示优先级并不高。先把 openid 跑通、把用户表建好比纠结头像昵称更实际。用户表一般只需要idopenidnickname可选avatar可选create_timelast_login_time学习记录表是另一个核心。每个用户每做一道题就要在题目记录表里写一行或多行记录包含用户 ID、题目 ID、是否答对、用户提交的答案、做题时间、题目所属分类。这张表才是你做统计、做错题推荐、做薄弱项分析的数据基础。4.2 错题本不是收藏夹错题本的功能和“收藏夹”完全不是一回事。收藏夹是你主动收藏某些题目错题本是系统自动收集你做错的题目并且要支持“消除”。一个比较常见的设计是答错记录一次错误加入错题本再次做对连续做对一定次数比如连续答对 3 次从错题本中移出答对后又答错重新计数继续留在错题本。这个逻辑看起来很简单但很实用。如果错题本只进不出时间长了就成了一个巨大的题目列表用户根本不想回头看。如果没有做对次数的要求用户一次蒙对了就会从错题本里消失下次照样错。错题本还需要保留“错因”信息。用户是因为对交通标志不熟悉还是因为法规条款记混了这个信息从单次答题看不出来但累积多了就能暴露问题。所以错题记录表里至少要有wrong_answer和is_correct两个字段方便回看当时的错误答案。4.3 学习数据的展示与驱动有了做题记录和错题记录就可以做统计了。常见展示维度包括累计做题数量总正确率今日做题数和今日正确率各分类正确率错题数量与已消除数量。这些统计的价值不只是给用户看一个数字而是引导用户去练最弱的部分。比如用户发现“交通信号”这个分类的正确率只有 60%他就会有意识地去多练这一块。很多小程序会在练习页面做“薄弱分类推荐”逻辑很简单就是按分类统计正确率取最低的一个放到显眼位置。5. 开发中最容易被带偏的几个方向5.1 支付、地图、蓝牙先判断和核心场景的关系交通规则小程序开发过程中经常会被热门关键词带偏。周围人会问能不能加上在线支付能不能接入地图用户去考场导航能不能蓝牙连接设备做题还有人在开发前就研究微信支付 v3 对接搞了一整天平台证书最后发现项目根本不需要支付功能。这不是说这些功能没有价值而是要做一个判断这个功能是不是项目主题的核心环节交通规则系统的核心是练习、考试、错题巩固。支付属于增值服务地图属于周边工具蓝牙打印更接近线下助考场景都属于“如果有时间再做”的部分。尤其对于毕设或学习项目先把核心闭环做完整比盲目加功能重要得多。一个能稳定完成 100 道题模拟考试、判分准确、错题能消除的系统远比一个页面漂亮但交卷会丢数据、还带了一个支付入口的半成品更有说服力。5.2 花哨组件UI 好看不等于系统可靠有一个很常见的现象项目做到一半开发者花大量时间在答题页面加动画特效或者用第三方组件库搭出酷炫的进度条和转场效果。不是说这些不能做而是在核心流程没跑通之前UI 层面的优先级应该往后放。交通规则小程序的核心体验是“答得顺、交得快、看得懂错在哪”。动画特效只是锦上添花。如果动画导致答题切换卡顿反而破坏了考试体验。这里有一个比较实用的开发顺序文字界面先把完整流程跑通再统一视觉样式最后按需加交互动效。5.3 减少对基础能力的依赖交通规则小程序本身不复杂但如果你在开发时把大量逻辑依赖在某些不稳定的外部能力上就会给自己挖坑。一个典型例子是题库完全依赖第三方接口。假如第三方题库接口挂了你整个小程序就废了。另一个例子是获取用户手机号做登录这个能力现在需要企业主体的小程序才有接口权限个人开发者很容易在这里卡住。稳妥的做法是题库数据自己做一份结构化备份不依赖第三方在线接口登录先用 openid 方案手机号授权当作可选增强地图、支付这类能力先查清楚小程序主体和个人开发者限制再决定要不要接入。6. 从“跑通”到“能长期用”上线前后的工程化补全6.1 真机与开发工具之间的差异开发工具里跑得好好的真机上一测就出错这是小程序开发里最常见的现象。交通规则小程序也一样。常见差异包括机型差异iOS 和 Android 对video、canvas等组件的支持细节不同安全区域顶部导航栏高度、底部小黑条在不同机型上表现不同答题页的翻页按钮很容易被遮挡缓存策略本地缓存在某些机型上可能被系统清理不能把重要数据只存在本地网络环境开发工具的模拟网络过于理想真机上弱网环境下接口超时是常态。所以从开发第一天开始就要有真机调试的习惯不要等项目写完再拿手机测。哪怕每天只花 10 分钟在真机上点一遍核心流程也能提前暴露很多问题。6.2 接口安全、请求频率与内容审核小程序上线要经过微信审核审核不通过的原因五花八门。但如果你的交通规则小程序里接了自己开发的题库接口就要特别注意接口必须校验用户身份不能让别人随便调用你的题库接口把全部数据拉走。常见做法是获取用户 openid 后再生成一个自定义登录态接口请求时带上 token。记录用户行为日志像交卷、删错题、修改记录这类操作后端最好保留日志。万一用户反馈“我的错题少了”你能从日志里查原因。控制请求频率防止单个用户在短时间反复请求题库接口给服务器造成压力。常见做法是按用户维度做接口限流。内容安全题库里的文字、图片尤其是解析部分要确保没有违规内容。审核不通过时先检查这里。6.3 日志、异常与数据备份很多开发者把项目停留在“功能都能用”的阶段但离“系统稳定运行”还差很远。这里最关键的三个动作加日志。记录关键操作的时间点和结果比如用户登录、考试开始、答卷提交、错题消除。不用很复杂文本日志就够早期排查使用。捕获全局异常。小程序有全局的onError监听把异常信息上报到后端或日志平台。否则用户报错时你只能靠猜。定期备份数据库。题库和用户学习记录都是核心资产。如果数据库误删或服务器故障没有备份就是灾难。交通规则系统的用户数据量不会特别大但它的特点是用户连续使用周期很长。一个用户可能刷了 5000 道题做了 30 次模拟考试这些数据一旦丢失用户几乎不可能重来一遍。所以哪怕只是每天自动导出一次数据库备份都能在关键时刻救你一次。6.4 维护视角考试题库会过时题目数据需要定期更新任何领域的考试题库都有一个共同点命题范围会随法规、政策和教材的变化而变化。交通规则题目的标准答案可能因为法规调整而发生变化这是所有同类系统都绕不开的现实。所以做一个交通规则小程序不只是写代码那么简单。你需要给自己的系统一个“可持续更新的入口”。可以是一个后台管理界面甚至可以简单到一个能导入 JSON 的管理命令核心是当题目需要更新时你不需要重新发版。如果题库是写死在代码里的一次更新就要走完整的发版流程用户还不一定及时更新。如果题库在服务端前端做版本判断用户一进来就能拉取最新题体验会好很多。这里要格外处理的事是不要因为题库更新而影响用户已经产生的答题记录。题目 ID 要保持稳定如果一个题目的答案变了代码里要处理好旧记录和新答案的关系不能让用户的错题本里显示出一题两个答案的怪异状态。回到最开始说的那个判断交通规则小程序真正解决的问题不是把一个题库搬上手机而是把“学习—练习—考试—复盘”这个完整闭环稳定地跑起来。在落地时我的建议一直是同一个顺序先做最小闭环再补边缘情况。所谓最小闭环就是登录、看题、答题、判分、交卷、看到分数和错题这一条链路必须跑通且稳定。这条链路稳定之后再去做统计图表、错题推荐、弱项分析、模拟考试次数限制、每日打卡这些延展功能。如果一开始就想着把所有功能都做上去很容易陷入“页面很多、没有一个好用”的境地。反过来把一条主链路做扎实哪怕功能少一点用户也能感受到这是一个正经的学习工具。交通规则系统是一类很适合作为毕设、课程设计或技术练手的小程序项目但它的“简单”只是表面上。真正把它做好靠的不是堆页面而是对数据结构、状态管理和流程边界的理解。这份理解也会在以后做任何复杂系统时反复用到。先跑通再优化。答案是否可靠用户会告诉你。
那年做毕设选题的时候我选的是“基于微信小程序的交通规则系统”。身边不少人觉得这个题目太常见、太简单——无非是题库列表、答题页面、错题本再加上一个模拟考试页面做完就差不多了。真正动手之后才发现这个项目最麻烦的地方根本不在界面而在三件事情上题目数据怎么管、考试过程怎么不出乱子、用户练完题之后能不能形成学习闭环。如果你只是搭了几个页面把几十道题写死在代码里那确实很快。但只要把场景换成“真实考生用手机反复练习、随时中断、模拟考试、再看错题”整个系统的复杂度马上就不一样了。这篇文章我想把这类交通规则小程序从选题到落地过程中最容易被忽略的部分拆开讲一遍。不是抄功能清单而是回答一个问题为什么很多同类系统看起来什么都有用起来却不像一个正经的考试学习工具1. 先搞清楚交通规则小程序真正处理的是“考场流程”不是题目列表1.1 为什么很多人会低估这个项目交通规则系统本质上是一套“考试练习工具”。它的核心用户场景并不复杂用户打开小程序选择科目或章节做练习答完看解析参加模拟考试限时交卷得到分数把做错的题收集起来反复练习。听起来很直接对吧但问题在于答题不是一个孤立动作而是一连串状态的组合。用户做第 10 题的时候前面 9 题的答案还在内存里用户考试考到一半切出去回了个微信回来之后倒计时还在不在用户交卷时网络断了他这道题的答题结果会不会丢……这些才是真正决定一个系统好不好的地方。很多人一上来就写页面先做个题目列表再做个答题页然后发现数据放不下、状态理不清、考试流程各种异常最后整个项目退化成“一个能看题的静态页面”。1.2 把考场的规则翻译成程序的状态变化我们可以把线下考场的流程仔细想一遍你会发现它其实是一条严格的状态链入场确定考生身份分配座位对应小程序的登录和用户识别发卷考生拿到一份符合规则的试卷对应随机组卷答题边写边记录题号之间跳转不会覆盖已有答案对应答题状态保存交卷时间到或主动交卷系统判分对应交卷和计分逻辑复盘考完看错在哪下次不要再错对应错题本和解析。如果程序里的状态和这个流程对不上用户就会觉得“别扭”。比如答了 20 题回到第 1 题刚才选的答案没了比如考试还有 3 分钟切到后台再回来直接显示“考试结束”——这些都是状态丢失造成的问题。所以我的建议是先不要把“页面”摆在第一位先把“考试状态机”理清楚。什么时候是“练习中”什么时候是“考试中”什么时候“已交卷”什么时候“错题复习中”这些状态之间怎么切换才是系统的核心骨架。1.3 先确认你的边界题库规模、题型数量、是否需要后台开始设计之前有几件事要提前想清楚否则后期返工成本很高题库从哪来是自己收集整理还是调用第三方 API还是由管理员在后台录入这个决定决定了数据表怎么设计。题目量级多大如果只有几十道题写死在本地 JSON 里也能接受如果上千道题就必须走服务端接口和分页加载。题型有哪些判断题、单选题、多选题的判分逻辑完全不同尤其是多选题错选、漏选都不得分不能和单选题共用一套判分。需不需要模拟考试如果需要就必须处理计时、交卷、分数统计这是比练习更复杂的一块。这些看起来是在做“需求分析”实际上是在定系统的复杂度天花板。先把边界划清楚后面写代码就不会反复推翻。2. 题库数据结构是地基别急着写页面2.1 题目表的基本字段设计在常见实践里一套交通规则小程序的题目数据至少要包含这些字段字段说明id题目唯一标识主键category_id所属分类比如科目一、科目四或章节type题型1 判断题2 单选题3 多选题question题干文本options选项列表建议用 JSON 数组存储answer标准答案判断题存 true/false选择题存选项下标或标识analysis题目解析difficulty难度等级用于组卷权重分配status是否启用下线的题不要出现在练习里version题目版本用于后续更新同步这里最容易踩坑的是选项的存储方式。新手最常见的做法是建 20 个字段比如option_a、option_b、option_c……这很不好扩展。如果哪天题型改成不定项或者选项图标换成图片这套表就要大改。更合理的做法是把选项存成一个 JSON 数组例如[ { key: A, text: 红灯亮时 }, { key: B, text: 绿灯亮时 }, { key: C, text: 黄灯闪烁时 }, { key: D, text: 以上都不对 } ]这样前端渲染时直接遍历数组新题型也只是多传一项不用改表结构。答案字段则存[A]或[B, C]这样的数组判断题可以简单存true或false。2.2 难点不在存储而在更新和导入交通规则题目的一个特点是它会过时。交通法规如果调整题目答案可能变化。如果你把题目写死在代码里发布一次就要重新审核、重新上架用户还得更新版本才能看到新题。所以这里更建议采用服务端拉取的方式。管理员在后台维护题目小程序端请求分类列表和题目列表本地可以缓存一部分但以服务端数据为准。题目导入也是一个容易被忽视的问题。常见的导入格式是 Excel 或 JSON。你可能会遇到选项列错位、判断题答案格式不统一、题干里有多余空格、答案解析里带了特殊字符等问题。稳妥的做法是导入时做一次数据清洗并在导入前先导出模板确保格式一致。对于个人开发者来说如果不想做后台管理系统也可以用一个简单的管理接口或者用数据库管理工具直接维护题目表。但不管哪种方式题目表一定要有 version 字段或 update_time 字段否则你无法判断本地缓存是不是已经过期。2.3 题目标注分类、难度、组卷权重很多交通规则系统里的题目不是凭空混在一起抽的而是按规则组卷。比如科目一考试里道路交通安全法律法规、交通信号、安全行车常识等分类各占一定比例。要让模拟考试更接近真实场景题目表需要保存category_id和difficulty。组卷时按照比例去各分类里随机抽取。比如总共 100 题法规类抽 40 题交通信号类抽 30 题安全文明类抽 30 题。如果某一个分类下题目数量不够程序要能提前发现并提示而不是组卷到一半突然发现没题可用。3. 考试逻辑从“能出题”到“不能出乱子”3.1 随机组卷与判分逻辑模拟考试是这类小程序里最有“工程感”的部分。表面上只是随机出题、限制时间、交卷判分但每一环都有细节。随机组卷的核心不是“随机”而是“可控的随机”。你要保证题目不重复、各分类比例符合设定、难度分布不能忽高忽低。同时同一用户连续两次模拟考试最好不要抽出完全一样的卷子这就涉及本地去重或按时间窗口过滤。判分逻辑更不能马虎判断题用户选项和标准答案一致得分单选题用户选项等于唯一答案得分多选题答案集合和标准答案完全一致才算对少选、多选、错选都不得分。在实现上多选题不能用简单的等值比较尤其要注意选项顺序。用户选“A、C”和选“C、A”应该视为同一组答案。常见做法是先把用户答案排序再和标准答案排序后比较。3.2 最容易出问题的三个关键时刻从工程经验看考试流程最容易出问题的不是答题过程而是三个边缘时刻第一个切后台。用户考试中途切到微信聊天再回来倒计时应该暂停还是继续不同产品逻辑不同。常见做法是记录一个考试开始时间戳每次回到页面时用服务器时间或本地时间计算剩余时长。如果用户长时间切走要给提示或自动交卷避免“边查资料边考试”。第二个交卷瞬间。用户在最后几秒点交卷如果网络刚好波动请求超时了前后端状态不一致就会出现“前端显示已交卷、后端没收到任何答题记录”的问题。比较稳妥的做法是本地先保存答卷数据再尝试提交提交成功后才标记为“已交卷”如果失败提示用户重新提交。第三个多选判分。多选少选、漏选、错选都不得分这是常识。但很多新手在存答案时用join(,)拼接成字符串再接一个字符串相等判断结果用户选的顺序一变就误判。这个在前面也提到了简单一个排序就能解决但确实非常常见。3.3 模拟考试中断的兜底方案考试中断是移动端应用逃不开的问题。不管是因为内存不足被回收、用户主动退出还是网络断开都要有一个兜底方案。兜底方案一般分三层草稿箱机制用户在答题过程中每答完一题就把当前答题状态写入本地缓存包括当前题号、已答题目、剩余时间、开始时间。回到页面时先读缓存恢复现场。断点续考如果用户中途退出模拟考试再次进入时询问是否继续上次未完成的考试如果用户选择放弃才清除缓存并记为一次无效考试。交卷重试提交失败时保留本地答卷提供“重新提交”按钮并在网络恢复后自动提交一次。这三层听起来不难但很多人会跳过。原因通常是“反正考试时间不长退出就退出吧”。问题是用户不这么想他做了一半天因为一个误触退出回来发现试卷空了很可能直接卸载小程序。注意本地缓存一定要区分“练习模式”和“正式考试模式”。练习模式的缓存可以随意覆盖正式考试模式的缓存要谨慎处理避免误清。4. 学习记录、错题本与统计让系统真正有“学习价值”4.1 登录与用户识别的常见误区小程序里做用户识别绕不开wx.login。这个接口会换取一个临时凭证后端再用凭证去微信服务端换取 openid。openid 就是用户在这个小程序里的唯一标识。很多新手会犯一个错想把用户的昵称和头像存下来于是直接在页面里调用wx.getUserProfile或用button open-typechooseAvatar等能力。这里要注意微信的规则一直在调整而且不同版本的基础库行为不一样。如果这个信息只是用来展示优先级并不高。先把 openid 跑通、把用户表建好比纠结头像昵称更实际。用户表一般只需要idopenidnickname可选avatar可选create_timelast_login_time学习记录表是另一个核心。每个用户每做一道题就要在题目记录表里写一行或多行记录包含用户 ID、题目 ID、是否答对、用户提交的答案、做题时间、题目所属分类。这张表才是你做统计、做错题推荐、做薄弱项分析的数据基础。4.2 错题本不是收藏夹错题本的功能和“收藏夹”完全不是一回事。收藏夹是你主动收藏某些题目错题本是系统自动收集你做错的题目并且要支持“消除”。一个比较常见的设计是答错记录一次错误加入错题本再次做对连续做对一定次数比如连续答对 3 次从错题本中移出答对后又答错重新计数继续留在错题本。这个逻辑看起来很简单但很实用。如果错题本只进不出时间长了就成了一个巨大的题目列表用户根本不想回头看。如果没有做对次数的要求用户一次蒙对了就会从错题本里消失下次照样错。错题本还需要保留“错因”信息。用户是因为对交通标志不熟悉还是因为法规条款记混了这个信息从单次答题看不出来但累积多了就能暴露问题。所以错题记录表里至少要有wrong_answer和is_correct两个字段方便回看当时的错误答案。4.3 学习数据的展示与驱动有了做题记录和错题记录就可以做统计了。常见展示维度包括累计做题数量总正确率今日做题数和今日正确率各分类正确率错题数量与已消除数量。这些统计的价值不只是给用户看一个数字而是引导用户去练最弱的部分。比如用户发现“交通信号”这个分类的正确率只有 60%他就会有意识地去多练这一块。很多小程序会在练习页面做“薄弱分类推荐”逻辑很简单就是按分类统计正确率取最低的一个放到显眼位置。5. 开发中最容易被带偏的几个方向5.1 支付、地图、蓝牙先判断和核心场景的关系交通规则小程序开发过程中经常会被热门关键词带偏。周围人会问能不能加上在线支付能不能接入地图用户去考场导航能不能蓝牙连接设备做题还有人在开发前就研究微信支付 v3 对接搞了一整天平台证书最后发现项目根本不需要支付功能。这不是说这些功能没有价值而是要做一个判断这个功能是不是项目主题的核心环节交通规则系统的核心是练习、考试、错题巩固。支付属于增值服务地图属于周边工具蓝牙打印更接近线下助考场景都属于“如果有时间再做”的部分。尤其对于毕设或学习项目先把核心闭环做完整比盲目加功能重要得多。一个能稳定完成 100 道题模拟考试、判分准确、错题能消除的系统远比一个页面漂亮但交卷会丢数据、还带了一个支付入口的半成品更有说服力。5.2 花哨组件UI 好看不等于系统可靠有一个很常见的现象项目做到一半开发者花大量时间在答题页面加动画特效或者用第三方组件库搭出酷炫的进度条和转场效果。不是说这些不能做而是在核心流程没跑通之前UI 层面的优先级应该往后放。交通规则小程序的核心体验是“答得顺、交得快、看得懂错在哪”。动画特效只是锦上添花。如果动画导致答题切换卡顿反而破坏了考试体验。这里有一个比较实用的开发顺序文字界面先把完整流程跑通再统一视觉样式最后按需加交互动效。5.3 减少对基础能力的依赖交通规则小程序本身不复杂但如果你在开发时把大量逻辑依赖在某些不稳定的外部能力上就会给自己挖坑。一个典型例子是题库完全依赖第三方接口。假如第三方题库接口挂了你整个小程序就废了。另一个例子是获取用户手机号做登录这个能力现在需要企业主体的小程序才有接口权限个人开发者很容易在这里卡住。稳妥的做法是题库数据自己做一份结构化备份不依赖第三方在线接口登录先用 openid 方案手机号授权当作可选增强地图、支付这类能力先查清楚小程序主体和个人开发者限制再决定要不要接入。6. 从“跑通”到“能长期用”上线前后的工程化补全6.1 真机与开发工具之间的差异开发工具里跑得好好的真机上一测就出错这是小程序开发里最常见的现象。交通规则小程序也一样。常见差异包括机型差异iOS 和 Android 对video、canvas等组件的支持细节不同安全区域顶部导航栏高度、底部小黑条在不同机型上表现不同答题页的翻页按钮很容易被遮挡缓存策略本地缓存在某些机型上可能被系统清理不能把重要数据只存在本地网络环境开发工具的模拟网络过于理想真机上弱网环境下接口超时是常态。所以从开发第一天开始就要有真机调试的习惯不要等项目写完再拿手机测。哪怕每天只花 10 分钟在真机上点一遍核心流程也能提前暴露很多问题。6.2 接口安全、请求频率与内容审核小程序上线要经过微信审核审核不通过的原因五花八门。但如果你的交通规则小程序里接了自己开发的题库接口就要特别注意接口必须校验用户身份不能让别人随便调用你的题库接口把全部数据拉走。常见做法是获取用户 openid 后再生成一个自定义登录态接口请求时带上 token。记录用户行为日志像交卷、删错题、修改记录这类操作后端最好保留日志。万一用户反馈“我的错题少了”你能从日志里查原因。控制请求频率防止单个用户在短时间反复请求题库接口给服务器造成压力。常见做法是按用户维度做接口限流。内容安全题库里的文字、图片尤其是解析部分要确保没有违规内容。审核不通过时先检查这里。6.3 日志、异常与数据备份很多开发者把项目停留在“功能都能用”的阶段但离“系统稳定运行”还差很远。这里最关键的三个动作加日志。记录关键操作的时间点和结果比如用户登录、考试开始、答卷提交、错题消除。不用很复杂文本日志就够早期排查使用。捕获全局异常。小程序有全局的onError监听把异常信息上报到后端或日志平台。否则用户报错时你只能靠猜。定期备份数据库。题库和用户学习记录都是核心资产。如果数据库误删或服务器故障没有备份就是灾难。交通规则系统的用户数据量不会特别大但它的特点是用户连续使用周期很长。一个用户可能刷了 5000 道题做了 30 次模拟考试这些数据一旦丢失用户几乎不可能重来一遍。所以哪怕只是每天自动导出一次数据库备份都能在关键时刻救你一次。6.4 维护视角考试题库会过时题目数据需要定期更新任何领域的考试题库都有一个共同点命题范围会随法规、政策和教材的变化而变化。交通规则题目的标准答案可能因为法规调整而发生变化这是所有同类系统都绕不开的现实。所以做一个交通规则小程序不只是写代码那么简单。你需要给自己的系统一个“可持续更新的入口”。可以是一个后台管理界面甚至可以简单到一个能导入 JSON 的管理命令核心是当题目需要更新时你不需要重新发版。如果题库是写死在代码里的一次更新就要走完整的发版流程用户还不一定及时更新。如果题库在服务端前端做版本判断用户一进来就能拉取最新题体验会好很多。这里要格外处理的事是不要因为题库更新而影响用户已经产生的答题记录。题目 ID 要保持稳定如果一个题目的答案变了代码里要处理好旧记录和新答案的关系不能让用户的错题本里显示出一题两个答案的怪异状态。回到最开始说的那个判断交通规则小程序真正解决的问题不是把一个题库搬上手机而是把“学习—练习—考试—复盘”这个完整闭环稳定地跑起来。在落地时我的建议一直是同一个顺序先做最小闭环再补边缘情况。所谓最小闭环就是登录、看题、答题、判分、交卷、看到分数和错题这一条链路必须跑通且稳定。这条链路稳定之后再去做统计图表、错题推荐、弱项分析、模拟考试次数限制、每日打卡这些延展功能。如果一开始就想着把所有功能都做上去很容易陷入“页面很多、没有一个好用”的境地。反过来把一条主链路做扎实哪怕功能少一点用户也能感受到这是一个正经的学习工具。交通规则系统是一类很适合作为毕设、课程设计或技术练手的小程序项目但它的“简单”只是表面上。真正把它做好靠的不是堆页面而是对数据结构、状态管理和流程边界的理解。这份理解也会在以后做任何复杂系统时反复用到。先跑通再优化。答案是否可靠用户会告诉你。
