简介这套基于SpringBoot与Vue的个性化定制智慧校园管理系统项目包面向需要完成毕业设计、课程实训或快速上手前后端分离开发的学习者。系统覆盖学生、教师、管理员三类角色包含用户管理、课程与选课、考试管理、资源共享、个性化定制及后台管理等完整功能模块可作为智慧校园场景下的可运行参考项目。压缩包共947个文件大小约37.23MB核心代码以197个Java、157个JavaScript、90个Vue等前后端源文件为主另有162个SVG图标、79个GIF演示、69个HTML页面、50个CSS样式表及SQL数据库脚本、万字Word文档覆盖源码、建库脚本、说明文档与演示素材其中Java与SpringBoot负责后端业务逻辑Vue与JavaScript承载前端交互SQL脚本可快速完成建表与数据初始化GIF和HTML便于直观查看运行效果。目前已有49人浏览学习除前后台完整可运行源码和数据库初始化脚本外文档还给出系统设计、架构与接口说明目录按功能模块划分便于逐块阅读、调试和二次开发。通过实际部署与调试可同时巩固SpringBoot接口开发、Vue组件化页面构建和MySQL数据建模等能力适合作为毕设或课程设计的起点也为后续扩展选课、成绩分析等个性化功能打下基础。1. 智慧校园管理系统里“个性化定制”到底改的是什么给学校做管理系统最容易踩的坑是把“个性化定制”理解成换主题色。实际使用时学生、教师、辅导员、后勤管理员进入同一套 Spring Boot Vue 的智慧校园管理系统看到的首页入口、默认打开的页面、消息通知范围、快捷操作顺序都应该不同。如果这些差异全靠 if/else 判断菜单、路由、首页会写出一堆分支以后加一个角色就得回代码里翻一遍。个性化定制的本质不是 UI 皮肤而是数据模型的分层数据层把“用户能改的东西”抽成偏好配置接口层把配置和权限合并后下发前端层根据配置动态生成路由与页面。把这三层理清楚比一开始就切页面更能决定项目能不能支持多角色、多校区、可扩展需求。换句话说这套系统的核心能力是“按人组页”。2. 打通后台数据用“角色默认值 用户覆盖值”承接个性化定制2.1 角色权限管“能不能看”个性化定制管“看到什么”先分清两件事否则后续所有表都会耦合。RBAC用户、角色、菜单回答的是这个用户能访问哪些接口、哪些菜单。它应该保持稳定改动频率低。个性化定制回答的是同一份菜单用户希望按什么顺序排、默认落在哪个页面、要不要把某个入口加到首页。这类数据允许用户自己改改动频率高。常见的错误是把“用户自定义菜单顺序”直接写进角色菜单表。后果是用户 A 调了顺序角色共享的菜单配置被改掉同角色的用户 B 也变了或者管理员在后台一保存角色配置又把用户自定义顺序覆盖没了。正确做法是设计两层配置让“角色默认值”和“用户覆盖值”合并。2.2 一张 sys_user_profile 表搞定平时九成需求先看角色默认配置这是可选表再看用户覆盖配置这是核心表。用户表结构大致长这样CREATE TABLE sys_user_profile ( id BIGINT NOT NULL COMMENT 主键, user_id BIGINT NOT NULL COMMENT 用户ID对应sys_user.id, theme VARCHAR(32) NULL COMMENT 主题标识默认default, home_page VARCHAR(128) NULL COMMENT 登录后默认首页路径, menu_order JSON NULL COMMENT 菜单path数组空表示沿用角色默认, quick_entries JSON NULL COMMENT 首页快捷入口如[{title:课表,path:/timetable}], notice_prefs JSON NULL COMMENT 通知订阅如班级通知、成绩提醒, extension JSON NULL COMMENT 扩展字段按业务自行约定, updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 更新时间, PRIMARY KEY (id), UNIQUE KEY uk_user_id (user_id) ) COMMENT 用户个性化配置表;几个关键选择。第一user_id 设置唯一键保证一个用户只有一条配置每次保存用插入或更新别用“用户每次点击都在原行上追加列”。第二menu_order 存菜单的 path不存数据库主键因为前端路由跳转用的是 path拿主键还得再翻译一次。第三MySQL 5.7 以上支持 JSON 类型可以直接JSON_CONTAINS做查询平时代码里取出后转成 Java 的 List 或 Map 也方便。对应的 MyBatis-Plus 实体Data TableName(sys_user_profile) public class UserProfile { TableId(type IdType.ASSIGN_ID) private Long id; private Long userId; private String theme; private String homePage; private String menuOrder; private String quickEntries; private String noticePrefs; private String extension; private LocalDateTime updatedAt; }这里没有用TableField(typeHandler JacksonTypeHandler.class)而是统一存字符串在 Service 层做 JSON 序列化与反序列化。原因很简单field 多了以后typeHandler 的自动映射在聚合查询里很容易被忽略出错后难看Service 层显式转换代码更直白也方便统一加默认值。2.3 合并规则角色配置打底用户覆盖层生效个性化配置最终要合成一份给前端渲染合并规则是先查角色默认配置再查用户配置用户配置里字段为 null 就沿用角色值不为 null 就覆盖角色值。写成服务代码如下public UiConfig loadUiConfig(Long userId, Long roleId) { // 角色默认配置后台可维护 RoleProfile roleProfile roleProfileMapper.selectByRoleId(roleId); // 用户个性化配置可能为空代表“没改过全用默认” UserProfile userProfile userProfileMapper.selectByUserId(userId); UiConfig config new UiConfig(); config.setTheme(roleProfile ! null ? roleProfile.getTheme() : default); config.setHomePage(roleProfile ! null ? roleProfile.getHomePage() : /dashboard); config.setMenuOrder(parseMenuOrder(roleProfile ! null ? roleProfile.getMenuOrder() : null)); // 用户值覆盖角色值 if (userProfile ! null) { if (StringUtils.hasText(userProfile.getTheme())) { config.setTheme(userProfile.getTheme()); } if (StringUtils.hasText(userProfile.getHomePage())) { config.setHomePage(userProfile.getHomePage()); } if (StringUtils.hasText(userProfile.getMenuOrder())) { config.setMenuOrder(parseMenuOrder(userProfile.getMenuOrder())); } } return config; }注意三个容易被忽略的点。角色配置本身不完全等于“系统默认”一个学校可能有多个角色学生默认到课表页教师默认到课程管理页后勤默认到报修处理页。用户配置字段用 null 表示“未覆盖”空字符串、空数组不是 null。menuOrder 传了[]就表示用户主动把所有菜单折叠了这在业务上说不通所以我一般约定[]仍然使用角色默认只有非空数组才参与覆盖。这个约定要在接口文档里写清楚前后端才不会对空数组理解不一致。后续版本要加“按班级/学院生效的推荐首页”不要在 user_profile 里不断加列而是把这类规则放进 extension JSON例如{grade:2024,departmentId:12}让合并逻辑按规则匹配。2.4 为什么选 JSON 列而不是动态建表有人会想每个用户配置不一样为什么不给用户动态建一张表或加一批字段动态建表会有几个直接问题MyBatis 的实体映射是编译期定死的表结构一变Mapper 的 resultMap 要跟着改学生选课、教师课表这类业务还会把表和业务逻辑耦合在一起迁移的时候非常痛苦。JSON 列牺牲了一点点类型约束换来的是“新增一个偏好项不用改表结构”这对智慧校园这类需求经常变化的系统来说更划算。等 JSON 里某个字段真的要被频繁查询和排序再把它抽成独立列那也是后话了。3. 把配置做成接口Spring Boot 聚合、缓存与权限控制3.1 先定接口一个 /ui/config 返回整棵配置树前后端分离开发时前端最怕后端把个性化配置拆成十几个接口页面要并行请求三四次才能组装出首页。常见做法是做一个聚合接口用户登录后前端调一次/api/v1/ui/config后端一次返回主题、首页、菜单、快捷入口、通知订阅前端拿到数据直接渲染。这样首屏加载也少了两轮网络往返。接口返回值大致是{ code: 0, data: { theme: dark-blue, homePage: /student/timetable, menus: [ { path: /student, title: 学习中心, children: [...] } ], quickEntries: [ { title: 查课表, path: /student/timetable } ] } }前端不用关心这个菜单树是后端从角色表、菜单表、用户配置表怎么拼出来的。它只需要知道只要登录状态有效这个接口返回的 menus 就是这个人最终能看到的路由集合。3.2 JWT 鉴权与接口白名单Spring Boot 3.x 集成 Spring Security 后包名是jakarta.*配置方式变化不算大。先建 JWT 过滤器Component public class JwtAuthenticationFilter extends OncePerRequestFilter { private final JwtUtil jwtUtil; Override protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException { String auth request.getHeader(Authorization); if (StringUtils.hasText(auth) auth.startsWith(Bearer )) { String token auth.substring(7); if (jwtUtil.validate(token)) { LoginUser loginUser jwtUtil.parse(token); UsernamePasswordAuthenticationToken authentication new UsernamePasswordAuthenticationToken( loginUser, null, loginUser.getAuthorities()); SecurityContextHolder.getContext().setAuthentication(authentication); } } filterChain.doFilter(request, response); } }这段过滤器做的事只有一件从请求头里取出 token解析成登录用户信息塞进 Spring Security 的上下文。后面的接口就能用AuthenticationPrincipal LoginUser拿到当前用户也能用PreAuthorize(hasRole(TEACHER))做细粒度判断。注意白名单要明确登录接口、验证码接口、静态资源接口应该放行个性化配置接口不能放行。漏写白名单会导致 Swagger 或验证码接口直接被 401 挡掉写太宽则等于把配置接口裸奔暴露。我一般用一个常量数组维护白名单每次加接口先检查是否应该进白名单。3.3 用 Spring Cache 给“按人定制”加缓存每个用户配置都查三张表高并发下数据库压力会很大。缓存方案按照偏好的 key 设计覆盖三个层级用户级配置、角色级配置、菜单树。缓存 key 前缀过期时间主动失效时机ui:user:{userId}60 分钟用户保存个性化配置时立即删除ui:role:{roleId}60 分钟后台修改角色配置时删除ui:menu:tree30 分钟菜单发布或角色菜单变更时删除用 Spring Cache 注解实现Cacheable(cacheNames ui:user, key #userId) public UiConfig getUserUiConfig(Long userId) { // 查 roleProfile userProfile 再合并 }实际开发中更常用 Redis 手动读写因为Cacheable只能处理 key 固定、入参简单的场景要有版本号或动态 TTL 就不太方便。用 RedisTemplate 时把 message 序列化器统一成 JSON方便在终端直接keys ui:user:*查看。这里有一个容易踩的坑“用户改了自己的配置但页面没变”。常见原因是改了库里数据却没有把ui:user:{userId}这个 key 删掉。另一个原因是 Redis 里存了旧对象而对象没实现Serializable反序列化直接报类型转换异常。解决方法是缓存对象固定用UiConfig这一个类不允许前端传入任意 JSON 覆盖整个缓存。3.4 配置参数参考连接池、超时与 TokenSpring Boot 项目的个性化接口是否稳定往往不取决于代码而取决于这些参数配置项常见基线说明server.tomcat.threads.max200最大工作线程线程不是越多越好spring.datasource.hikari.maximum-pool-size20数据库连接池上限按“峰值QPS x 单请求耗时”估算spring.data.redis.timeout3sRedis 操作超时避免 Redis 慢拖垮接口jwt.expire-hours12token 有效期学校场景建议短一些server.compression.enabledfalse对文本接口建议开启减少传输体积JWT 的有效期在校园场景不值得设太长。学生每天登录次数固定12 小时足够管理员可能连续用一整天设 24 小时也没问题。关键是 Redis 里要维护一个黑名单或“登录态版本号”用户改密码、被踢下线时旧 token 立刻失效而不是干等自然过期。3.5 配置文件里的口令别裸奔数据库口令、Redis 口令写在 application.yml 里是常态但提交到 Git 后一旦仓库泄露就等于裸奔。常见做法分两步敏感信息用环境变量注入即spring.datasource.password: ${DB_PASSWORD}如果必须写进 yml就用 Jasypt 的ENC(...)写法加密存储。注意加密盐值不要和密文放同一个文件。4. Vue 端落地路由动态加载、菜单递归渲染和个人首页4.1 工程搭建与目录划分Vue 侧我一般用 Vite 创建项目命令是npm create vuelatest选上 Router、Pinia。装完依赖后目录按“功能域”而不是“文件类型”划分src/ api/ # 按模块放请求 router/ # 静态路由 动态路由注册 stores/ # Pinia用户信息、配置信息 layout/ # 布局、侧边栏、导航 views/ student/ teacher/ admin/为什么按功能域划分智慧校园系统角色多、页面多按类型分会出现views/table/xxx.vue这种谁都看不懂的目录按角色分新人接到“给学生加一个页面”时直接进views/student找不需要猜测页面归属。4.2 axios 拦截器统一带 token、处理 401前后端分离最常见的会话问题是用户登录后每次请求都要带 tokentoken 失效后不能每个页面各弹一次提示。统一放在 axios 拦截器里// src/api/http.js import axios from axios const service axios.create({ baseURL: /api, timeout: 10000 }) service.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers.Authorization Bearer ${token} } return config }) service.interceptors.response.use( response response.data, error { if (error.response?.status 401) { localStorage.removeItem(token) window.location.href /login } return Promise.reject(error) } )这段代码的要点是request 拦截器做“注入”response 拦截器做“兜底”。把 token 读出来放到 Authorization 头后端 JWT 过滤器才能取到401 时统一清理登录态并跳转登录页而不是让每个页面自己写catch。baseURL用/api是约定走网关或后端同域开发环境再通过 Vite proxy 转发到后端端口从而避免浏览器直接跨域带来的 OPTIONS 预检。4.3 Vue Router 动态路由别把所有页面写死在静态路由表里个性化系统的核心是不同用户加载不同路由。Vite 构建时前端如果提前把所有页面都 import 进来路由表会很大而且后端配置的“这个人看不到某菜单”在前端完全不生效。正确做法是登录后拿/ui/config返回的 menus用router.addRoute动态注册// src/router/dynamic.js import Layout from /layout/index.vue const componentMap { Layout, studentTimetable: () import(/views/student/timetable.vue), teacherCourse: () import(/views/teacher/course.vue), adminReport: () import(/views/admin/report.vue) } export function registerDynamicRoutes(menus) { menus.forEach(menu { if (router.hasRoute(menu.path)) return router.addRoute({ path: menu.path, name: menu.name, component: componentMap[menu.component] || Layout, meta: { title: menu.title, icon: menu.icon, roles: menu.roles } }) if (menu.children?.length) { registerDynamicRoutes(menu.children) } }) }这里的componentMap扮演“前端组件白名单”的角色。后端返回的不是具体路径而是组件标识例如studentTimetable前端把标识映射到真正的 import 方法。这样后端改菜单、排序都不需要重新发前端包但后端也无法让前端加载一个不存在的组件。路由懒加载的好处是首屏只加载公共代码进入哪个页面才加载哪个页面student区域的代码不会影响teacher的打开速度。动态路由和静态路由要避免冲突。登录页、404、重置密码这类与角色无关的页面留在静态路由表业务页面全部动态注册。如果动态路由注册失败常见原因是router.hasRoute(menu.path)里的 path 带参数比如/student/detail/:id和真实路由/student/detail/100不一致这种情况要约定后端返回的 path 用配置模板前端注册再替换成真实值。4.4 菜单递归组件与按用户渲染首页菜单树是嵌套的前端不能写死三级。用递归组件最方便!-- src/layout/MenuTree.vue -- script setup defineOptions({ name: MenuTree }) defineProps({ menus: Array }) /script template template v-formenu in menus :keymenu.path a-sub-menu v-ifmenu.children menu.children.length :keymenu.path template #title{{ menu.title }}/template MenuTree :menusmenu.children / /a-sub-menu a-menu-item v-else :keymenu.path click$router.push(menu.path) {{ menu.title }} /a-menu-item /template /template用了 Ant Design Vue 的 Menu 组件递归组件名要和defineOptions({ name: MenuTree })保持一致否则在模板里MenuTree无法识别自己。缩进层级不要写死统一交给递归。首页组装更简单从 Pinia store 里读homePage如果没有值就默认/dashboard登录重定向时直接router.replace(config.homePage)。快捷入口就是quickEntries数组用v-for渲染成一排卡片点击跳转menu.path。这里不要加载时重新请求接口登录后/ui/config的数据已经放进 Pinia 且持久化到 localStorage刷新页面后从 localStorage 恢复避免每次刷新都闪一下登录页。4.5 一个典型坑直接赋值导致页面不变Vue 3 里用 reactive 声明的对象直接“深层”追加属性页面常常不更新。比如把接口返回的配置塞进对象const state reactive({ uiConfig: {} }) // 不生效 state.uiConfig.homePage data.homePage // 生效 state.uiConfig { ...state.uiConfig, ...data }原因很简单reactive的代理是在第一次赋值时建立的空对象没有homePage这个 key后续新增属性不会触发响应式依赖。排错时先看值是更新了但 DOM 没变还是值根本没更新。前者多半是响应式丢失用Object.assign或整个替换后者看接口返回什么。Vue Devtools 在这里很实用看 Pinia state 里uiConfig的值如果值变了页面没变就是模板里绑定的路径写错了常见是config.homePage与state.config.homePage混淆。5. 从“能用”到“扛得住”版本选型、参数调优和排错5.1 Spring Boot 版本选择2.7 还是 3.xJDK 怎么配智慧校园项目往往要部署到学校自己的服务器上环境没那么新版本选型要提前定。Spring Boot 3.x 要求 JDK 17 起Servlet 包从javax换成jakarta2.7.x 还可以跑 JDK 8。如果学校已经有 JDK 8 的运行环境硬上 Boot 3 会带来一堆部署成本如果新项目、新服务器就直接 JDK 17 Boot 3.x毕竟 Boot 2 的社区维护周期已经结束。技术选型推荐组合说明JDK 8 Spring Boot 2.7适合已有旧服务器javax 包名MyBatis-Plus 兼容好JDK 17 Spring Boot 3.x适合新部署jakarta 包名Spring Security 6 语法变化Vue 3 Vite Ant Design Vue前后端分离标配避免引入过重 UI 框架初学容易犯的错是本地装了 Boot 3代码里还写javax.servlet启动直接报 NoClassDefFoundError或者本地 JDK 21 但生产 JDK 8编译用高版本导致生产跑不起来。统一在 pom 里把java.version和maven.compiler.source/target钉死本地、测试、生产保持一致。5.2 几个真正影响体验的参数下面的参数我在每个 Spring Boot Vue 项目落地时都会过一遍配置项参考值作用server.tomcat.threads.max200限制并发执行线程防线程爆炸server.tomcat.accept-count100等待队列长度和线程数一起调spring.datasource.hikari.maximum-pool-size20数据库连接数太高反而拖垮数据库spring.datasource.hikari.connection-timeout30000拿不到连接的等待时间spring.mvc.async.request-timeout30000异步请求超时个性化配置接口可设置server.compression.enabledtrue开启 gzipJSON 体积通常能减少 60%user_profile这类配置表数据量不大但被高频读取索引除了user_id唯一键还要考虑后台按主题、通知偏好做统计时的查询必要时给 extension JSON 里的常用字段建生成列索引。MySQL 8 支持JSON_EXTRACT的表达式索引但学校环境可能是 MySQL 5.7所以我的经验是运营要统计“有多少人开了成绩提醒”就别在 JSON 里查单独建一个notice_grade_flag TINYINT列并加索引代码里写两份一份给配置、一份给统计。5.3 接口变慢时按这条链路查前端反馈“首页转了 3 秒”不要立刻怀疑代码。先问三个问题是只有一个人慢还是大家都慢是首次登录慢还是每次登录都慢后端接口返回慢还是前端渲染慢然后按这条命令链路去定位# 1. 看接口完整耗时 curl -o /dev/null -s -w total%{time_total} dns%{time_namelookup} connect%{time_connect}\n \ -H Authorization: Bearer $TOKEN \ http://localhost:8080/api/v1/ui/config # 2. 看 JVM GC 和 CPU jstat -gcutil pid 1000 # 3. 看慢方法Arthas java -jar arthas-boot.jar trace com.example.service.UserProfileServiceImpl loadUiConfigcurl的结果里dns和connect都很小说明网络没问题time_total大后端问题概率高。jstat看到 GC 时间频繁超过 500ms就要查是缓存对象太大还是 JVM 堆太小。trace能看到loadUiConfig内部哪一行最耗时比如roleProfileMapper.selectByRoleId每次调用都查数据库说明缓存没命中。一个常见假象是第一次加载快第二次刷新慢过了几秒又正常。这多半是懒加载路由的 chunk 文件太大Vite 构建时没有做代码分割。打开 Network 面板看是不是加载了一个 2MB 的 JS如果是就在router.addRoute的组件映射里继续拆或把 Ant Design Vue 按需引入。5.4 权限不生效、菜单不显示的核对清单个性化系统里权限不生效我一般按以下顺序查角色菜单表和用户配置表是否混用。如果用户改了自己的菜单顺序把角色菜单表也改了那别的同角色用户会受牵连。前端路由是否动态注册成功。打开控制台执行router.getRoutes()看该用户的路由是否存在。不存在说明后端返回的 menus 为空或componentMap没匹配上。JWT 里的角色信息是否过期。用户改了角色旧 token 里还带着老角色后端hasRole判断仍走旧权限。处理方式是登录态版本号用户角色一变版本号 1JWT 校验时发现版本不匹配就强制重新登录。缓存没删。角色配置改了ui:role:{roleId}还在前端拿到的仍是被覆盖前的菜单。后台保存接口里补一句删除缓存别只改数据库。如果菜单显示但点击后白屏多半是componentMap里没有对应组件或 import 路径错误。此时不要先怀疑后端看浏览器 console 的 “Failed to resolve component” 提示更快。6. 把个性化定制再往前推一步从配置表到可渲染的页面 Schema到上一步为止个性化还停留在“菜单顺序、首页路径、主题”这种组合级定制。如果再进阶就是把“用户能定制的内容”从“选哪个页面”升级成“页面里的字段和布局也能定制”。这是低代码平台的核心思路也是智慧校园管理系统后续经常要补的能力。做法是把页面配置抽象成一块 JSON Schema。比如学生个人中心的“常驻模块”区域后端下发{ moduleKey: studentCenter, schema: [ { key: timetable, title: 今日课表, widget: card, visible: true }, { key: score, title: 最新成绩, widget: table, visible: true }, { key: notice, title: 班级通知, widget: list, visible: false } ], layout: { cols: 2 } }前端写一个通用SchemaRenderer.vue遍历 schema 数组根据widget渲染卡片、表格、列表用户拖拽排序后把新的 schema 发回后端存到sys_user_profile.extension。这样“新增加一个定制组件”时后端只要多写一个组件入口前端多注册一个 widget 映射不需要新建页面。这个方案往前走要保持克制。第一次做的时候别把整个页面都交给 Schema 托管先从首页的“模块可见性 排序”开始。因为 schema 一复杂校验、回滚、版本管理都要跟上。给每条配置加version字段保存时只允许在最新版本上修改避免两个页面同时提交互相覆盖。验证配置是否正确两个动作就够一是用测试账号登录看 Pinia 里的uiConfig是否是预期结构二是直接改库里的 JSON 模拟极端情况——比如把menuOrder改成空数组、把homePage指向一个下架页面看系统会不会 404 后直接崩。校园系统的服务器配置通常不高压测时不要跑复杂场景用ab -n 2000 -c 100 http://localhost:8080/api/v1/ui/config看 p95 响应时间就行重点看 Redis 命中后的表现。把 Schema 渲染器抽成公共组件后你会发现后续“校长驾驶舱”“学院门户”这些需求本质上都是同一件事给不同人安排不同内容块。这个组件就是个性化定制的通用答案。本文还有配套的精品资源点击获取 智慧校园管理系统个性化定制：从用户配置表到动态路由的落地实践
简介这套基于SpringBoot与Vue的个性化定制智慧校园管理系统项目包面向需要完成毕业设计、课程实训或快速上手前后端分离开发的学习者。系统覆盖学生、教师、管理员三类角色包含用户管理、课程与选课、考试管理、资源共享、个性化定制及后台管理等完整功能模块可作为智慧校园场景下的可运行参考项目。压缩包共947个文件大小约37.23MB核心代码以197个Java、157个JavaScript、90个Vue等前后端源文件为主另有162个SVG图标、79个GIF演示、69个HTML页面、50个CSS样式表及SQL数据库脚本、万字Word文档覆盖源码、建库脚本、说明文档与演示素材其中Java与SpringBoot负责后端业务逻辑Vue与JavaScript承载前端交互SQL脚本可快速完成建表与数据初始化GIF和HTML便于直观查看运行效果。目前已有49人浏览学习除前后台完整可运行源码和数据库初始化脚本外文档还给出系统设计、架构与接口说明目录按功能模块划分便于逐块阅读、调试和二次开发。通过实际部署与调试可同时巩固SpringBoot接口开发、Vue组件化页面构建和MySQL数据建模等能力适合作为毕设或课程设计的起点也为后续扩展选课、成绩分析等个性化功能打下基础。1. 智慧校园管理系统里“个性化定制”到底改的是什么给学校做管理系统最容易踩的坑是把“个性化定制”理解成换主题色。实际使用时学生、教师、辅导员、后勤管理员进入同一套 Spring Boot Vue 的智慧校园管理系统看到的首页入口、默认打开的页面、消息通知范围、快捷操作顺序都应该不同。如果这些差异全靠 if/else 判断菜单、路由、首页会写出一堆分支以后加一个角色就得回代码里翻一遍。个性化定制的本质不是 UI 皮肤而是数据模型的分层数据层把“用户能改的东西”抽成偏好配置接口层把配置和权限合并后下发前端层根据配置动态生成路由与页面。把这三层理清楚比一开始就切页面更能决定项目能不能支持多角色、多校区、可扩展需求。换句话说这套系统的核心能力是“按人组页”。2. 打通后台数据用“角色默认值 用户覆盖值”承接个性化定制2.1 角色权限管“能不能看”个性化定制管“看到什么”先分清两件事否则后续所有表都会耦合。RBAC用户、角色、菜单回答的是这个用户能访问哪些接口、哪些菜单。它应该保持稳定改动频率低。个性化定制回答的是同一份菜单用户希望按什么顺序排、默认落在哪个页面、要不要把某个入口加到首页。这类数据允许用户自己改改动频率高。常见的错误是把“用户自定义菜单顺序”直接写进角色菜单表。后果是用户 A 调了顺序角色共享的菜单配置被改掉同角色的用户 B 也变了或者管理员在后台一保存角色配置又把用户自定义顺序覆盖没了。正确做法是设计两层配置让“角色默认值”和“用户覆盖值”合并。2.2 一张 sys_user_profile 表搞定平时九成需求先看角色默认配置这是可选表再看用户覆盖配置这是核心表。用户表结构大致长这样CREATE TABLE sys_user_profile ( id BIGINT NOT NULL COMMENT 主键, user_id BIGINT NOT NULL COMMENT 用户ID对应sys_user.id, theme VARCHAR(32) NULL COMMENT 主题标识默认default, home_page VARCHAR(128) NULL COMMENT 登录后默认首页路径, menu_order JSON NULL COMMENT 菜单path数组空表示沿用角色默认, quick_entries JSON NULL COMMENT 首页快捷入口如[{title:课表,path:/timetable}], notice_prefs JSON NULL COMMENT 通知订阅如班级通知、成绩提醒, extension JSON NULL COMMENT 扩展字段按业务自行约定, updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 更新时间, PRIMARY KEY (id), UNIQUE KEY uk_user_id (user_id) ) COMMENT 用户个性化配置表;几个关键选择。第一user_id 设置唯一键保证一个用户只有一条配置每次保存用插入或更新别用“用户每次点击都在原行上追加列”。第二menu_order 存菜单的 path不存数据库主键因为前端路由跳转用的是 path拿主键还得再翻译一次。第三MySQL 5.7 以上支持 JSON 类型可以直接JSON_CONTAINS做查询平时代码里取出后转成 Java 的 List 或 Map 也方便。对应的 MyBatis-Plus 实体Data TableName(sys_user_profile) public class UserProfile { TableId(type IdType.ASSIGN_ID) private Long id; private Long userId; private String theme; private String homePage; private String menuOrder; private String quickEntries; private String noticePrefs; private String extension; private LocalDateTime updatedAt; }这里没有用TableField(typeHandler JacksonTypeHandler.class)而是统一存字符串在 Service 层做 JSON 序列化与反序列化。原因很简单field 多了以后typeHandler 的自动映射在聚合查询里很容易被忽略出错后难看Service 层显式转换代码更直白也方便统一加默认值。2.3 合并规则角色配置打底用户覆盖层生效个性化配置最终要合成一份给前端渲染合并规则是先查角色默认配置再查用户配置用户配置里字段为 null 就沿用角色值不为 null 就覆盖角色值。写成服务代码如下public UiConfig loadUiConfig(Long userId, Long roleId) { // 角色默认配置后台可维护 RoleProfile roleProfile roleProfileMapper.selectByRoleId(roleId); // 用户个性化配置可能为空代表“没改过全用默认” UserProfile userProfile userProfileMapper.selectByUserId(userId); UiConfig config new UiConfig(); config.setTheme(roleProfile ! null ? roleProfile.getTheme() : default); config.setHomePage(roleProfile ! null ? roleProfile.getHomePage() : /dashboard); config.setMenuOrder(parseMenuOrder(roleProfile ! null ? roleProfile.getMenuOrder() : null)); // 用户值覆盖角色值 if (userProfile ! null) { if (StringUtils.hasText(userProfile.getTheme())) { config.setTheme(userProfile.getTheme()); } if (StringUtils.hasText(userProfile.getHomePage())) { config.setHomePage(userProfile.getHomePage()); } if (StringUtils.hasText(userProfile.getMenuOrder())) { config.setMenuOrder(parseMenuOrder(userProfile.getMenuOrder())); } } return config; }注意三个容易被忽略的点。角色配置本身不完全等于“系统默认”一个学校可能有多个角色学生默认到课表页教师默认到课程管理页后勤默认到报修处理页。用户配置字段用 null 表示“未覆盖”空字符串、空数组不是 null。menuOrder 传了[]就表示用户主动把所有菜单折叠了这在业务上说不通所以我一般约定[]仍然使用角色默认只有非空数组才参与覆盖。这个约定要在接口文档里写清楚前后端才不会对空数组理解不一致。后续版本要加“按班级/学院生效的推荐首页”不要在 user_profile 里不断加列而是把这类规则放进 extension JSON例如{grade:2024,departmentId:12}让合并逻辑按规则匹配。2.4 为什么选 JSON 列而不是动态建表有人会想每个用户配置不一样为什么不给用户动态建一张表或加一批字段动态建表会有几个直接问题MyBatis 的实体映射是编译期定死的表结构一变Mapper 的 resultMap 要跟着改学生选课、教师课表这类业务还会把表和业务逻辑耦合在一起迁移的时候非常痛苦。JSON 列牺牲了一点点类型约束换来的是“新增一个偏好项不用改表结构”这对智慧校园这类需求经常变化的系统来说更划算。等 JSON 里某个字段真的要被频繁查询和排序再把它抽成独立列那也是后话了。3. 把配置做成接口Spring Boot 聚合、缓存与权限控制3.1 先定接口一个 /ui/config 返回整棵配置树前后端分离开发时前端最怕后端把个性化配置拆成十几个接口页面要并行请求三四次才能组装出首页。常见做法是做一个聚合接口用户登录后前端调一次/api/v1/ui/config后端一次返回主题、首页、菜单、快捷入口、通知订阅前端拿到数据直接渲染。这样首屏加载也少了两轮网络往返。接口返回值大致是{ code: 0, data: { theme: dark-blue, homePage: /student/timetable, menus: [ { path: /student, title: 学习中心, children: [...] } ], quickEntries: [ { title: 查课表, path: /student/timetable } ] } }前端不用关心这个菜单树是后端从角色表、菜单表、用户配置表怎么拼出来的。它只需要知道只要登录状态有效这个接口返回的 menus 就是这个人最终能看到的路由集合。3.2 JWT 鉴权与接口白名单Spring Boot 3.x 集成 Spring Security 后包名是jakarta.*配置方式变化不算大。先建 JWT 过滤器Component public class JwtAuthenticationFilter extends OncePerRequestFilter { private final JwtUtil jwtUtil; Override protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException { String auth request.getHeader(Authorization); if (StringUtils.hasText(auth) auth.startsWith(Bearer )) { String token auth.substring(7); if (jwtUtil.validate(token)) { LoginUser loginUser jwtUtil.parse(token); UsernamePasswordAuthenticationToken authentication new UsernamePasswordAuthenticationToken( loginUser, null, loginUser.getAuthorities()); SecurityContextHolder.getContext().setAuthentication(authentication); } } filterChain.doFilter(request, response); } }这段过滤器做的事只有一件从请求头里取出 token解析成登录用户信息塞进 Spring Security 的上下文。后面的接口就能用AuthenticationPrincipal LoginUser拿到当前用户也能用PreAuthorize(hasRole(TEACHER))做细粒度判断。注意白名单要明确登录接口、验证码接口、静态资源接口应该放行个性化配置接口不能放行。漏写白名单会导致 Swagger 或验证码接口直接被 401 挡掉写太宽则等于把配置接口裸奔暴露。我一般用一个常量数组维护白名单每次加接口先检查是否应该进白名单。3.3 用 Spring Cache 给“按人定制”加缓存每个用户配置都查三张表高并发下数据库压力会很大。缓存方案按照偏好的 key 设计覆盖三个层级用户级配置、角色级配置、菜单树。缓存 key 前缀过期时间主动失效时机ui:user:{userId}60 分钟用户保存个性化配置时立即删除ui:role:{roleId}60 分钟后台修改角色配置时删除ui:menu:tree30 分钟菜单发布或角色菜单变更时删除用 Spring Cache 注解实现Cacheable(cacheNames ui:user, key #userId) public UiConfig getUserUiConfig(Long userId) { // 查 roleProfile userProfile 再合并 }实际开发中更常用 Redis 手动读写因为Cacheable只能处理 key 固定、入参简单的场景要有版本号或动态 TTL 就不太方便。用 RedisTemplate 时把 message 序列化器统一成 JSON方便在终端直接keys ui:user:*查看。这里有一个容易踩的坑“用户改了自己的配置但页面没变”。常见原因是改了库里数据却没有把ui:user:{userId}这个 key 删掉。另一个原因是 Redis 里存了旧对象而对象没实现Serializable反序列化直接报类型转换异常。解决方法是缓存对象固定用UiConfig这一个类不允许前端传入任意 JSON 覆盖整个缓存。3.4 配置参数参考连接池、超时与 TokenSpring Boot 项目的个性化接口是否稳定往往不取决于代码而取决于这些参数配置项常见基线说明server.tomcat.threads.max200最大工作线程线程不是越多越好spring.datasource.hikari.maximum-pool-size20数据库连接池上限按“峰值QPS x 单请求耗时”估算spring.data.redis.timeout3sRedis 操作超时避免 Redis 慢拖垮接口jwt.expire-hours12token 有效期学校场景建议短一些server.compression.enabledfalse对文本接口建议开启减少传输体积JWT 的有效期在校园场景不值得设太长。学生每天登录次数固定12 小时足够管理员可能连续用一整天设 24 小时也没问题。关键是 Redis 里要维护一个黑名单或“登录态版本号”用户改密码、被踢下线时旧 token 立刻失效而不是干等自然过期。3.5 配置文件里的口令别裸奔数据库口令、Redis 口令写在 application.yml 里是常态但提交到 Git 后一旦仓库泄露就等于裸奔。常见做法分两步敏感信息用环境变量注入即spring.datasource.password: ${DB_PASSWORD}如果必须写进 yml就用 Jasypt 的ENC(...)写法加密存储。注意加密盐值不要和密文放同一个文件。4. Vue 端落地路由动态加载、菜单递归渲染和个人首页4.1 工程搭建与目录划分Vue 侧我一般用 Vite 创建项目命令是npm create vuelatest选上 Router、Pinia。装完依赖后目录按“功能域”而不是“文件类型”划分src/ api/ # 按模块放请求 router/ # 静态路由 动态路由注册 stores/ # Pinia用户信息、配置信息 layout/ # 布局、侧边栏、导航 views/ student/ teacher/ admin/为什么按功能域划分智慧校园系统角色多、页面多按类型分会出现views/table/xxx.vue这种谁都看不懂的目录按角色分新人接到“给学生加一个页面”时直接进views/student找不需要猜测页面归属。4.2 axios 拦截器统一带 token、处理 401前后端分离最常见的会话问题是用户登录后每次请求都要带 tokentoken 失效后不能每个页面各弹一次提示。统一放在 axios 拦截器里// src/api/http.js import axios from axios const service axios.create({ baseURL: /api, timeout: 10000 }) service.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers.Authorization Bearer ${token} } return config }) service.interceptors.response.use( response response.data, error { if (error.response?.status 401) { localStorage.removeItem(token) window.location.href /login } return Promise.reject(error) } )这段代码的要点是request 拦截器做“注入”response 拦截器做“兜底”。把 token 读出来放到 Authorization 头后端 JWT 过滤器才能取到401 时统一清理登录态并跳转登录页而不是让每个页面自己写catch。baseURL用/api是约定走网关或后端同域开发环境再通过 Vite proxy 转发到后端端口从而避免浏览器直接跨域带来的 OPTIONS 预检。4.3 Vue Router 动态路由别把所有页面写死在静态路由表里个性化系统的核心是不同用户加载不同路由。Vite 构建时前端如果提前把所有页面都 import 进来路由表会很大而且后端配置的“这个人看不到某菜单”在前端完全不生效。正确做法是登录后拿/ui/config返回的 menus用router.addRoute动态注册// src/router/dynamic.js import Layout from /layout/index.vue const componentMap { Layout, studentTimetable: () import(/views/student/timetable.vue), teacherCourse: () import(/views/teacher/course.vue), adminReport: () import(/views/admin/report.vue) } export function registerDynamicRoutes(menus) { menus.forEach(menu { if (router.hasRoute(menu.path)) return router.addRoute({ path: menu.path, name: menu.name, component: componentMap[menu.component] || Layout, meta: { title: menu.title, icon: menu.icon, roles: menu.roles } }) if (menu.children?.length) { registerDynamicRoutes(menu.children) } }) }这里的componentMap扮演“前端组件白名单”的角色。后端返回的不是具体路径而是组件标识例如studentTimetable前端把标识映射到真正的 import 方法。这样后端改菜单、排序都不需要重新发前端包但后端也无法让前端加载一个不存在的组件。路由懒加载的好处是首屏只加载公共代码进入哪个页面才加载哪个页面student区域的代码不会影响teacher的打开速度。动态路由和静态路由要避免冲突。登录页、404、重置密码这类与角色无关的页面留在静态路由表业务页面全部动态注册。如果动态路由注册失败常见原因是router.hasRoute(menu.path)里的 path 带参数比如/student/detail/:id和真实路由/student/detail/100不一致这种情况要约定后端返回的 path 用配置模板前端注册再替换成真实值。4.4 菜单递归组件与按用户渲染首页菜单树是嵌套的前端不能写死三级。用递归组件最方便!-- src/layout/MenuTree.vue -- script setup defineOptions({ name: MenuTree }) defineProps({ menus: Array }) /script template template v-formenu in menus :keymenu.path a-sub-menu v-ifmenu.children menu.children.length :keymenu.path template #title{{ menu.title }}/template MenuTree :menusmenu.children / /a-sub-menu a-menu-item v-else :keymenu.path click$router.push(menu.path) {{ menu.title }} /a-menu-item /template /template用了 Ant Design Vue 的 Menu 组件递归组件名要和defineOptions({ name: MenuTree })保持一致否则在模板里MenuTree无法识别自己。缩进层级不要写死统一交给递归。首页组装更简单从 Pinia store 里读homePage如果没有值就默认/dashboard登录重定向时直接router.replace(config.homePage)。快捷入口就是quickEntries数组用v-for渲染成一排卡片点击跳转menu.path。这里不要加载时重新请求接口登录后/ui/config的数据已经放进 Pinia 且持久化到 localStorage刷新页面后从 localStorage 恢复避免每次刷新都闪一下登录页。4.5 一个典型坑直接赋值导致页面不变Vue 3 里用 reactive 声明的对象直接“深层”追加属性页面常常不更新。比如把接口返回的配置塞进对象const state reactive({ uiConfig: {} }) // 不生效 state.uiConfig.homePage data.homePage // 生效 state.uiConfig { ...state.uiConfig, ...data }原因很简单reactive的代理是在第一次赋值时建立的空对象没有homePage这个 key后续新增属性不会触发响应式依赖。排错时先看值是更新了但 DOM 没变还是值根本没更新。前者多半是响应式丢失用Object.assign或整个替换后者看接口返回什么。Vue Devtools 在这里很实用看 Pinia state 里uiConfig的值如果值变了页面没变就是模板里绑定的路径写错了常见是config.homePage与state.config.homePage混淆。5. 从“能用”到“扛得住”版本选型、参数调优和排错5.1 Spring Boot 版本选择2.7 还是 3.xJDK 怎么配智慧校园项目往往要部署到学校自己的服务器上环境没那么新版本选型要提前定。Spring Boot 3.x 要求 JDK 17 起Servlet 包从javax换成jakarta2.7.x 还可以跑 JDK 8。如果学校已经有 JDK 8 的运行环境硬上 Boot 3 会带来一堆部署成本如果新项目、新服务器就直接 JDK 17 Boot 3.x毕竟 Boot 2 的社区维护周期已经结束。技术选型推荐组合说明JDK 8 Spring Boot 2.7适合已有旧服务器javax 包名MyBatis-Plus 兼容好JDK 17 Spring Boot 3.x适合新部署jakarta 包名Spring Security 6 语法变化Vue 3 Vite Ant Design Vue前后端分离标配避免引入过重 UI 框架初学容易犯的错是本地装了 Boot 3代码里还写javax.servlet启动直接报 NoClassDefFoundError或者本地 JDK 21 但生产 JDK 8编译用高版本导致生产跑不起来。统一在 pom 里把java.version和maven.compiler.source/target钉死本地、测试、生产保持一致。5.2 几个真正影响体验的参数下面的参数我在每个 Spring Boot Vue 项目落地时都会过一遍配置项参考值作用server.tomcat.threads.max200限制并发执行线程防线程爆炸server.tomcat.accept-count100等待队列长度和线程数一起调spring.datasource.hikari.maximum-pool-size20数据库连接数太高反而拖垮数据库spring.datasource.hikari.connection-timeout30000拿不到连接的等待时间spring.mvc.async.request-timeout30000异步请求超时个性化配置接口可设置server.compression.enabledtrue开启 gzipJSON 体积通常能减少 60%user_profile这类配置表数据量不大但被高频读取索引除了user_id唯一键还要考虑后台按主题、通知偏好做统计时的查询必要时给 extension JSON 里的常用字段建生成列索引。MySQL 8 支持JSON_EXTRACT的表达式索引但学校环境可能是 MySQL 5.7所以我的经验是运营要统计“有多少人开了成绩提醒”就别在 JSON 里查单独建一个notice_grade_flag TINYINT列并加索引代码里写两份一份给配置、一份给统计。5.3 接口变慢时按这条链路查前端反馈“首页转了 3 秒”不要立刻怀疑代码。先问三个问题是只有一个人慢还是大家都慢是首次登录慢还是每次登录都慢后端接口返回慢还是前端渲染慢然后按这条命令链路去定位# 1. 看接口完整耗时 curl -o /dev/null -s -w total%{time_total} dns%{time_namelookup} connect%{time_connect}\n \ -H Authorization: Bearer $TOKEN \ http://localhost:8080/api/v1/ui/config # 2. 看 JVM GC 和 CPU jstat -gcutil pid 1000 # 3. 看慢方法Arthas java -jar arthas-boot.jar trace com.example.service.UserProfileServiceImpl loadUiConfigcurl的结果里dns和connect都很小说明网络没问题time_total大后端问题概率高。jstat看到 GC 时间频繁超过 500ms就要查是缓存对象太大还是 JVM 堆太小。trace能看到loadUiConfig内部哪一行最耗时比如roleProfileMapper.selectByRoleId每次调用都查数据库说明缓存没命中。一个常见假象是第一次加载快第二次刷新慢过了几秒又正常。这多半是懒加载路由的 chunk 文件太大Vite 构建时没有做代码分割。打开 Network 面板看是不是加载了一个 2MB 的 JS如果是就在router.addRoute的组件映射里继续拆或把 Ant Design Vue 按需引入。5.4 权限不生效、菜单不显示的核对清单个性化系统里权限不生效我一般按以下顺序查角色菜单表和用户配置表是否混用。如果用户改了自己的菜单顺序把角色菜单表也改了那别的同角色用户会受牵连。前端路由是否动态注册成功。打开控制台执行router.getRoutes()看该用户的路由是否存在。不存在说明后端返回的 menus 为空或componentMap没匹配上。JWT 里的角色信息是否过期。用户改了角色旧 token 里还带着老角色后端hasRole判断仍走旧权限。处理方式是登录态版本号用户角色一变版本号 1JWT 校验时发现版本不匹配就强制重新登录。缓存没删。角色配置改了ui:role:{roleId}还在前端拿到的仍是被覆盖前的菜单。后台保存接口里补一句删除缓存别只改数据库。如果菜单显示但点击后白屏多半是componentMap里没有对应组件或 import 路径错误。此时不要先怀疑后端看浏览器 console 的 “Failed to resolve component” 提示更快。6. 把个性化定制再往前推一步从配置表到可渲染的页面 Schema到上一步为止个性化还停留在“菜单顺序、首页路径、主题”这种组合级定制。如果再进阶就是把“用户能定制的内容”从“选哪个页面”升级成“页面里的字段和布局也能定制”。这是低代码平台的核心思路也是智慧校园管理系统后续经常要补的能力。做法是把页面配置抽象成一块 JSON Schema。比如学生个人中心的“常驻模块”区域后端下发{ moduleKey: studentCenter, schema: [ { key: timetable, title: 今日课表, widget: card, visible: true }, { key: score, title: 最新成绩, widget: table, visible: true }, { key: notice, title: 班级通知, widget: list, visible: false } ], layout: { cols: 2 } }前端写一个通用SchemaRenderer.vue遍历 schema 数组根据widget渲染卡片、表格、列表用户拖拽排序后把新的 schema 发回后端存到sys_user_profile.extension。这样“新增加一个定制组件”时后端只要多写一个组件入口前端多注册一个 widget 映射不需要新建页面。这个方案往前走要保持克制。第一次做的时候别把整个页面都交给 Schema 托管先从首页的“模块可见性 排序”开始。因为 schema 一复杂校验、回滚、版本管理都要跟上。给每条配置加version字段保存时只允许在最新版本上修改避免两个页面同时提交互相覆盖。验证配置是否正确两个动作就够一是用测试账号登录看 Pinia 里的uiConfig是否是预期结构二是直接改库里的 JSON 模拟极端情况——比如把menuOrder改成空数组、把homePage指向一个下架页面看系统会不会 404 后直接崩。校园系统的服务器配置通常不高压测时不要跑复杂场景用ab -n 2000 -c 100 http://localhost:8080/api/v1/ui/config看 p95 响应时间就行重点看 Redis 命中后的表现。把 Schema 渲染器抽成公共组件后你会发现后续“校长驾驶舱”“学院门户”这些需求本质上都是同一件事给不同人安排不同内容块。这个组件就是个性化定制的通用答案。本文还有配套的精品资源点击获取