★ FEATURED ARTICLE Spring Boot Vue3 Android这套组合做在线英语学习交流App实战拆解全记录这几年在线教育类App的需求一直挺旺尤其是英语学习方向基本上每隔一段时间就能看到新的产品形态冒出来。我这两年也陆续做过几个类似的项目最近刚完成的一套是Spring Boot Vue3 Android原生的英语在线学习交流系统整体从后端接口、管理后台到用户端App完整走了一遍踩了不少坑也沉淀了一些比较实用的经验。这篇文章就把这个项目从头到尾做一个比较细致的拆解包括功能规划、技术选型逻辑、核心模块实现、数据库设计以及我实际开发过程中遇到的一些问题和解决方法希望能给正在做同类项目的朋友一些参考。1. 项目整体设计思路与功能拆解1.1 项目背景为什么要做“学习交流”双核心最早接到这个需求的时候客户给的描述很简单做一款英语学习App能背单词、能练口语、还能让用户之间交流。但真正往下细化需求才发现纯背单词的工具类App实在太多了像一些知名App早就把单词记忆、打卡、排行榜这些功能做到了极致再做同类产品没有差异化留不住用户。聊了几轮之后我们把产品的核心定位调整成了“学习交流”双轮驱动。什么意思就是用户不只是自己埋头背单词更重要的是能在系统里找到一起学习的语伴、加入兴趣小组、在社区里发帖提问形成一个互帮互助的学习闭环。这个定位也符合现在在线教育的一个趋势工具属性决定用户能不能进来社交属性决定用户能不能留下来。1.2 功能模块规划用户端与管理端分头推进功能规划是项目启动后的第一件事。我们按角色分成了用户端和管理端两大块每一块再细分具体的功能点。用户端Android App主要包含用户注册登录支持手机号验证码注册登录也支持第三方授权登录登录后使用JWT做Token鉴权。单词学习模块按词库分类学习支持每日学习计划、单词收藏、错词本自动收录、复习提醒。口语练习模块基于TTS语音合成和语音识别接口实现跟读、打分、纠音。在线交流社区用户发布学习心得、提问帖支持评论、点赞、收藏。学习伙伴匹配根据用户填写的英语水平、学习目标、兴趣方向推荐相似学习者支持添加好友。个人中心学习时长统计、连续打卡天数、成就徽章、学习报告周报。消息通知系统通知、互动消息有人评论了你的帖子、有人给你点赞等。管理端Vue 3后台主要包含仪表盘用户总量、日活跃、新增用户、学习行为统计等核心数据可视化。用户管理用户列表、状态管理封禁/解封、学习数据查看。词库管理单词分类、词条增删改查、批量导入导出。内容审核用户发布的帖子、评论需要进行内容安全审核支持人工审核和调用接口自动审核。系统配置公告管理、敏感词库配置、积分规则配置。数据导出学习行为数据、用户数据可以按条件筛选后导出Excel。1.3 技术选型分析为什么是这三件套技术选型是这类项目里比较容易被问到一个问题也是我比较有心得的地方。Spring Boot、Vue 3和Android原生这三者的组合从后端到前端再到移动端形成了一个相对完整的全栈闭环每一层都有它不得不这么选的理由。后端用Spring Boot核心原因有三个。第一生态成熟度非常高Spring Security、MyBatis-Plus、Redis、MinIO这些周边组件都有非常完善的文档和社区解决方案团队上手快招聘也容易。第二开发效率高Spring Boot的自动配置简化了大量XML配置的工作基本上项目启动几分钟就能把骨架跑起来。第三稳定性和运维成本可控Java应用部署到云服务器上一台2核4G的机器就能跑得动中小体量的业务这对预算有限的团队来说非常友好。管理端用Vue 3倒不是说Vue 2不行而是Vue 3的Composition API在逻辑复用上的优势太明显了。后台管理系统有大量表单验证、列表筛选、弹窗编辑这类场景用Composition API把相关的状态和操作逻辑抽出来封装成自定义Hooks代码复用率会高很多。再配合Element Plus组件库五六个页面的后台基本两三天就能搭完。移动端用Android原生Java/Kotlin这一点我在和团队讨论时是有过争议的。有同事建议用Flutter做跨平台一套代码同时出Android和iOS。但实际的考量是项目预算只够先做Android版本iOS后续再说另外口语练习模块要深度调用系统的语音识别和音频处理能力原生的API调用更直接性能上也更可控。所以最终客户确认先做原生Android版。2. 数据库设计与核心表结构2.1 核心表设计从用户到行为数据的全链路这套系统的数据模型说复杂也复杂说简单也简单核心就是“用户—内容—行为”三条线。先看用户线的表设计任何一款在线学习产品用户表都是地基中的地基。用户表的核心字段包括用户ID、手机号、密码、昵称、头像URL、英语水平等级入门/初级/中级/高级、学习目标考试/旅游/职场/日常交流、积分余额、连续打卡天数、总学习时长、注册时间、状态等。这里有一个特别容易踩坑的地方千万不要把用户的所有信息都塞进一张表。比如用户的动态学习统计数据像连续打卡天数、总学习时长这种更新频率极高的字段建议单独拆一张用户统计表用异步任务定时更新避免频繁update用户主表造成锁竞争。单词表的结构比较有意思需要同时兼顾“词条本身”和“用户的个性化学习数据”两个维度。词条表存的是单词、音标、释义、例句、所属词库ID、难度等级、发音资源URL而用户单词学习记录表存的是用户ID、单词ID、掌握程度1-5分、错误次数、上次学习时间、是否已收藏、是否在错词本中。两张表通过用户ID和单词ID关联这样设计的好处是词条数据可以复用不同用户在同一词条上的学习状态互不干扰。帖子表包含了帖子ID、用户ID、标题、正文内容、图片列表、所属话题标签比如“四六级备考”“口语纠音”“阅读打卡”、浏览量、点赞量、评论量、审核状态、发布时间。这里我们特意加了“审核状态”字段原因是社区类产品上线后最大的问题往往是垃圾内容和违规内容如果表结构里没有这个字段后面加审核流程会非常痛苦需要改表、改代码、改接口牵一发动全身。2.2 外键还是逻辑关联我的选择与理由关于表之间要不要真正的数据库外键约束我和团队里的初级开发聊过几次这里也想分享一下我的建议。我的习惯是核心业务表之间不要建物理外键统一用逻辑外键也就是普通索引字段来维护关联关系。理由很简单物理外键在插入、更新、删除时都会触发额外的约束校验数据量大之后性能损耗明显而且在线学习这种高并发读写场景下分库分表时物理外键会成为很大的障碍。当然不建外键不代表不需要维护数据一致性。我的做法是在Service层做显式的关联校验比如删除一个用户时要先检查该用户是否有帖子、评论、学习记录有的话先做软删除或者批量清理保证没有脏数据。2.3 数据索引策略与慢查询优化项目上线前做性能压测的时候有几个接口的响应时间一直不达标排查下来基本都是索引问题。这里分享几个比较典型的优化点单词学习记录表查询频繁核心查询条件是user_id word_id组合加上status状态过滤建联合索引(user_id, word_id, status)查询效率直接提升10倍以上。帖子列表页要按时间和热度两个维度排序分别建立create_time和like_count的普通索引就够了但要注意如果查询条件还带了话题标签过滤最好建(topic_id, create_time)的联合索引否则会有大量回表扫描。帖子表的数据量增长很快按我的经验单表超过500万行就该考虑分表或者归档了。这个项目我们采取的做法是把历史帖子按月归档到历史表主表只保留最近三个月的活跃数据。3. 后端核心模块实现Spring Boot的工程化落地3.1 项目分层结构与通用返回体设计后端工程结构按经典的三层架构拆包Controller层统一处理请求和参数校验Service层负责业务逻辑Mapper层管数据库交互。另外单独建了common、config、utils、exception几个基础包。这里重点说一下通用返回体的设计它是所有接口规范化的第一步也是最容易被新手忽略的地方。我们定义的统一返回体结构是{ code: 200, message: 操作成功, data: { userId: 10234, nickname: Lily } }对应的Java类是Data public class ResultT { private Integer code; private String message; private T data; public static T ResultT success(T data) { ResultT result new Result(); result.setCode(200); result.setMessage(操作成功); result.setData(data); return result; } public static T ResultT error(Integer code, String message) { ResultT result new Result(); result.setCode(code); result.setMessage(message); return result; } }所有接口的返回值都统一使用这个Result包装前端拿到响应后先看codecode为200再解析data非200直接提示message。这样做极大地统一了前后端联调的认知成本只要约定清楚调试接口的效率会高很多。3.2 JWT登录鉴权机制从方案选型到落地细节登录鉴权我选的是JWT Spring Security的组合方案。为什么不选传统的Session方案因为这套系统的App端和管理端是分离的将来某天做多端扩展的时候比如增加小程序端Session的适配就比较痛苦而JWT是无状态的天然就支持多端共享Token。实际的落地流程是用户提交用户名密码或手机号验证码验证通过后后端生成一个Token字符串返回给客户端客户端在后续请求中通过Authorization: Bearer token的方式携带后端通过Spring Security的过滤器拦截并校验Token校验通过后解析出用户ID放入请求上下文。有几个实际开发中容易出问题的地方值得提醒一下Token过期时间怎么定我们这里设计成AccessToken有效期2小时同时生成了一个RefreshToken有效期14天客户端在AccessToken过期时用RefreshToken换新的Token避免用户频繁重新登录。用户被封禁时Token怎么办JWT无状态的特点导致它没法直接作废我们的解决方案是在用户表加了一个status字段每次请求鉴权时检查一下用户状态如果为封禁状态则直接拒绝请求并返回错误码。密钥管理JWT的签名密钥绝对不能硬编码在代码里我们放在配置中心部署时通过环境变量注入。3.3 登录接口的完整实现示例登录接口的核心代码如下注意处理密码加密和参数校验的逻辑PostMapping(/login) public ResultLoginResponse login(RequestBody Valid LoginRequest request) { // 1. 参数校验手机号格式、验证码非空 // 2. 查询用户是否存在 LambdaQueryWrapperUser queryWrapper new LambdaQueryWrapper(); queryWrapper.eq(User::getPhone, request.getPhone()); User user userMapper.selectOne(queryWrapper); if (user null) { return Result.error(400, 该手机号未注册); } // 3. 校验密码 if (!passwordEncoder.matches(request.getPassword(), user.getPassword())) { return Result.error(400, 密码错误); } // 4. 检查用户状态 if (user.getStatus() 0) { return Result.error(403, 账号已被封禁); } // 5. 生成Token并返回用户基本信息 String accessToken jwtUtil.generateToken(user.getId(), user.getRole(), 7200L); String refreshToken jwtUtil.generateToken(user.getId(), user.getRole(), 1209600L); LoginResponse response new LoginResponse(); response.setAccessToken(accessToken); response.setRefreshToken(refreshToken); response.setUserId(user.getId()); response.setNickname(user.getNickname()); return Result.success(response); }密码加密这里多说一句必须用BCrypt这类带盐的哈希算法绝对不要用MD5或SHA直接存密码否则一旦数据库泄露用户的明文密码就等于暴露了。3.4 单词学习模块每日计划与复习策略单词学习模块的核心业务逻辑是“学习计划生成”和“复习曲线调度”。学习计划生成相对简单就是根据用户选择的词库和每日学习量按顺序取词。复习曲线的调度稍微复杂一些我们参考了艾宾浩斯遗忘曲线的原理给每个单词设置了一个“需要复习的时间点”到期后把单词推送到用户的待复习队列。这个逻辑拆成几步实现用户学完一个新单词后后台为这条学习记录生成N个复习节点比如第1天、第3天、第7天、第15天。每天定时任务扫描“当天需要复习的单词记录”生成用户当天的复习任务。用户在App端完成复习后更新掌握程度评分并根据评分决定是否进入错词本。这里有一个比较稳妥的经验复习计划不要完全自动生成后就不管了要给用户一定的选择权。我们最终的方案是每天默认给用户20个复习单词但用户可以自行更换“太简单”的单词避免复习任务积压导致用户流失。3.5 口语练习模块语音评测与TTS方案口语练习模块是这个项目里技术挑战最大的一个模块因为语音评测的准确度直接决定了用户对这个功能的信任度。我们的方案是分层设计录制音频后先做降噪和格式转换然后调用语音评测接口返回总分、流利度、准确度、完整度四个维度分数前端再把评测结果以可视化的方式展示给用户。整体流程是用户点击录音Android端通过MediaRecorder录制PCM格式的音频。录音完成后上传到后端后端统一转成WAV格式后调用评测接口。评测结果落库用户在历史记录中可以看到每次口语练习的得分和评语。同时接入TTS接口用户可以点击示例发音听到标准发音后再跟读。一个我踩过的坑Android模拟器上是没法正常调用录音功能的一定要用真机调试否则音频采集这一块的问题调试起来会非常痛苦。4. 用户端Android App的实现重点4.1 前端架构选型MVVM与Retrofit的结合Android端的架构用的是目前比较主流的MVVM模式。UI层用Jetpack Compose处理页面渲染和交互ViewModel层负责维护UI状态、调用Repository获取数据Repository层封装了网络请求和本地缓存的调用。网络通信框架选择了Retrofit OkHttp这个组合在Android生态里的地位基本等同于后端生态里的Spring Boot稳定性和生态配套都是最好的。Retrofit相关配置中有一个细节值得注意OkHttp的拦截器一定要区分业务拦截器和日志拦截器。业务拦截器负责统一添加Token、处理公共参数、对特定错误码做统一处理比如401时自动刷新Token日志拦截器只在Debug包开启Release包不能打印日志避免泄露用户信息。4.2 离线缓存与断网体验优化做在线学习类App离线能力是不能忽略的一点。设想一个场景用户在地铁上、飞机上或者网络信号不好的地方想复习单词结果App因为断网直接打不开那体验一定是很差的。所以我们做了一个相对完整的离线缓存方案单词数据和词库数据支持下载到本地SQLite数据库下载后即使完全断网用户也能正常学习、复习单词。用户的学习记录先写入本地数据库联网后在后台自动同步到服务器同步成功后会返回确认信号本地数据标记为已同步状态。帖子列表做了分页缓存用户已经浏览过的帖子在断网状态下仍然可以正常查看。数据同步这里有一个要重点处理的细节同步冲突处理。用户可能在不同设备上操作后端怎么确定以哪份数据为准我们的策略比较务实以“最后修改时间”为准后修改的覆盖先修改的。如果业务需要更复杂的多端合并那就要引入版本号机制了但那属于比较重型的设计前期需求没有明确的话不建议过度设计。4.3 社区交流系统的点赞、评论与通知联动社区交流模块是连接“学习”和“交流”两个核心定位的关键它的实现上有几个需要打通的点。点赞功能我们做了防重复提交处理Redis中存储post_id user_id的点赞标记用户点赞时先判断是否已点过防止刷数据同时前端做了动画效果来提升交互体验。评论功能支持楼中楼回复也就是用户可以对评论再进行回复社区氛围会更活跃。最费心思的是通知联动。用户发了一篇帖子后如果收到新的评论、点赞、收藏App需要实时收到消息通知。我们选择的方案是WebSocket长连接 离线消息推送结合App在前台时维护WebSocket连接有新的互动消息实时推送App在后台或杀死状态时通过第三方的推送通道发送离线通知。这里我想强调的一点是WebSocket连接的管理和心跳重连机制一定要处理好否则会出现一种很尴尬的情况用户看着消息列表什么反应都没有但服务器端数据显示消息早就推送成功了。这种问题排查起来非常费时倒不如在最开始就把心跳和重连的细节想清楚。5. 管理后台Vue3的实现与前后端联调要点5.1 管理端的页面结构与权限控制管理后台用的是Vue3 Element Plus Vite这套组合。页面结构上整体是一个典型的后台布局顶部导航栏显示管理员信息和快捷入口左侧树形菜单承载功能导航仪表盘、用户管理、词库管理、帖子审核等右侧主内容区是各个业务组件的容器。权限控制方面管理员的角色分成了超级管理员和普通管理员。超级管理员可以管理其他管理员账号普通管理员只能处理被分配到的业务模块。实现上通过Vue Router的全局前置守卫动态注册路由表、动态添加异步路由组件并在菜单层面做了按钮级别的权限控制。说白了就是前端页面可以都打包进去但能不能访问是路由守卫说的算能不能操作按钮是自定义指令说了算。5.2 表格页面的搜索、分页与批量操作后台管理系统里出现频率最高的页面就是表格页。这类页面的开发模式我们提炼了一套标准化写法查询条件筛选表单 表格展示 分页条 批量操作按钮 行内操作按钮。比如用户管理页查询条件包含注册时间范围、学习等级、用户状态表格列包含用户ID、头像、昵称、手机号、等级、积分、状态、注册时间、最后活跃时间行内操作包含查看详情、编辑资料、封禁、重置密码批量操作包含批量导出。这套模式看起来简单但有几个性能优化的注意点不要一次把所有用户数据都查出来一定要分页查询数据量大的时候后端接口的排序操作尽量放在SQL里做不要前端排序。在实际项目中我们就有过因为前端做全字段排序导致页面卡顿的尴尬经历。5.3 数据看板的图表设计管理后台的仪表盘页面需要展示平台的核心运营数据。我们用ECharts做图表包括折线图近30天新增用户趋势、饼图用户英语等级分布、柱状图各词库学习人数、环形图学习目标占比、排行表热门帖子Top10。数据看板这个模块有一个重要的经验指示大盘核心数据的数值卡用户总数、今日活跃、今日新增、今日学习人次要单独拉接口并且做缓存比如3分钟缓存一次避免高频刷新把数据库打崩。图表背后的数据聚合查询也不要直接在业务表上做定时任务每小时汇总到专门的统计表里前端图表接口只查统计表响应时间能控制在100ms以内。6. 部署方案、常见问题与踩坑实录6.1 服务器部署与项目上线流程部署这块我们用的是常规的Linux服务器 Docker容器化方案。后端网关和生产服务跑在Docker里MariaDB和Redis直接以容器方式部署MinIO对象存储用来存图片和语音音频文件。上线部署时踩过不少坑挑几个典型的说说。第一服务器选型不能只看配置要重点看带宽和回程线路质量尤其是语音文件上传下载这个功能带宽小了用户体验会非常差。第二数据库的账号权限不能给太高Docker容器里的数据库账号能用最小权限就最小权限一旦容器被渗透权限过大就容易出大问题。第三一定要配日志文件的定期清理任务不然时间长了磁盘会被日志占满导致服务异常。6.2 JWT Token过期处理与问题排查前面提到Token会过期过期后客户端需要拿RefreshToken去换新的Token。这个流程在实际线上运行中经常出问题我排查过好几次比较典型的情况是客户端并发发起多个请求同时因为Token过期返回401多次刷新Token导致旧的RefreshToken失效。处理策略是客户端做请求拦截器当遇到401时加一个并发锁只允许一个刷新Token的请求通过其他请求等待完成后重试原请求。这个逻辑细节在Android客户端和Web前台都要做一遍排查起来非常耗时。6.3 语音评测准确度问题与优化方向口语练习模块上线后用户反馈最多的问题就是语音评测“不准”尤其是对带口音的用户评分结果明显偏低。我们排查后发现语音评测接口本身的准确度是有一定局限性的完全依赖第三方接口解决不了所有情况。后续的优化思路主要在两个方向一是加入音素级别的纠错信息回传告诉用户具体哪个单词的哪个音发错了这样用户能针对性练习比单纯给一个总分体验好得多二是增加“录音回放”和“标准发音对比”功能先让用户自己听出差异再自我纠音。这两项优化做完后用户对口语练习的满意度有明显提升。所以这里也建议做类似功能的朋友不要过度依赖技术评分产品交互上的体验优化同样重要用户感知到的好不好用和技术上上下游的准确率是一样重要的。6.4 微信小程序等后续扩展方向这个项目的架构在后端接口和数据库设计上没有绑定Android客户端所以后续如果要做微信小程序版本后端接口是可以复用的Android端的很多业务逻辑也能迁移到小程序端。这是一开始就规划好的JWT无状态鉴权天然支持多端接入算是比较明智的设计决策。6.5 项目管理与开发排期的一些参考最后简单说说排期。类似规模的项目如果团队是“1个后端 1个Android 1个前端 1个产品/测试”的核心阵容比较稳妥的周期是8到10周。具体分配上需求细化和技术方案设计尽量控制在1周内后端核心接口开发和联调安排3周左右Android端和前端同步开发3周剩余的2到3周留给测试、修复和上线部署。不建议为了赶进度压缩需求细化和测试的时间这两个阶段省的功夫后面会在线上以另一个方式还回来。我在实际开发中做这个系统最大的体会是技术和业务从来不是分开的东西。技术能给你以更快速度实现这一切的基础但对教育产品的理解、对用户学习体验的关注才是别人唯一难以模仿的护城河。如果你也在做类似的项目希望我的这些经验和踩坑记录能帮你少走一些弯路。
阅读完成 · 觉得有帮助？
