简介这是一份基于SpringBoot、Vue.js与ElementUI技术栈的后台管理系统模板源码适合正在学习前后端分离开发、需要快速搭建管理后台的开发者参考。后端以SpringBoot提供RESTful API与业务逻辑前端由Vue.js配合ElementUI组件库构建交互界面二者通过接口联调构成一个可运行的基础工程。压缩包共129个文件包含62个Java后端源码、17个Vue组件、17个JS脚本、8个SQL脚本及若干配置与静态资源文件整体仅4.93MB结构清晰方便按模块展开学习。资源内覆盖项目目录结构、开发流程以及HikariCP、Logback、Spring Security等常见软件/插件的集成思路对理解企业级后台系统的分层设计与前后端协作方式很有帮助。目前已有231人学习是入门SpringBootVue全栈开发的一份实用模板。 最近不少朋友在找我聊后台管理系统要么是毕业设计要交差了要么是公司内部工具急着上线大家一上来就卡在登录、权限、菜单这些基础功能上。我把一套基于 SpringBoot Vue ElementUI 的后台管理系统模板源码整理了出来把自己实际搭建过程中踩过的坑和设计思路都沉淀在里面。这篇文章不打算做成那种“照着敲一遍”的教程而是想把它拆开讲清楚模板到底该包含哪些东西、每个模块为什么这样设计以及拿到模板后怎么最快改成自己的项目。这篇内容适合两种人一种是需要快速搭起一个后台管理系统的人另一种是虽然能写完功能但想知道“项目结构怎么组织才更合理”的开发者。不管你是主力后端还是主力前端只要能看懂 Java 和 Vue 的基础语法这套模板的实现思路就能直接拿过去用。1. 模板到底该装哪些东西不该装哪些1.1 后台系统真正浪费时间的不是业务后台管理系统做了几个之后就发现业务本身反而好写真正浪费时间的是那些每个系统都绕不开的基础设施。登录认证、权限控制、菜单路由、用户管理、角色分配、操作日志、文件上传这些功能看着不起眼但从零开始写一遍没有两周下不来。尤其权限模型后端要控制接口前端要控制路由和按钮两边还得对得上稍不留神就变成一团乱麻。我把这些通用能力提前整理成模板就是希望接新项目的时候直接把这一层拿过去用自己专心写业务表。模板里包含的用户、角色、菜单、日志、字典、文件上传这些模块本质上都是“系统底座”跟具体业务无关。这样新项目启动时不需要再从登录页开始写起。1.2 为什么网上模板那么多这套组合依然能打网上的后台管理模板确实不少但很多是纯前端模板比如基于 Vue ElementUI 的 Admin 模板页面展示很漂亮后端接口却要自己从头写。而 SpringBoot Vue ElementUI 的组合意味着从前端到后端都有一套完整可运行的代码拿来就能跑这点对新手尤其友好。这套技术栈不一定最新但胜在稳定和资料多。SpringBoot 2.x 配合 MyBatis-Plus写增删改查效率很高Vue 2 加 ElementUI 的组件生态非常成熟随便一个报错都能搜到答案。对于毕业设计、中小型管理系统、公司内部工具来说这套组合非常稳。如果完全没有历史包袱也可以考虑 Vue 3 Element Plus但模板里的设计思路是通用的换框架不影响整体结构。1.3 模板源码的边界意识做模板最忌讳什么都往里塞。我的原则是只保留通用能力不写具体业务。模板里看不到“商品管理”“订单管理”这种业务页面只有“系统管理”下的用户、角色、菜单、日志这些基础模块。这样做的好处有三个一是代码量可控别人拿来容易看懂二是业务扩展不会跟框架代码纠缠在一起三是新人接手时能很快分清哪些是模板能力哪些是需要自己改的业务。说实话一个模板好不好用不靠功能堆砌而靠边界清晰。我见过太多模板把示例业务写得很深结果想删都删不干净改起来比从零写还痛苦。做好边界才是模板价值最大的地方。2. 后端SpringBoot 的“地基”细节2.1 统一响应体和全局异常处理先把这个定死后端接口返回给前端的数据格式如果不统一前端每个请求都要单独判断是成功还是失败代码会变得非常零碎。模板里定义了一个ResultT类包含 code、message、data 三个字段所有接口统一返回这个对象。成功是 200业务失败是 500未登录是 401无权限是 403。配合全局异常处理器RestControllerAdvice业务代码里就不用到处写 try-catch。参数校验不通过直接抛一个BusinessException全局处理器会捕获并转成统一格式。这样前端 Axios 拦截器就能统一处理这些 code不需要关心每个接口内部的异常细节。public class ResultT { private int code; private String message; private T data; public static T ResultT ok(T data) { return new Result(200, 操作成功, data); } public static T ResultT fail(int code, String message) { return new Result(code, message, null); } }2.2 JWT 登录认证用拦截器就够了别一上来就上 SecuritySpring Security 加 JWT 是标准组合但对一个后台管理系统模板来说确实偏重。配置复杂学习成本高新人接手容易一头雾水。模板里用的是 JWT HandlerInterceptor 的方式登录成功后生成 token前端每次请求在 header 里带上后端拦截器校验 token 并解析出用户信息放到 ThreadLocal 里controller 里直接取当前用户。如果担心接口权限不够细可以再加一个自定义注解RequirePermission在拦截器里校验用户是否拥有某个权限码。这个方案足够支撑绝大多数管理系统代码也清晰。以后真需要上 Security登录逻辑可以保留把拦截器替换成过滤器链就行改动成本并不高。2.3 MyBatis-Plus 自动填充与启动初始化表MyBatis-Plus 的MetaObjectHandler可以自动填充创建时间、更新时间省得每次 insert 和 update 手动 set。模板里实现了一个字段填充处理器插入时自动填 createTime、updateTime更新时自动更新 updateTime。这个细节看似简单但能省掉不少重复代码。另外关于“表不存在自动建表”MyBatis-Plus 本身不自带这个能力。模板里的做法是放一份 schema.sql项目启动时用 Spring 的DataSourceInitializer执行如果表不存在就创建。比直接依赖 Hibernate 的 ddl-auto 更可控也更容易定位建表失败的问题。MySQL、PostgreSQL 都适用只要你把 SQL 写到对应格式。2.4 Profiles 多环境配置测试和生产分开很多小项目把所有配置都写在 application.yml 里数据库地址写死密码也写死。这在本地跑没问题一部署到服务器就尴尬了。模板里拆成了三份文件application.yml 放公共配置application-dev.yml 配本地数据库application-prod.yml 配服务器数据库。切换环境只需要启动参数指定--spring.profiles.activedev或 prod。数据库密码不要直接写在 yml 里用环境变量占位比如${DB_PASSWORD}这样代码仓库里不会出现敏感信息。这个习惯一定要养成尤其是项目后面要交给别人维护的时候。3. 前端Vue ElementUI 的组装逻辑3.1 目录结构先定好后面新增页面不迷路前端项目用 Vue CLI 创建后我先把 src 目录拆成 api、assets、components、router、store、utils、views。api 目录放所有接口请求按模块拆文件views 目录放页面组件同样按模块分目录。这样新增一个“客户管理”模块时只需要在 api 下加 customer.jsviews 下加 customer 文件夹路由里挂载一下所有代码的位置都是可预判的。模板项目最怕的就是文件随便放今天创建一个页面丢在 views 根目录明天写个接口塞到某个组件里后面找代码能找半天。目录结构提前定好多人协作时也能尽量避免无意义的代码冲突。3.2 路由权限静态路由打底动态路由加菜单后台管理系统的路由不能全写死在 router 里因为不同角色看到的菜单不一样。模板的做法是router 里只保留 login、404、首页这些公共路由登录成功后再根据后端返回的菜单数据用router.addRoutes动态添加业务路由。侧边栏菜单也根据同一份菜单数据渲染这样后端配置好角色对应的菜单前端菜单和路由就一起变了。需要注意Vue 2 配合 Vue Router 3 时用的是 addRoutes到了 Vue Router 4 这个方法改名了。如果你用 Vue 3记得查一下对应版本的动态路由写法。3.3 Axios 封装别让接口请求散落各处Axios 如果不封装每个组件里都会出现一段重复的请求逻辑之后改请求地址或者说统一加超时时间会非常麻烦。模板里在 utils/request.js 里集中封装了一个 axios 实例主要做三件事设置 baseURL请求拦截器里从 store 拿 token 放到 header响应拦截器里统一处理 code遇到 401 跳登录页遇到 500 提示后端报错信息。每个 api 模块只需要写具体的请求方法比如import request from /utils/request export function listUser(params) { return request({ url: /system/user/list, method: get, params }) }组件里调用listUser(params).then(res { ... })就行整体非常清爽。这个封装是前端项目的基本功建议每个项目都这样做。3.4 ElementUI 表格和表单的二次封装写多了就会发现后台系统的列表页几乎都是“表格 分页 搜索表单”。所以模板里封装了一个 PageTable 组件把 el-table、el-pagination、搜索表单都包进去。使用时只需要传表格列配置、搜索项配置、查询接口组件内部帮你处理搜索、分页、重新加载。还有 DialogForm 组件用来承载新增和编辑弹窗。封装有两个核心原则第一不要封得太重配置项要能覆盖多数场景但不能把 el-table 原本的功能都堵死第二留好插槽比如表格操作列、表单自定义项都可以通过 slot 扩展。这样写一个新业务页面时可能只需要几十行配置而不是几百行模板代码。4. 模板内置的通用模块权限、日志、文件、字典4.1 RBAC 权限模型五张表把用户角色菜单串起来模板里的权限模型是标准 RBAC用户表、角色表、菜单表、用户角色关联表、角色菜单关联表。用户不直接跟菜单绑定而是通过角色间接拥有菜单。菜单表里有一个 type 字段区分目录、菜单和按钮目录对应侧边栏分组菜单对应路由页面按钮对应页面里的操作权限。比如“删除用户”这个按钮菜单表里会有一条按钮权限记录前端用v-permission指令判断当前用户有没有这个权限码没有就隐藏按钮。后端接口再用拦截器校验一次防止有人绕过前端直接调接口。这样前后端权限是闭环的不会出现“前端藏了按钮但接口还能直接访问”的情况。4.2 操作日志AOP 切一下别在每个方法手写操作日志如果手动在每个方法里写记录代码特别容易漏而且代码重复严重。模板里用 AOP 实现定义一个Log注解支持模块名、操作类型这些属性然后写在切面里解析注解和方法参数把操作人、操作时间、请求参数、IP 等信息存到日志表。为了不影响主流程性能可以用Async把日志落库做成异步。登录日志我用监听器来记录登录成功和登录失败各发一个事件监听器分别落库。需要注意记录参数时不要直接 toString 整个对象里面可能包含密码等敏感信息该脱敏的字段要提前处理掉。4.3 文件上传和 Excel 在线预览怎么做文件上传模块也是后台管理系统的标配。后端提供一个统一的上传接口把文件存到服务器指定目录或者对象存储然后返回可访问的 URL。前端封装一个 FileUpload 组件对接 el-upload业务页面直接引。如果要在后台管理系统里在线预览 Excel简单做法是用前端插件把 Excel 解析成表格展示比如用 xlsx 库读取文件后渲染成 el-table。复杂一点可以由后端把文件转成 HTML 或 PDF 再预览。我的建议是内部系统直接用 xlsx 解析简单够用不要去接那种按次收费的付费预览服务划不来。4.4 数据字典让下拉框不再硬编码后台管理系统里到处是下拉框性别、状态、类型、审核结果。如果这些选项硬编码在前端或者后端以后加一个选项就要改代码重新发布。模板里做了数据字典表存字典类型和字典项包括 label、value、sort 等字段。前端提供 DictSelect 组件通过 dictType 自动请求字典项渲染下拉框后端也提供字典查询接口。维护的时候在系统管理页面里直接增删改选项不需要动代码。这个模块对运营类后台特别有用因为运营经常要加新的选项每次都发版谁也受不了。5. 从模板到上线改造顺序与部署避坑5.1 拿到模板后第一件事改包名和数据库连接很多人拿到模板就急着读代码但更建议先做“换壳三步”。第一步全局替换项目名和包名比如把 com.example 换成你自己公司的域名反写记得连 pom.xml 里的 groupId 和 artifactId 一起改。第二步修改数据库连接、Redis 连接这些环境配置。第三步导入初始化 SQL确保表结构建好。这三步做完先把项目原样跑起来确认登录页能进、菜单能点、用户能增删改然后再开始写业务。这么做能避免后续排错时分不清是环境问题还是代码问题。我见过不少人一上来就改业务结果登录都过不去最后发现是数据库没初始化白白浪费半天。5.2 本地跑通前端后端的配置顺序本地开发推荐先起后端再起前端。后端用 IDEA 打开等 Maven 依赖下载完启动 Application 类前端在项目根目录执行 npm install 安装依赖然后 npm run serve 启动开发服务器。有几个细节容易踩坑Node 版本太高可能导致 node-sass 安装失败建议用 Node 14 或 16npm install 太慢可以换成淘宝镜像源后端端口统一设置为 8080前端开发服务器单独一个端口同时用 Vue CLI 的 devServer.proxy 把 /api 请求转发到后端这样前端开发时就没有跨域问题也不用后端去配 CORS。5.3 三种部署方式和你最可能遇到的坑后台管理系统部署方式主要有三种。第一种前后端分离部署前端打包成 dist 目录放到 Nginx 下Nginx 把 /api 请求反向代理到后端 8080 端口这种最灵活推荐正式环境用。第二种把前端 dist 目录复制到后端 resources/static 下打成单一 jar 包运行适合小项目和毕业设计演示不用单独装 Nginx。第三种Docker 容器化部署前后端各一个容器适合需要频繁发布的环境。最容易踩的坑是Vue Router 用 history 模式时Nginx 必须配 try_files否则刷新页面就 404。如果你不想折腾 Nginx可以改成 hash 模式URL 里多一个 # 号但省心很多。小项目用 hash正式项目再由运维来配 history这个取舍很实用。5.4 静态资源 404、端口冲突、日期格式这些老问题最后聊几个我实际调试模板时反复遇到的问题。静态资源 404先检查前端打包后的路径是不是绝对路径如果部署在子路径下要在 vue.config.js 里设置 publicPath 为相对路径或子路径。端口冲突时在 application.yml 里改后端端口或者用系统命令查占用进程再 kill 掉。日期格式是另一个高频问题。SpringBoot 返回的 LocalDateTime 默认序列化格式带 T建议在配置里加 Jackson 全局配置指定成yyyy-MM-dd HH:mm:ss。MySQL 连接还要注意时区问题JDBC URL 里加上serverTimezoneAsia/Shanghai否则日期会差 8 个小时。这些坑看着很小但部署现场能卡半天提前处理好能省很多事。说句实在话模板项目最大的价值在于把“约定”固定下来。同一个团队里新人照着模板写代码出来的风格不会差得太远接新项目时省掉最基础的那部分至少能提前两周进入业务开发。我在整理这套模板时最深的体会是不要在模板里堆一堆看起来很酷但用不到的功能能让业务快速跑起来能让人看懂就是好模板。如果你后续基于这个模板扩展了更多模块也欢迎回来交流。本文还有配套的精品资源点击获取