基于SpringBoot和Vue的儿童性教育网站管理系统设计与实现

上个月接了一个儿童教育机构的系统需求，说是要做一个基于SpringBoot和Vue的儿童性教育网站管理系统。听着就是一套标准的后台管理加内容展示项目，但真正开始梳理需求时才发现，这个系统的难点根本不在增删改查，而在三块：内容怎么分级、权限怎么隔离、审核流程怎么闭环。如果你也想做类似的教育内容管理系统，或者正在用Java+MySQL+MyBatis这套技术栈做毕业设计、企业实训项目，这篇文章会把我在整个设计和实现过程中的核心决策、表结构设计、关键代码思路以及踩过的坑一次说清楚，希望能帮你少走几条弯路。

1. 这个系统到底在解决什么问题：儿童性教育的内容管理与分级难题

1.1 为什么儿童性教育内容需要一套独立的管理系统

很多人问，儿童性教育本质上就是一些图文课件和视频，为什么不能直接在通用CMS上加几个栏目？做过内容平台的人应该清楚，这类教育的特殊之处在于内容极其敏感，且必须严格匹配孩子的年龄阶段和认知水平。

一个6岁孩子和12岁孩子需要获取的知识完全不是一回事，如果内容没有分级、没有展示审批记录、没有家长参与机制，那网站就变成一个不可控的内容池。这在现实业务中是绝对不能被接受的。

我当时梳理出来的核心需求有四个维度：

• 内容适龄分级：每一篇课件、视频、问答都要挂上年龄段标签，查询时按用户身份自动过滤。孩子端只能看到自己年龄对应的内容。
• 发布审核闭环：内容编辑提交后，必须经过审核员审校，避免出现措辞不当、科学错误的内容直接上线。审核状态要可追踪、可回滚。
• 多重角色隔离：系统需要同时服务管理员、审核员、教师或内容编辑、家长、孩子这几类人群。孩子端和家长端的界面、接口完全分离。
• 学习过程留痕：家长可以在系统里看到孩子的学习进度、学习记录，平台运营方也需要据此做内容质量评估。

这些需求叠加在一起后，一个普通的CMS模板就无法覆盖了。需要一个有明确角色权限模型、内容审核状态机、文件资源管理、学习行为记录的完整管理系统。这就是SpringBoot+Vue这类前后端分离架构能发挥价值的地方——后端负责业务规则和权限控制，前端负责给不同角色提供差异化的操作界面。

1.2 系统的角色边界：管理员、审核员、教师、家长的职责划分

角色的定义不应该是拍脑袋做的，我从业务方那里拿到的线下工作流程中，梳理出五类角色，最终落到RBAC权限模型里。

这个表格直接决定了后面数据库里的菜单权限种子数据怎么设计。比如一个审核员账号，登录后左侧菜单只显示“审核任务”“审核日志”“我的待办”，而不应该看到“用户管理”“系统参数配置”这类管理模块。这是典型的权限控制问题，而实现权限控制的关键，是表结构和认证框架的选型。

2. 技术栈选型复盘：SpringBoot+MyBatis+Vue这套组合的取舍理由

2.1 后端选型：为什么是SpringBoot而不是其他微服务框架

项目启动之前，团队内部也讨论过要不要上微服务，毕竟内容管理、用户中心、学习记录这些模块听起来可以拆开。但仔细一想就知道这个阶段不合适：团队不到五人，项目周期两个月，真实的并发量预估也就一个小型教育机构内部使用的水平。

SpringBoot的意义在于，它把Spring生态里大量繁琐的配置自动化了。以前用SSH或Spring MVC写一个项目，光配置数据源、事务管理、组件扫描就要半天，SpringBoot通过自动配置机制把这些沉淀成了约定。我们用到的核心依赖非常收敛：

• spring-boot-starter-web：处理RESTful接口和请求分发
• mybatis-spring-boot-starter：持久层框架，承接SQL映射
• mysql-connector-java：连接MySQL
• spring-boot-starter-security：负责认证授权，配合JWT做无状态鉴权
• spring-boot-starter-validation：参数校验
• lombok：减少实体类样板代码

对于这种管理系统，单体应用是架构上的正确选择。部署简单、调试直观、事务控制在一个应用内完成。只有当未来内容量大到需要把文件存储、学习记录统计拆成独立服务时，再考虑模块拆分也不迟，那时候SpringBoot的模块化边界也方便我们做微服务演进。

2.2 持久层选型：MyBatis相对JPA在内容管理系统的优势

这个项目的课程表、内容表、审核记录表之间的关系并不复杂，但查询条件变化非常多。比如内容列表页就有下面这些筛选条件：内容标题模糊查询、内容分类、年龄段标签、审核状态、发布状态、创建时间区间，而且列表要和分类表、创建人表关联显示。

如果用Spring Data JPA，动态拼接查询条件一般要写Specification或者QueryDSL，封装层次多、调试不直观。MyBatis直接用XML或注解写SQL，动态SQL使用<if>标签解决多条件，性能上限和可控性都更好。

我在项目中特意做了一个规范：所有超过两张表的关联查询，都必须写在Mapper XML里，并指定返回的DTO类型。这样SQL就是明文存在的，后续DBA介入优化也方便。举一个内容列表页的主查询示例：

<select id="selectContentPage" resultType="com.example.dto.EduContentDTO"> SELECT c.id, c.title, c.content_type, c.age_range, cat.name AS category_name, u.nickname AS creator_name, c.review_status, c.publish_status, c.create_time FROM education_content c LEFT JOIN content_category cat ON c.category_id = cat.id LEFT JOIN sys_user u ON c.creator_id = u.id <where> <if test="title != null and title != ''"> AND c.title LIKE CONCAT('%', #{title}, '%') </if> <if test="contentType != null and contentType != ''"> AND c.content_type = #{contentType} </if> <if test="ageRange != null and ageRange != ''"> AND c.age_range = #{ageRange} </if> <if test="reviewStatus != null and reviewStatus != ''"> AND c.review_status = #{reviewStatus} </if> </where> ORDER BY c.create_time DESC LIMIT #{offset}, #{pageSize} </select>

像这种查询用JPA写Specification反而绕了一层，MyBatis直接给SQL，团队新人也容易看懂。

2.3 前端选型：Vue2还是Vue3，组件库怎么选

前端这边，考虑到项目组成员对Vue2更熟，而且使用的组件库Element UI对Vue2的支持最稳定，我们最终选择了Vue2 + Element UI + Vuex + Vue Router + Axios的组合。Vue3的Composition API确实更现代，但如果团队没有熟练掌握，迁移成本会直接影响项目交付。

一个需要注意的细节是：儿童端页面和后台管理端页面要分开设计。后台管理端直接用Element UI的表格、表单、弹窗组件就够了，而学生端界面要照顾孩子的操作习惯，按钮要更大、配色要更温和、文字要更口语化，所以学生端我们没有做单独的技术栈，而是在Vue组件层面把页面拆开，甚至用了一套独立的路由模块来区分。

3. 数据库设计：从需求推导表结构的关键决策

3.1 十一张核心表的职责划分与关系

数据库是这类项目的命根子，表结构设计直接决定了后续功能开发的效率。我梳理出十一张核心表，每张表都对应一条业务线：

这些表的关联关系并不复杂，但设计时有几个隐藏决策值得说明：education_content表把年龄段、审核状态、发布状态三个字段放在一起，是为了方便做内容过滤和审核列表查询；审核日志单独成表而不是在内容表上仅保留一个状态字段，是为了追审有据；学习记录表必须记录学习时长和完成状态，因为家长端要看孩子到底学没学完。

3.2 内容分级字段与审核状态机的设计细节

儿童性教育内容的分级，是整个系统最重要的设计。我在education_content表上设计了一个age_range字段，取值范围是：

• 6_8：面向6到8岁孩子的内容
• 9_12：面向9到12岁孩子的内容
• 12_15：面向12岁以上孩子的内容
• parent_guide：面向家长的指导内容

这个字段要同时服务于后端查询过滤和前端展示分类。为了让孩子端不能通过修改前端请求参数看到本不该看的内容，后端所有查询内容的接口都必须强制带当前登录用户的年龄范围参数，而不是直接信任前端传来的ageRange。

审核状态我用了一个整数状态码字段review_status来维护：

这个状态机的流转逻辑我用了一个很朴素的工具类来校验：

public class ReviewStatusValidator { private static final Map<Integer, List<Integer>> ALLOWED_TRANSITIONS = new HashMap<>(); static { ALLOWED_TRANSITIONS.put(0, Arrays.asList(1)); // 草稿 -> 提交审核 ALLOWED_TRANSITIONS.put(1, Arrays.asList(2, 3)); // 待审核 -> 通过/退回 ALLOWED_TRANSITIONS.put(2, Arrays.asList(4)); // 通过 -> 下线 ALLOWED_TRANSITIONS.put(3, Arrays.asList(1)); // 退回 -> 重新提交 ALLOWED_TRANSITIONS.put(4, Arrays.asList(1)); // 下线 -> 重新提交 } public static boolean canTransit(Integer current, Integer target) { return ALLOWED_TRANSITIONS.getOrDefault(current, Collections.emptyList()).contains(target); } }

这个校验器在接口层和Service层都会被调用，用来防止绕过状态机直接更改状态。实际运营中曾出现过审核员点“通过”后由于网络抖动重复提交，导致状态从2又变回3的问题，后面我们在这个逻辑上加了乐观锁版本号字段，这里先不展开，后面踩坑部分细说。

3.3 学习记录与用户行为表的设计思路

研究学习记录表时，我参考了常见在线学习系统的做法。核心记录单位是“一次学习动作”，也就是用户打开内容页面开始到离开为止。前端会定时上报学习进度，后端接口只做增量更新，避免频繁写库。

study_record表的核心字段：

• user_id：学习用户ID
• content_id：学习的内容ID
• study_duration：本次累计学习时长（秒）
• study_status：0进行中、1已完成
• finish_time：完成时间
• last_study_time：最后学习时间

家长端查询学习日报时，只需要按天聚合这个表。为了兼顾性能，我在这张表上建了联合索引user_id + content_id，并在实现时避免了未使用索引前缀导致的慢查询。另一个容易忽略的点是：孩子反复点击内容，会产生大量重复记录。我的做法是同一个用户同一份内容只保留一条进行中的记录，前端每次上报都走“存在则更新、不存在则插入”的逻辑，这样既保证数据量可控，也方便做状态流转。

4. 后端核心实现：权限控制、内容审核与文件上传

4.1 基于Spring Security的RBAC权限模型落地

之前做的很多项目权限控制都比较随意，用拦截器判断一下当前用户是不是管理员就完事。但在这个系统里，不同角色的权限差异特别细，比如审核员能不能看到某个菜单、内容编辑能不能看到全部用户列表，这些都要精确到接口级别。

我们选择Spring Security + JWT的组合。用户登录成功后，后端签发JWT，JWT里只存放用户ID和用户名，不存放角色列表。用户每次请求时，过滤器解析出用户ID，然后从Redis缓存中读取角色和权限标识集合，再交给Spring Security做权限判断。

这样设计的原因很实际：如果角色变化了，比如审核员被降为普通编辑，存储在JWT里的角色无法立即失效，就会造成越权。而每次从Redis读取权限集合，管理员在后台调整角色后，只需清掉该用户的缓存，下一次请求就会拿最新权限。

核心配置大致是：

@Configuration @EnableWebSecurity public class SecurityConfig extends WebSecurityConfigurerAdapter { @Override protected void configure(HttpSecurity http) throws Exception { http.cors().and().csrf().disable() .authorizeRequests() .antMatchers("/api/auth/login", "/api/auth/register").permitAll() .antMatchers("/api/admin/**").hasAnyRole("ADMIN", "REVIEWER") .antMatchers("/api/student/**").hasRole("STUDENT") .anyRequest().authenticated() .and() .addFilterBefore(new JwtAuthenticationFilter(), UsernamePasswordAuthenticationFilter.class); } }

这里要特别说明一个小坑：Spring Security的hasRole会自动拼接ROLE_前缀，所以数据库角色表里的角色代码要对应写成ROLE_ADMIN这种，或者自定义权限校验逻辑，否则权限判断始终不生效。

4.2 内容发布与审核接口的实现逻辑

内容发布流程是我们整个系统的业务核心，它的链路是：

内容编辑保存草稿 → 提交审核 → 审核员查看内容 → 通过或退回 → 内容上线。

在后端，我拆成两个Controller：ContentController负责内容的增删改查和提交审核，ReviewController负责审核操作。两个模块在业务上分开，但在数据库层面共享同一张内容表和审核日志表。

提交审核接口里，最关键的校验有两点：

1. 当前内容状态必须是草稿或审核退回状态；
2. 内容必须填写标题、年龄段、分类和正文，不能提交空内容。

审核通过的接口，除了更新内容状态，还需要同步生成一条content_review_log记录，把审核意见、审核人、审核时间记录下来。我在设计时特意要求：审核意见不能为空，无论是通过还是退回，都得说清楚理由。这一步看似繁琐，但运营上非常重要，因为内容编缉人员需要知道修改方向，也方便后期追责。

一个后端实现时的关键细节是事务控制。更新内容状态、写入审核日志这两个操作必须在同一个事务中完成：

@Transactional(rollbackFor = Exception.class) public void passReview(Long contentId, String comment) { EduContent content = contentMapper.selectById(contentId); if (content == null) { throw new BusinessException("内容不存在"); } if (!ReviewStatusValidator.canTransit(content.getReviewStatus(), 2)) { throw new BusinessException("当前状态不允许通过审核"); } content.setReviewStatus(2); contentMapper.updateById(content); ContentReviewLog log = new ContentReviewLog(); log.setContentId(contentId); log.setReviewerId(currentUserId()); log.setReviewAction(2); log.setReviewComment(comment); log.setReviewTime(new Date()); reviewLogMapper.insert(log); }

4.3 图片与视频文件的上传与管理方案

教育内容里不可避免要上传图片、视频、课件PDF。最初我们想直接把文件存到本地磁盘，后来发现教育网站的图片和视频访问频率特别高，本地磁盘在部署和备份方面都很被动，最后选择了MinIO作为文件存储服务。MinIO是开源的对象存储系统，接口与S3兼容，部署简单，内网环境跑起来非常稳定。

文件上传接口的逻辑：

1. 前端调用接口获得一个临时上传凭证；
2. 后端校验当前用户是否有文件上传权限；
3. 文件上传到MinIO后，把文件名、访问URL、文件大小、文件类型写入resource_file表；
4. 内容编辑在编写课件时，通过已经上传的文件URL引用资源。

需要注意的一点是文件名不能直接用原始文件名，否则中文文件名和特殊字符会在URL中造成各种解析问题。我用UUID重命名文件，同时保留原始文件名到数据库中，方便后台管理溯源。

5. 前端页面与交互：Vue组件化开发中的关键实践

5.1 后台管理端的页面骨架与路由守卫

管理端采用典型的左侧菜单加右侧内容区的布局。菜单数据不是前端写死的，而是用户登录后通过接口动态获取。这里有一个很实用的设计：后端菜单表里有一个perms字段，存的是前端动态路由需要的组件路径，前端拿到菜单列表后，用Vue Router的addRoutes方法动态注册路由。

路由守卫是权限控制在前端的最后一道防线：

router.beforeEach((to, from, next) => { const token = localStorage.getItem('token'); if (!token && to.path !== '/login') { next('/login'); return; } if (token && to.path === '/login') { next('/'); return; } if (token && !store.state.user.hasUserInfo) { store.dispatch('user/getInfo').then(() => { next({ ...to, replace: true }); }).catch(() => { store.commit('user/logout'); next('/login'); }); } else { next(); } });

路由守卫的逻辑不仅是判断是否登录，还要在刷新页面后重新拉取用户信息，否则动态菜单和角色权限会丢失，导致页面白屏或菜单不完整。

5.2 课件列表与富文本编辑器的集成细节

内容编辑在后台写课件时，需要用到富文本编辑器。我们集成的是ueditor的Vue封装版。集成富文本编辑器时最大的坑是：编辑器生成的HTML里包含大量行内样式，如果直接存入数据库，然后在看课页面用v-html渲染，会带来XSS注入风险。

这里的处理策略是：

1. 前端提交内容前，对HTML做一次客户端大小限制（比如不能超过200KB）；
2. 后端在接收内容时，用Jsoup的safelist机制过滤掉所有script、iframe、onclick这类危险标签和属性；
3. 后端把过滤后的HTML再存入库。

这个步骤不能省略。我之前见过太多项目因为觉得“后台是管理员在用，不会有XSS”，结果运营账号被盗后被注入恶意脚本的案例。

5.3 Axios拦截器与跨域问题的处理

前端所有请求通过Axios发送。我在项目中统一封装了一个request.js，主要做了三件事：

• 请求头自动注入Authorization，格式为Bearer ${token}；
• 响应拦截器统一处理后端返回的code字段，如果code为401，说明登录已过期，自动跳转到登录页；
• 对于后端返回的业务异常，统一弹出消息提示，避免每个页面都写重复的错误处理代码。

跨域问题其实是开发环境最常见的问题。前端跑在8080端口，后端跑在8081端口，如果不在后端配置跨域，浏览器会拦截所有异步请求。解决方式有两种：一种是后端加CorsFilter，另一种是在Vue的devServer中配置proxy代理。我推荐用proxy方式，因为生产环境前端部署在Nginx下，可以通过Nginx反向代理同源访问后端接口，这样代码里不需要硬编码后端地址，一套代码同时适配开发和部署。

6. 从源码到部署：完整复现这个项目的实操指南

6.1 环境准备与项目初始化

虽然标题写了“完整源码”，但想要跑起来，环境准备是第一步。我建议用以下统一版本，避免出现奇怪的兼容问题：

项目拿到手后，先把前后端代码分别放入backend和frontend目录。后端导入IDE时建议直接用Maven方式导入，等待依赖下载完成。如果下载慢，给Maven配置阿里云镜像，这个操作能节省大量等待时间。

6.2 数据库初始化与配置文件修改

数据结构初始化是整个复现过程中最不能跳过的环节。源码中一般会附带sql脚本，我在这个项目中把数据库表和基础菜单数据写在了两个脚本中：

• init_table.sql：创建数据库、所有表和索引
• init_data.sql：插入管理员账号、角色、菜单种子数据

执行数据库脚本时有一个先后顺序的坑：init_data.sql里插入了sys_role_menu关联数据，它依赖菜单ID和角色ID。如果表结构脚本和种子数据脚本分开，必须先执行表结构脚本，再执行数据脚本，否则会外键报错。

后端配置文件application.yml里有几项必须根据本地环境修改：

spring: datasource: url: jdbc:mysql://localhost:3306/edu_safety_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: your_password minio: endpoint: http://localhost:9000 access-key: minioadmin secret-key: minioadmin bucket-name: edu-content

这里要特别留意MySQL8.0的驱动类名是com.mysql.cj.jdbc.Driver，MySQL5.7用的是com.mysql.jdbc.Driver，如果用错了版本会启动报错。另外数据库连接串里的serverTimezone参数不能省略，否则本地时区跟服务器不一致时会报错。

6.3 本地启动、接口自测与常见启动故障

后端启动步骤：

1. 确认MySQL服务已启动；
2. 确认MinIO服务已启动，并创建edu-content这个bucket；
3. 运行BackendApplication.java的主类；
4. 观察控制台日志，出现Started BackendApplication即启动成功。

前端启动步骤：

1. npm install安装依赖；
2. npm run dev启动开发服务器；
3. 浏览器访问http://localhost:8080，用初始化脚本里的管理员账号登录。

这中间最容易出现的启动故障有三个：

故障一：端口被占用。SpringBoot默认端口8080，如果本地有别的服务占用，可以在application.yml里改成8081，然后前端proxy配置也对应修改。

故障二：Security权限配置导致所有接口都403。这种情况大多是角色编码前缀问题，要么给角色代码加ROLE_前缀，要么在配置里自定义权限匹配逻辑。

故障三：MyBatis的Mapper XML没有扫描到。检查启动类上有没有@MapperScan注解，以及mybatis配置里mapper-locations是不是指向classpath:mapper/*.xml。这个问题报错往往很隐晦，SpringBoot启动不会失败，但调用接口时才报Invalid bound statement。

接口自测时，我习惯先用Postman把这几个关键流程完整走一遍：

• 管理员登录获取token
• 新增内容分类
• 创建内容并提交审核
• 用另一个审核员账号登录，执行审核通过
• 用学生端账号查询已发布内容

只有这条链路通了，整个项目的核心功能才算真正跑通。

6.4 部署到服务器时的注意事项

本地跑通后，部署到生产服务器有几个容易遗漏的配置：

• 后端需要打成Jar包，打包命令最好跳过测试：mvn clean package -DskipTests
• 前端需要执行npm run build，生成dist目录，然后由Nginx托管
• Nginx配置两个location：/指向前端dist目录，/api反向代理到后端服务
• MySQL和MinIO需要使用公网内网可访问的地址，注意在安全组里放行端口

一个经常遇到的坑是：前端打包后刷新页面404。这是因为Vue路由使用的是History模式，刷新时Nginx找不到对应的真实文件。解决办法是在Nginx的location中配置try_files：

location / { root /usr/share/nginx/html; index index.html; try_files $uri $uri/ /index.html; }

部署完成后，建议用生产环境地址重新走一遍审核链路，确认静态资源、图片URL、API请求都能正常访问。

7. 踩坑记录：内容安全、性能与数据一致性的那些坑

7.1 富文本XSS过滤：为什么不能只靠前端

在试运行阶段，内容编辑上传了一篇包含外部图片的课件，结果图片加载失败后页面出现了一个悬浮层。研究后发现问题出在富文本编辑器的HTML里面，有些标签带有javascript协议的事件属性，而前端编辑器是可以手动修改HTML源码的。当时我就意识到，前端做再多的过滤都不靠谱，攻击者完全可以绕过前端直接向后端提交数据。

后来我在后端增加了一个统一的HTML清洗过滤器，恰好是在内容提交和编辑接口处执行的：

private String sanitizeHtml(String html) { Whitelist whitelist = Whitelist.relaxed() .addTags("video", "source") .addAttributes("video", "src", "controls", "width", "height") .addAttributes("source", "src", "type"); return Jsoup.clean(html, whitelist); }

Jsoup的Whitelist机制会根据配置保留安全的标签和属性，其他全部清除。视频标签本身支持正常的播放功能，但script、style、on*事件都会被强制剥离。实测跑了一段时间，没有再出现注入问题。

7.2 列表页N+1查询与慢SQL优化

内容列表页面一开始加载很慢，排查后发现一个典型问题：分页查询内容列表时，每条内容都要单独查一次分类名称和创建人昵称。10条数据需要执行21条SQL，这就是经典的N+1查询问题。

优化思路很直接，把原来“查列表后循环查子表”的逻辑改成一条主查询加两条批量查询。用MyBatis的association和collection标签来做结果映射，或者直接查DTO。我选择的是写一个专门的查询Mapper，像x.x.1那节展示的SQL一样，一次LEFT JOIN查出所有需要的字段。优化后，接口响应时间从平均800毫秒降到了100毫秒以内。

另外还要提一个MySQL分页的细节：当数据量增大后，LIMIT 100000, 20这种方式会越来越慢，因为MySQL会先把前十万条数据查出来再丢弃。优化的常见做法是使用上一页最后一条记录的ID做分页游标，或者使用子查询延迟关联。

7.3 并发审核场景下的数据一致性问题

系统上线两周后，运营反馈了一个诡异的问题：同一个内容被两个审核员同时审核，一个点击通过，一个点击退回，后提交的人把前者的操作覆盖了。而且审核日志里出现了两条记录，内容状态却停留在最后一条操作的结果上。

这个问题属于典型的并发更新丢失。解决办法是给内容表增加一个version版本号字段，每次更新时通过乐观锁校验版本号：

UPDATE education_content SET review_status = #{targetStatus}, version = version + 1 WHERE id = #{contentId} AND version = #{oldVersion}

如果更新的影响行数为0，说明版本号已被其他事务修改，本次操作直接返回“该内容已被他人处理，请刷新后再试”。同时，我在审核接口里增加了对内容状态的二次校验，从数据库查出的review_status必须等于当前操作对应的预期状态，而不是前端传过来的状态。

经历了这次问题后，我在项目代码里确定了一条约定：任何涉及状态流转的更新操作，都必须走乐观锁或悲观锁，绝不允许无条件地update状态字段。这条约定在后面的资源位配置、课程上下线功能中都起到了作用。

8. 关于儿童性教育网站管理系统，我最后的几点实操感受

这类软件系统说到底还是工具，真正有意义的是内容本身被有序、分级、安全地传递到需要的人手里。我在这套系统里做的最有价值的工作，不是写了多少行代码，而是通过状态机让每一份内容上线前都经过了该有的审核环节，通过RBAC权限模型让不同角色只能看到自己职责范围内的功能，通过学习记录让家长能够了解孩子的学习轨迹。

如果你准备在自己的项目里复现这套管理系统，我有一个建议：不要一上来就陷入代码细节。先把内容分级规则、审核流程、角色权限矩阵这三件事用文档写清楚，再动手设计数据库。业务流程理解了，表结构自然会清晰；表结构清晰了，后端的Controller和Service写起来就是体力活。

最后分享一个自己用着顺手的小技巧：在本地开发时，给SpringBoot项目配上Spring Boot DevTools热加载依赖，修改代码后应用会自动重启，调试效率提升非常明显。另外，前端页面验证码登录功能不要省，教育类网站的用户名密码暴力破解风险虽然不高，但加上验证码能省掉很多安全加固上的麻烦。

如果后续你想在这个项目上继续扩展，可以优先考虑两个方向：一是把学习记录的数据做更细的统计分析，帮助运营团队评估课程内容质量；二是加入内容浏览时的语音播放能力和更友好的学生端UI，让低龄用户使用起来更顺畅。