最近在整理一套前后端分离的在线英语阅读分级平台项目技术栈正好是SpringBootVueMyBatisMySQL前端部分还结合原生htmlcss做了不少阅读器层面的定制。这套系统本身功能不算特别庞大但从用户注册、等级测评、分级书单推荐到阅读器交互、生词管理、阅读进度追踪链路非常完整很适合正在学前后端分离、想把Java后端和Vue前端彻底串起来的朋友拿来练手也适合直接作为毕业设计或个人作品集的底子。先说下这套系统解决了什么问题。市面上常见的英语阅读产品要么是内容固定、没法按用户水平推文章要么是阅读体验单一、缺少学习闭环。这个平台的核心思路是先通过一套测评题估算用户的词汇水平再映射到分级等级之后系统按照等级推荐文章用户在阅读器里可以点击查词、收藏生词、记录阅读进度后台还有一个管理端用来维护文章库和等级配置。我用SpringBoot做纯API后端Vue负责前端页面渲染MyBatis帮我把复杂的SQL查询和数据映射管起来MySQL承担数据存储整个项目分成两个独立工程来开发联调时非常清爽。下面我按设计思路、核心实现、部署流程、踩坑经验和扩展建议这几个维度把整套项目从零到部署的完整过程讲一遍。1. 项目整体设计与技术选型思路1.1 为什么选SpringBootVue做前后端分离如果你之前做过传统的JSP项目你一定体会过那种页面和服务端代码缠在一起的痛苦。前端改个按钮颜色后端要重新编译打包稍微复杂一点的页面JSP里全是Java代码块读起来非常折磨。前后端分离的核心价值就是把页面展示和数据提供彻底拆开前端只负责用Vue把数据渲染成页面后端只负责用SpringBoot提供JSON数据接口。两边可以并行开发后端把接口文档定好前端用mock数据就能先跑起来效率翻倍。具体到这套平台选型逻辑是这样的SpringBoot负责后端API它内置了Tomcat不用额外配置外部容器一个jar包就能跑起来对新手部署非常友好。Vue负责前端单页应用配合Vue Router实现页面跳转配合axios做HTTP请求组件化开发让阅读器等复杂页面可以拆成多个独立的子组件维护。MyBatis作为持久层框架相比JPA那种全自动ORMMyBatis允许你手写SQL这在需要多表关联查询、动态条件拼接比如按文章等级关键词组合筛选时非常灵活SQL可控性高也方便做性能调优。MySQL做数据存储虽然是轻量级关系型数据库但对于阅读平台的用户、文章、记录这类结构化数据完全够用而且部署成本低、生态成熟、出问题资料一搜一大把。标题里特别提到的htmlcss很多人会疑惑Vue本身不就是写页面吗为什么还要强调htmlcss实际上Vue单文件组件里的template部分本质上就是html结构style部分就是css样式。这个项目在阅读器模块上没有盲目引入大型UI组件库而是用原生html结构加手写css来实现文章排版、生词高亮、音标注音这些细节。原因是阅读类场景对排版的要求非常特殊现成组件库很难满足眼睛友好的需求自己用css控制字间距、行高、段距反而更精准。1.2 分级阅读的核心逻辑拆解在线英语阅读平台和普通博客、资讯站最大的区别在于它有分级这个业务核心。分级体系看起来简单实际落地时需要考虑这几个问题第一个问题用户水平怎么来不可能让用户一上来就填写我的英语水平是几级这不现实。这个项目采用的方式是词汇量测评从词库里随机抽取不同难度区间的单词让用户做选择题认识/不认识或者选中文释义然后根据答对比例估算词汇量再映射到对应的阅读等级比如L1-L6。这个方案虽然不如专业测评精确但胜在实现简单、用户体验好五分钟内就能完成。第二个问题文章怎么分级每一篇文章入库时除了标题、封面、分类、内容这些常规字段还有一个核心字段叫difficulty_level由内容管理员在后台录入或编辑时指定。更进阶一点的做法是可以做一个文本分析工具扫描文章单词表统计高频词分布和平均句长自动给出建议等级但那是后话了后面我会在扩展建议里细说。第三个问题推荐逻辑怎么做一个基础但有效的推荐策略是优先推荐当前用户等级±1范围内的文章再结合阅读完成度、收藏量、点击量做热度排序。换句话说SQL里既有等级匹配的硬性条件又有行为数据的软性加权两端配合用户看到的书单才不会太简单无聊或者太难打击积极性。1.3 前端项目结构与技术分工Vue前端工程我采用的是Vue 2.6版本配合Vue Router 3.x和Vuex 3.x为什么没用最新的Vue 3因为SpringBoot后端要的是稳定成熟的技术组合Vue 2的社区资料量最大遇到问题几乎都能搜到答案教学和毕设场景下踩坑成本最低。Node环境建议使用14.x或16.x版本避免16-18升级过程中node-sass编译报错的问题。前端工程结构大致是这样的frontend/ ├── src/ # 前端源码目录 │ ├── api/ # 接口请求封装按模块拆分login.js、article.js、user.js │ ├── assets/ # 静态资源css、图片、字体等 │ ├── components/ # 公共组件分页组件、弹窗组件、阅读器组件 │ ├── router/ # 路由配置文件含路由守卫 │ ├── store/ # Vuex状态管理存储用户信息、token、阅读进度 │ ├── views/ # 页面级组件登录、注册、首页、书城、阅读器、生词本、管理后台 │ ├── App.vue # 根组件 │ └── main.js # 入口文件 ├── public/ # 静态资源目录 └── package.json # 依赖管理路由和状态管理是前端两个比较关键的设计点。路由守卫要拦截非法访问用户在未登录状态下直接访问阅读器或生词本会被重定向到登录页Vuex里保存登录token和用户等级这样不同页面切换时用户的等级信息不用反复请求后端接口。2. 数据库设计与核心接口实现2.1 数据表设计与业务字段规划数据库是这套系统的地基表结构设计是否合理直接决定后续开发效率。我梳理了以下核心表用户表、测评记录表、文章表、文章内容表、阅读记录表、生词本表。下面逐张表说明。用户表t_user的核心字段包括id、username、password存MD5加密后的密文也可以用BCrypt、current_level当前阅读等级、vocabulary_size估算词汇量、avatar、create_time。业务上用户等级是动态变化的当测评次数增加、阅读完成文章数变多后系统可以重新评估等级所以在设计时不要把等级做成固定值。测评记录表t_assessment要记录每次测评的明细user_id、score、estimated_vocabulary、result_level、answers_json、create_time。其中answers_json字段用JSON格式存储用户每一道题的答题记录这样做不需要额外建一张答题明细表简化结构对测评这种一次性写完再汇总的场景是合理的妥协。文章表和内容表我刻意拆成了两张表。t_article存储文章元信息title、category、difficulty_level、cover_image、summary、read_count、status上下架t_article_content存储文章主体内容article_id、content_html、word_count。为什么要拆因为文章列表页只需要元信息如果每次列表查询都把全文content拉出来数据量一大性能就会明显下降。分表之后列表查询走t_article阅读器打开时再按article_id去查正文这是很经典的读写分离思路。阅读记录表t_reading_record用来记录用户读到哪了user_id、article_id、progress读到百分之多少、last_position段落索引或滚动位置、update_time。生词本表t_vocabulary则存user_id、word、definition、phonetic、source_article_id、create_time。建表脚本我建议直接用Navicat或命令行执行MySQL版本用5.7或8.0都可以。如果使用MySQL 8.0需要在JDBC连接串里加上serverTimezoneAsia/Shanghai否则会报时区相关的SQLException。2.2 后端分层设计与MyBatis的灵活应用SpringBoot后端工程按照经典的Controller-Service-Mapper三层结构组织。Controller层负责接收HTTP请求、参数校验、返回统一响应体Service层处理业务逻辑比如登录时校验密码、测评时计算等级、阅读时更新进度Mapper层对接MyBatis负责和数据库打交道。统一响应体我封装成ResultT包含code、message、data三个字段前端axios拦截器里统一判断code是否为200如果不是就弹出错误提示这样做前后端接口对接特别规范。核心接口清单如下模块接口路径说明认证POST /api/user/login登录返回token和用户信息认证POST /api/user/register注册测评POST /api/assessment/submit提交测评答案返回等级结果测评GET /api/assessment/questions获取一组随机测评题文章GET /api/article/list分页查询文章列表支持等级和分类筛选文章GET /api/article/{id}获取文章详情阅读器用阅读POST /api/reading/progress保存阅读进度生词GET /api/vocabulary/list查询生词本生词POST /api/vocabulary/add收藏生词管理POST /api/admin/article/save后台保存/编辑文章MyBatis的使用方式上我采用了XML映射文件为主、注解为辅的方式。为什么要用XML因为文章列表查询包含多个可选筛选条件比如等级、分类、关键词搜索这种动态SQL场景用XML里的where和if标签简直不要太舒服。举个例子select idqueryArticleList resultTypecom.example.entity.Article select id, title, category, difficulty_level, cover_image, summary, read_count from t_article where if testlevel ! null and difficulty_level #{level} /if if testcategory ! null and category ! and category #{category} /if if testkeyword ! null and keyword ! and (title like concat(%, #{keyword}, %) or summary like concat(%, #{keyword}, %)) /if and status 1 /where order by read_count desc limit #{offset}, #{pageSize} /select这种写法比用代码层if判断拼接SQL干净得多也避免了SQL注入风险。MyBatis的Mapper接口和XML怎么关联在application.yml里配置mybatis.mapper-locations: classpath:mapper/*.xml然后接口方法名与XML里的id对应即可。2.3 阅读器前端的交互设计实践阅读器是这套系统里前端最复杂的模块没有之一。它不只是一个展示文章正文的页面而是要解决在读英语文章时怎么让查词和收藏生词不打断阅读流这个核心体验问题。我的做法有两层。文章正文用v-html直接渲染后端返回的content_html字段但在渲染之后前端通过一个highlightAndBind方法遍历正文节点把出现频率高的目标词汇用span classhighlight-word>create database english_reading default character set utf8mb4 collate utf8mb4_general_ci;utf8mb4建议一定用因为阅读器要存储音标符号utf8mb4对特殊字符支持更全面。建好库之后导入项目附带的english_reading.sql脚本把所有表和初始数据一次性搞定。注意导入时先检查SQL脚本里有没有DROP TABLE IF EXISTS没有的话手动确认库里是空的避免重复导入报错。3.2 后端打包与启动过程记录后端配置文件application.yml里需要改的就是数据库连接和端口server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/english_reading?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: root password: 你的数据库密码 driver-class-name: com.mysql.cj.jdbc.Driver mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.entity然后在项目根目录执行mvn clean package -DskipTests打包后在target目录下会生成一个english-reading-1.0.jar文件用java -jar启动即可。这里要说一个容易被新手忽略的点很多人拿到一个jar包后不知道里面是什么结构其实SpringBoot的jar是FatJar模式可以把依赖的所有第三方库都打在同一个jar包中所以这个jar的体积动不动就是几十MB。如果想确认jar包里面有哪些配置文件可以用压缩软件打开jar看看正常的源码布局在BOOT-INF/classes目录下。有一点值得展开说如果你拿到的部署包只有jar没有源码又需要改代码最实用的办法是拿反编译工具比如CFR或IDEA自带的反编译插件把jar还原成java文件参考但反编译出的代码和原版有差异不建议直接把反编译结果当源码回编。我更建议的做法是把jar当作参考工具核心类看逻辑思路真正要改功能时还是找公司或项目方要原始工程用源码重新打包发布最稳妥。单纯的jar包可以直接在当前服务器运行也可以是nohup java -jar xxx.jar app.log 21 放到后台运行这样即使退出终端服务也不会停。3.3 前端构建与Nginx部署要点前端构建之前先检查一下接口地址配置。在Vue项目里我用了一个.env文件管理环境变量VUE_APP_BASE_URL/api所有axios请求的基础路径都是/api这个设计是为了配合Nginx反向代理做同源访问。本地开发时在vue.config.js里配置devServer代理把/api转发到http://localhost:8080devServer: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } }生产部署时构建命令很简单npm install npm run build构建成功后生成的dist目录就是纯静态文件。把dist目录上传到服务器指定目录比如/usr/share/nginx/html/english-reader然后配置Nginx站点server { listen 80; server_name your-domain.com; root /usr/share/nginx/html/english-reader; index index.html; location / { try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }第一处location /里的try_files是历史路由History模式的关键配置没有这行用户刷新页面时会报404第二处location /api/把前端请求转发给后端Java服务实现跨域免配置不需要在后端写CORS过滤器。Nginx配置改完之后执行nginx -t检查语法然后nginx -s reload生效。到这里整个前后端分离项目就算正式上线了。4. 常见问题与排查技巧实录这套项目从头到尾做下来我踩过的坑还真不少。很多问题在本地开发时不会暴露一到部署环境就冒出来我把高频问题整理成一个速查表希望你能少走弯路现象可能原因解决方案后端启动报连接数据库失败MySQL未启动、密码错误或MySQL 8.0时区问题确认mysql服务运行确认密码连接串加serverTimezoneAsia/Shanghai前端接口全部报跨域错误本地联调时没配置代理或后端没开CORSdevServer里配置proxy代理生产环境的跨域问题应优先用Nginx反向代理解决MyBatis报Invalid bound statementMapper接口与XML没有正确映射检查XML文件是否在mapper-locations指定目录检查XML中namespace是否等于接口全限定名Vue打包后页面404没有配置try_filesNginx增加try_files $uri $uri/ /index.html;用户登录后刷新页面状态丢失token只存在内存里登录成功后把token持久化到localStorageVuex初始化时从localStorage读取阅读器里生词点击没反应事件委托对象判断不正确检查target.classList.contains(highlight-word)MySQL中文乱码数据库字符集不是utf8mb4建库时指定utf8mb4连接串加characterEncodingutf8除表格里的常规问题还有两个特别值得单独拿出来说的细节。第一个是SpringBoot的CORS配置问题。本地调试如果不想配前端代理可以在后端写一个CorsFilter但要注意如果同时使用Nginx反代和后端CORS配置可能会产生重复跨域头Access-Control-Allow-Origin出现两次反而导致浏览器报错。所以我个人的习惯是开发环境用前端代理生产环境用Nginx反代后端不写CORS这样链路最干净。第二个是用户登录状态的问题。这套系统用的是JWTJson Web Token方案登录成功后后端签发一个token返回给前端前端存在localStorage然后每次请求时在axios拦截器里把token加到Authorization请求头上。后端通过Spring拦截器HandlerInterceptor统一校验token放行登录、注册、文章列表等公开接口。新手经常犯的错是在拦截器里把OPTIONS请求也拦截掉导致前端预检请求失败需要在拦截器里先判断请求方法。public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { if (OPTIONS.equalsIgnoreCase(request.getMethod())) { return true; // 放行预检请求 } // 其他逻辑 }顺便提一嘴生词本的音标显示偶尔会出现乱码根本原因基本可以锁定在两点第一数据库表字符集不是utf8mb4第二页面css没有设置对应的字体族比如Lucida Sans Unicode或IPA字体。定位方法也很简单用Navicat打开表看看音标字段原文是否正常如果数据库里是正常的、页面乱码那就是前端展示层的问题如果数据库里已经乱掉那就是字符集的问题。5. 项目扩展方向与二次开发建议这套分级阅读平台做完之后我认为它最大的价值不是能够跑通而是留出了足够多的扩展口子。如果你想在这个基础上继续做得更出彩可以从以下几个方向切入。5.1 数据统计与学习报告当前平台里已经积累了用户测评、阅读记录、生词本三类原始数据。可以做一个学习报告页面用ECharts渲染用户的阅读时长趋势图、等级成长曲线、词汇量变化图。后端增加一个日报聚合接口按天维度统计用户阅读的篇文章数和累计字数。这个功能对用户黏性提升非常明显——我在实际使用中观察到用户一旦看到上周读完了5篇文章累计阅读8600词生词收藏32个这样的数据明细会更愿意持续回访。5.2 引入简易的智能推荐文章推荐的粒度可以更细。目前是按用户等级粗筛升级一点的做法是计算文章的难度系数从均句长、单词平均长度、常用词占比几个维度打分然后用相似度算法把用户读过的文章和文章库做匹配。这里的难度系数计算可以在文章入库时由后端任务触发不必实时计算用Quartz或Spring Boot内置的Scheduled定时任务即可。5.3 多端适配与性能优化现在的前端页面虽然响应式但主要面向桌面设备。考虑到英语阅读场景在手机和平板上的使用频率更高建议做移动端适配。此外文章内容和生词数据都有明显的读多写少特点可以引入Redis做缓存文章列表接口和生词释义接口的响应时间能从几百毫秒降到几十毫秒。缓存策略上文章元信息用keyarticle:list:level:{level}:page:{page}文章正文用keyarticle:content:{id}生词解释用keydict:{word}更新文章后主动删除对应缓存。最后再补一个很真实的运维心得。项目上线后最怕的就是数据库出问题尤其是MySQL的数据备份。我给这个平台写了一个简单的备份脚本backup.sh每天凌晨3点用mysqldump导出全部数据并保留最近7天的备份文件配合crontab执行。别小看这个脚本哪天误删了表或者服务器被重置你才知道一个及时备份能救命。另一个不得不提的习惯是每次改代码之前先在本地把老版本jar包和数据库脚本留底增量发布后如果发现问题可以快速回滚。分级阅读这种教育类系统内容的完整性和用户数据的连续性比花哨功能重要得多先把地基打稳再想怎么盖高楼。