企业官网建设流程全解析

做管理系统的源码其实不新鲜，SpringBoot+Vue这个组合大家见得太多了，但“在线英语阅读分级平台”这个方向有点意思。市面上大多数阅读类项目要么只做了文章展示，要么把分级作为一个标签挂在文章上，真正把“分级”当成一套完整业务逻辑来设计的并不多。这套系统我整理的时候，核心思路就是让阅读行为、文章难度、用户水平三者形成闭环——你读的文章会反过来修正你的级别，你的级别又会决定你接下来能看到什么内容。前端用Vue负责页面交互和数据展示，后端是SpringBoot配合MyBatis处理业务逻辑，数据库上MySQL存储全部业务数据，工程结构很清楚。

这篇文章我会从需求拆解讲起，把系统架构、数据库设计、核心业务实现、前后端联调以及部署上线的经验全部过一遍。如果你正在找SpringBoot+Vue的完整项目练手，或者想在团队里做一套英语阅读类产品，这篇文章里提到的思路和踩坑记录应该能帮你省不少时间。

1. 项目概述与核心需求拆解

1.1 在线英语阅读分级平台到底做什么

先把这个平台的业务边界说清楚。它面向两类用户：一类是学生读者，他们登录后可以查看文章、选择阅读计划、完成任务并查看自己的水平测评结果；另一类是运营管理员，负责维护文章库、管理用户、配置分级规则、查看阅读统计。

这里的核心不是“文章列表”那么简单，而是分级阅读的完整闭环。具体来说，文章在录入时要标记难度级别，读者的水平要通过测评得出，系统根据这两个数据做匹配推荐。读者读完之后产生阅读进度、测评分数、生词记录，这些数据又会回流到用户模型里，用来调整后续推荐策略。

整套系统里最有业务价值的是两个模块：分级推荐算法和用户测评体系。前者决定了一篇文章在什么时机推给什么水平的读者，后者决定了读者的初始等级怎么定、多长时间重新评估一次。设计这两个模块时不能用简单条件判断糊弄过去，得考虑实际使用中的边界情况，比如新用户没有测评数据怎么办、文章被运营临时下架后推荐池如何处理。

1.2 技术选型的取舍逻辑

先说为什么主栈是SpringBoot。这个项目要求“企业级”，这个词落到技术上就意味着权限控制要完整、事务要可控、部署要可靠、代码要易于多人协作。SpringBoot的生态足够成熟，基于它做RBAC权限、接口鉴权、统一日志、异常处理都很顺手，团队招人也好招。

Vue作为前端框架的理由同样明确。这类管理平台页面交互密集，表格、弹窗、表单校验、动态路由都是刚需，Vue的响应式模型和组件化开发模式非常适合这种场景。搭配Vuex做状态管理，再配合vue-router做前端路由控制，整个前端工程可以做得很规整。有人问现在不是有Vue3吗，为什么用Vue2？我接触的很多企业项目还在Vue2生态里，组件库成熟稳定，团队迁移成本高，选Vue2是务实的做法，但不妨碍你拿到源码后自行升级。

MyBatis和MySQL组合没什么好争论的。MyBatis把SQL写在XML里，复杂查询控制力强，JOIN、子查询、批量更新都好写，比纯JPA更灵活。MySQL在数据量百万级、单机部署的情况下完全够用。项目里用Druid连接池做数据库连接管理，配合监控页面排查慢SQL很方便。

提示：这套选型不追求技术上的“最新最炫”，而追求“稳定、易维护、好解释”。如果你准备拿这套系统作为项目面试的素材，建议把选型逻辑讲清楚，面试官通常不希望听到“因为大家都在用”这种回答。

2. 系统总体架构与数据库建模

2.1 后端分层架构

后端不是简单的Controller-Service-DAO三层，实际落地时我加了两个层次：通用基础设施层和业务领域层。Controller只做参数接收和响应封装，Service层处理完整业务逻辑，DAO层通过MyBatis接口与XML映射访问数据库，通用基础设施层包含统一返回体、全局异常处理、JWT工具类、跨域配置等。

包结构大致如下：

com.example.readplatform ├── common // 通用返回体、异常、工具类 ├── config // 配置类（CORS、安全、拦截器） ├── security // 登录鉴权、权限注解 ├── controller // 前端接口入口 ├── service // 业务逻辑层 │ ├── article │ ├── user │ ├── assessment │ └── recommend ├── dao // MyBatis接口 ├── entity // 实体类 ├── vo // 视图对象 ├── dto // 入参对象 └── aspect // 日志切面

分层原则有一条要特别注意：VO、DTO、Entity必须分开。很多项目图省事把一个对象从数据库一路传到前端，短期代码少，后期维护极其痛苦。打个比方，数据库表如果有password字段，Entity里映射出来了，而你直接把Entity返回给前端，密码就漏了。项目中用VO做出口，Entity只在Service和DAO之间流动，这种事情从根本上就能避免。

2.2 前端页面结构

前端工程是基于Vue脚手架的SPA应用，所有页面组件都放在src/view下。针对不同角色做了不同页面集：学生端可以看到阅读大厅、我的书架、阅读任务、学习统计；管理端看到控制台、文章管理、用户管理、分级配置、数据报表。前端路由统一在router配置中管理，同时嵌套路由和动态路由组合使用——基础页面用静态定义，包含权限的页面用addRoutes动态注入。

状态管理这块，Vuex里维护了userInfo、token、permission列表和应用级配置。为什么不把token放在localStorage直接读？因为多个模块都要拿用户身份做条件分支判断，集中管理更安全，也方便在请求拦截器里统一设置请求头。接口层的封装也有讲究：所有请求都走独立封装的request工具类，统一带token、统一处理401跳转、统一弹出后端返回的错误信息。

2.3 核心表结构设计

我把数据库表分成四组：用户域、内容域、业务域、行为域。用户域管user、role、user_role、user_level_log；内容域管article、article_category、article_content；业务域管reading_plan、task、assessment_question、assessment_record；行为域管reading_progress、vocabulary_note、search_log。下面挑三张核心表说。

用户表：

CREATE TABLE `user` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `username` varchar(50) NOT NULL COMMENT '登录账号', `password` varchar(255) NOT NULL COMMENT '加密后的密码', `nickname` varchar(50) DEFAULT NULL, `avatar` varchar(255) DEFAULT NULL, `email` varchar(100) DEFAULT NULL, `current_level` tinyint(4) NOT NULL DEFAULT '1' COMMENT '当前阅读等级', `status` tinyint(4) NOT NULL DEFAULT '1' COMMENT '1启用 0禁用', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

文章表和文章内容表我做了拆分。主表存标题、等级、分类、摘要、封面图、上下架状态、阅读数等，内容独立一张表存正文。这样设计的好处是列表查询不需要带着大字段走，内容按需加载，性能压力小很多。

等级日志表记录用户每次等级变化的痕迹。这个表特别重要，因为等级调整会直接影响推荐结果，如果不留痕，后期出现“用户等级突然被提升”这类问题就无从排查。

注意：创建时间创建者、修改时间修改者这类审计字段，建表时必须有，这是企业级项目的基本要求。线上出问题的时候，这些字段就是救命稻草。

3. 核心功能模块的实现要点

3.1 登录注册与权限控制

登录这块直接用了JWT方案。用户输入账号密码后，后端校验通过生成token并返回给前端，前端在每次请求头里携带。token的有效期做成了两小时，过期后前端拿到401状态码就引导用户重新登录。

权限控制的后端落地方式是对接口加注解。在需要权限的Controller方法上加一个@RequirePermission("article:edit")这样的注解，由切面拦截处理。切面里拿到当前用户的权限集合，跟注解要求做匹配，不通过就抛出权限异常。前端把按钮级别的权限指令封装成自定义指令，比如v-permission="'article:delete'"，没有权限的删除按钮直接不渲染。

有个细节值得提一下：默认密码问题。管理员导入用户时，系统生成初始密码abc@123456，用户首次登录后会强制要求修改。这个设计看起来简单，但避免了“系统默认密码是什么”这种烂大街的漏洞。

3.2 文章管理模块

文章录入这个功能，一开始做得很传统：后端接收表单字段直接存。但实际使用中发现，运营人员需要在文章里插入大量排版标记、生词注释和段落样式，纯文本的方式根本不够用。后来升级成富文本内容加HTML格式存储。

入库前必须做内容清洗，这是很多人忽略的环节。富文本粘贴进来的内容经常包含字体样式、行内样式、甚至脚本片段，如果直接保存，页面渲染时轻则样式错乱，重则触发安全风险。所以我写了专门的清洗工具，用Jsoup来解析HTML，只保留安全标签集。

文章和等级的关系也不简单。同一篇文章可以同时适配多个等级，比如一篇科普文章难度适中，可以标记为“A级、B级都适合”。数据库中存储的就是多个等级映射表，推荐引擎查询时会用多级过滤。运营人员给文章打等级的时候，系统会显示参考指数——比如文章的平均单词长度、句长等统计信息，辅助人工判断。

3.3 分级推荐逻辑

推荐模块是整个系统的核心，我采用了规则引擎加权重积分的方式。用户有一个当前等级，每篇文章有多个适配等级，基础匹配做的是等级过滤。但光有等级过滤不够，用户读了很多同一类型的文章会产生偏好，于是引入了兴趣维度。

推荐服务的处理流程是这样的：用户打开阅读大厅，后端获取用户等级、最近阅读记录、常用分类，然后从文章库里捞取符合等级条件且用户没读过的文章，按照“兴趣匹配度+文章质量分+运营置顶权重”综合排序。这个排序分数不是一张表里静态存储的，而是每次实时算出的分数。

推荐结果会做缓存复用。大厅页面用户会频繁刷新，如果每次都实时跑全量计算，数据库扛不住。我用Redis做了推荐结果的短时缓存，过期时间设为300秒。用户刷新后默认走缓存，请求量大一些也不影响DB。

3.4 阅读进度与词汇测评

进度追踪方面，前端每30秒向后端汇报一次当前阅读页面的状态。会话表记录开始时间、当前进度、最近心跳时间。如果用户中途退出，下次进入时前端根据后端返回的进度比例自动滚动到对应位置。

词汇测评模块考的是生词本和等级评估的结合。阅读中用户点击不认识的单词，会被收集到生词本中。定期安排一套测评卷，题目包含单词拼写、词义匹配和完形填空，做完后系统根据正确率给出参考等级。这个新等级并不会直接覆盖用户等级，而是生成一条待确认记录，由管理员或系统规则审批后才生效。这套设计在实际使用中很合理，因为测评时用户状态可能很随机，一次测评就定等级会有误差。

4. 关键代码与联调实战

4.1 后端接口与MyBatis映射

先看一个推荐查询的SQL实现。多等级匹配的文章要查出来，同时过滤已读和已下架，这在MyBatis XML里可以用循环标签写：

<select id="selectRecommendList" resultType="com.example.readplatform.vo.ArticleVO"> SELECT a.id, a.title, a.level, a.category_id, a.cover_image, a.summary, a.read_count, a.status, a.create_time FROM article a WHERE a.status = 1 AND EXISTS ( SELECT 1 FROM article_level al WHERE al.article_id = a.id AND al.level_code IN <foreach collection="levelList" item="level" open="(" separator="," close=")"> #{level} </foreach> ) AND NOT EXISTS ( SELECT 1 FROM reading_progress rp WHERE rp.article_id = a.id AND rp.user_id = #{userId} ) <if test="categoryId != null"> AND a.category_id = #{categoryId} </if> ORDER BY a.create_time DESC LIMIT #{limit} </select>

这段SQL的关键是双重EXISTS子查询。第一层是等级过滤，第二层是已读排除。在数据量不大的项目里，这种写法性能没问题，而且比拆多个查询再内存聚合清爽得多。注意分页参数limit直接拼在末尾，用LIMIT关键字性能最佳。

Service层的事务控制主要落在两个地方：一是用户提交阅读进度时，同时更新阅读进度表和阅读统计表，必须加@Transactional保证数据一致；二是运营批量上下架文章，影响文章表、推荐缓存、阅读任务多张表，同样需要事务包裹。

4.2 Vue前端状态管理与页面交互

阅读页面的设计需要重点说一下。阅读页不是一个普通的管理列表，它要做到“沉浸式阅读”：左右两侧有工具栏和翻译面板，中间是内容区。组件拆分成阅读区域、生词面板、翻译弹窗、目录导航四个部分，通过Vue的组件通信机制协同。

状态管理上用了Vuex的modules方式拆分，分别管理用户信息、当前文章状态、生词列表、面板开关状态。页面每次加载文章时，先调用获取文章详情接口，再调用获取用户进度的接口，两个接口请求完成后再渲染内容区，避免出现先渲染全部内容再跳卷的视觉跳跃。

生词翻译这块，前端调用翻译接口时传入原文和当前语境，后端返回单词释义、音标和例句。点按生词后加入生词本，这个操作是异步的——不能因为网络问题影响用户阅读流。

4.3 API规范与联调细节

接口设计要做到统一。返回体结构定义为code、message、data三重结构，成功时code为200，异常时code为非200，HTTP状态码基本只用200、401、403、500四类。当时踩过一个坑：前端axios拦截器之前只判断HTTP状态码，后端返回业务异常code时，前端却当成成功处理了，后来在前端拦截器里先判断response.data.code是否为200，再做下一步处理。

联调时最大的痛点来自字段命名不一致。后端的驼峰命名在数据库里是全小写下划线，JSON返回时是驼峰，如果前后端字段命名习惯没对齐，页面就会显示undefined。后来我们约定所有的接口请求和响应字段统一使用驼峰格式，数据库映射由MyBatis环境配置自动转换，这个争执再无出现过。

实操建议：准备一个接口文档工具接口清单，把每个接口的入参、出参、错误码示例整理成表格。团队协作时，接口文档比聊天记录里的口水解释可靠一万倍。

5. 常见问题与避坑指南

5.1 跨域问题与安全拦截的冲突

前后端分离项目跨域是第一个绕不开的坎。后端配置了CORS后，前端请求仍然被拦截。排查后发现，Spring Security的过滤链在CORS配置之前就把请求拦截了，因为预检请求OPTIONS没有放行。修复方案是在安全配置中明确放行OPTIONS方法，并让CORS配置在安全过滤器前生效。

配置的关键代码：

@Bean public CorsFilter corsFilter() { CorsConfiguration config = new CorsConfiguration(); config.addAllowedOriginPattern("*"); config.addAllowedMethod("*"); config.addAllowedHeader("*"); config.setAllowCredentials(true); UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration("/**", config); return new CorsFilter(source); }

可能有人问，既然前端通过代理转发就能解决跨域，为什么生产环境还保留CORS配置？因为生产环境中前端Nginx和API服务可能部署在不同域名下，必须在服务端做跨域支持。前端代理只适合本地开发。

5.2 文章大字段的查询性能

文章内容是TEXT类型，如果列表接口误把正文一起查出来，用户量一大，数据库IO会迅速拉高。我在列表和详情两个接口使用不同DAO方法：列表方法只查主表字段，内容字段用延迟字段和select *从简处理；详情方法才用主表和内容表的JOIN查询把正文查全。

另外正文的传输量对大带宽有压力。线上反馈详情页偶尔加载慢，排查后发现Nginx的gzip没有开启。开启gzip压缩后，文章内容型接口的传输体积降了70%以上。

5.3 MyBatis级联查询的坑

业务中要查询用户列表并展示他们的最近一次阅读文章，如果直接在关系型数据库层面做强关联查询，在数据量大时会出现笛卡尔积的膨胀。项目里我改成两段式查询：先查用户列表，然后收集用户ID集合，再用IN查询批量获取阅读记录，最后在Service层做内存映射拼接。

这样做的原因很实在：强关联查询在MyBatis中resultMap的嵌套映射写起来麻烦，多层嵌套以后SQL维护成本剧增，而且一旦某层查询结果为空，单表查不出完整列表就会出问题。两段式查询虽然多了一次往返，但在数据量可控范围内性能完全能接受，代码逻辑也清晰。

5.4 用户状态的边界场景

权限控制中踩过比较典型的坑是用户被禁用后，已持有的token依旧有效。JWT的无状态特性让它无法在签发后立即使之失效，如果用户被管理员禁用还能继续访问接口，这是严重漏洞。

修复方案是在鉴权过滤器里除了校验token合法性，还要查一次用户状态，确认status为启用时才放行。再加一层缓存，把禁用用户的ID列表存到Redis中，每次校验时快速查一下，避免每次查库。

6. 部署上线与运维心得

6.1 本地环境配置清单

项目跑起来需要以下环境：JDK 1.8、Maven 3.6+、MySQL 5.7+、Node.js 10+、Redis 5+。数据库初始化时直接把项目中的schema.sql和data.sql导入即可，里面建好了所有表结构和基础数据，包括默认管理员账号和三张测试文章表。

前端依赖安装时需要注意版本兼容。项目里用的Vue核心是2.6版本，ElementUI是2.15版本，axios是0.21版本。安装前建议先锁定依赖版本号，避免后续组件库升级导致运行时未知问题。

6.2 打包和部署流程

前端执行npm run build生成dist目录，把dist目录放到Nginx静态目录下，同时做好前端路由的history模式回退配置——否则直接访问非首页路径会404。Nginx配置片段如下：

server { listen 80; server_name your-domain.com; root /www/dist; index 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; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } location / { try_files $uri $uri/ /index.html; } }

后端打包用mvn clean package生成jar包，部署时直接用java -jar应用名.jar --spring.profiles.active=prod启动。生产环境的数据库连接、Redis连接单独用application-prod.yml维护，不跟开发环境混用。定期安全加固方面，至少要做到数据库密码不写死、使用环境变量注入、开启Druid监控但严格限制白名单。

6.3 运维监控与备份策略

系统上线后，要主动关注三个指标：接口成功率、平均响应时长、慢查询数量。Druid监控后台可以查看SQL执行统计，MyBatis配合慢SQL日志能够定位到哪些查询效率低。我之前做过一次优化，把文章列表页原来超过800毫秒的接口优化到了200毫秒以内，方法就是加了联合索引，本来已经很高频的查询从全表扫描转成了索引范围扫描。

数据备份这块，我选择每天执行一次mysqldump全量备份，保留最近7天。备份文件放到和数据库独立的磁盘目录，防止服务器故障时备份也一起丢了。这个策略不复杂，但很多小团队压根没做，出了问题只能干瞪眼。

经验之谈：上线后前两周密切关注访问日志和错误日志，这段时间最容易发现业务逻辑的边界漏洞。连续两周无异常后，系统基本就能稳定运行了。

这套系统从需求梳理到部署上线，我认为做得最值的一笔投入是先花时间把“分级”这个业务模型想清楚再去建表。技术上的SpringBoot、MyBatis、Vue都是成熟框架，遇到问题网上都能查到解决方案，但业务模型一旦建错，后期返工的成本非常大。另一件事就是权限控制提前设计，等系统做完了再补安全方案就会各种难受。如果你拿到这套源码打算二次开发，建议先按“用户体系→文章内容→阅读行为→推荐评测”这条链路去读代码，理解业务闭环再动手改。