做过几套管理后台之后你会发现最值钱的不一定是代码本身而是从数据库设计到前后端联调这一整条链路上的细节。我手上刚交付的这套 Web 及游戏管理平台后台用的就是标题里这套江湖地位很高的组合SpringBoot 做接口服务Vue 做管理端界面MyBatis 负责数据持久化MySQL 存业务数据。源码把游戏上架、用户管理、公告运营、充值订单、数据统计这些后端功能全串起来了不是那种只能拿来应付增删改查演示的教学 demo。这篇文章我会照着这个管理平台把建表、后端接口、前端页面、联调、打包部署全过程拆开讲。适合两类人一是准备做毕业设计或者课程设计、想找一个完整可演示项目的学生党二是刚入职、被甩了一个后台管理系统需要快速上手维护的初级工程师。你能看到怎么设计权限、怎么写 MyBatis 动态 SQL、怎么让 Vue 路由跟着角色走这些内容放到任何做游戏开发或者互联网产品的中小公司里都能直接复用。1. 项目整体设计与技术选型1.1 运营后台的核心需求所谓 Web 及游戏管理平台说白了就是给游戏发行和运营团队用的内部系统。核心需求不外乎这么几块管理员登录与权限控制不同角色看到不同菜单按钮也要跟着角色决定是可用还是置灰游戏信息管理包括游戏名、图标、下载地址、分类、上下架状态、排序值公告与活动管理运营人员发布维护公告、版本更新说明这些内容玩家与订单管理查看注册用户、充值订单必要时导出报表最后是一块数据看板汇总下载量、充值金额、日活跃数据。需求听起来不复杂但代码层的难点从来不在于单表 CRUD而在于这些模块之间的关联。游戏上下架要联动前端的展示状态权限要联动路由和接口订单流水要联动玩家账号和游戏信息。我见过不少初学者上手就只做单表增删改查到答辩被问一句“你的权限是怎么控制的”“用户状态改了为什么登录不进去”直接卡壳。所以这套源码在规划阶段权限模型、状态流转、管理流程就必须先说清楚不能等代码写一半再补。1.2 为什么是 SpringBoot MyBatis MySQL Vue技术选型这件事讲求的不是最新最好而是生态成熟、队友最容易接手。后端选 SpringBoot是因为它已经是 Java 企业级开发的事实标准。配置自动化、内嵌 Tomcat、打出一个 jar 就能跑相比传统 SSM 省掉一堆 XML建项目的成本几乎等于零。数据层我倾向 MyBatis 而不是 JPA/Hibernate理由非常现实对比项MyBatisJPA/HibernateSQL 控制力手写 SQL完全可控自动生成为主复杂查询要学 JPQL学习成本低会 SQL 就能上手高要理解实体生命周期和缓存机制复杂统计查询XML 搞定多表联查、聚合分组要么写原生 SQL要么抱 Specification 大腿团队协作认可度国内普及率高面试也常考相对没那么主流游戏运营后台的筛选条件非常动态比如“按渠道时间状态筛充值流水”这种场景用 MyBatis 的动态 SQL 往下写直观而且排查问题也快不至于被自动生成的 SQL 绕晕。MySQL 做存储对中小规模后台来说性能和稳定性完全够用。前端选 Vue 的原因同样实际。组件化开发和渐进式上手曲线很适合中后台系统配合 Element UI / Element Plus 这样的组件库表格、表单、弹窗、分页这些后台高频组件基本拿来就用。相比 React 那套生态Vue 在中小团队、学生项目里的综合性价比更高。1.3 前后端分离架构与工程结构典型的前后端分离项目。后端只暴露 RESTful 接口前端通过 HTTP 请求拿到 JSON 再渲染页面。接口对齐全靠 Swagger 或者一份简洁的接口文档。后端工程结构建议这样拆com.gameadmin ├── controller ├── service ├── mapper ├── entity ├── config ├── common └── util前端目录结构src ├── api ├── assets ├── components ├── router ├── store ├── views └── utils这套结构最大的好处是职责边界清晰。往后加一个模块后端加 controller、service、mapper 三件套前端在 views 下加页面并注册路由改动彼此独立不容易互相打架。别小看这个分层项目一旦到几十个模块结构乱不乱直接决定你要多花多少时间去定位 bug。2. 核心细节解析与实操要点2.1 数据库建模字段、索引与状态设计管理后台的表设计最忌讳一张大表搞定所有事。我在这套源码里会拆成至少这几类核心表管理员表、角色表、菜单权限表、游戏信息表、玩家表、订单流水表、公告表。以游戏信息表为例DDL 大概长这样CREATE TABLE game_info ( id bigint NOT NULL AUTO_INCREMENT COMMENT 主键, game_name varchar(128) NOT NULL COMMENT 游戏名称, game_category varchar(32) DEFAULT NULL COMMENT 分类, icon_path varchar(255) DEFAULT NULL COMMENT 图标地址, download_url varchar(255) NOT NULL COMMENT 下载地址, intro text COMMENT 游戏简介, status tinyint NOT NULL DEFAULT 0 COMMENT 状态0草稿 1待审核 2已上架 3已下架, sort_order int DEFAULT 0 COMMENT 排序权重, operator varchar(64) DEFAULT NULL COMMENT 最后操作人, create_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT游戏信息表;有几个细节必须专门强调。字符集一定用 utf8mb4。游戏简介和公告里经常出现 emoji 或特殊符号老版 utf8 会直接导致写入失败或者静默截断。时间字段用 datetime 而不是 varchar方便 SQL 做排序和范围查询。create_time 设默认值更新时就不用每次手动维护。状态字段用数字而不是字符串枚举。数字在查询时索引效率和排序稳定性都更好至于数字对应的含义放在后端枚举类或者前端字典文件里统一维护。订单流水这类数据量大的业务表建议按日或按月分表或者至少在 create_time 上加好索引。后台按时间范围聚合是高频操作全表扫描一旦遇到大表接口响应慢到让你怀疑人生。2.2 MyBatis 配置与 XML 映射的关键写法拉下这套源码第一步改数据库密码第二步就是看 MyBatis 配置。application.yml 里比较常见的配置项spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/game_admin?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalseallowPublicKeyRetrievaltrue username: root password: yourpassword mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.gameadmin.entity configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImplmap-underscore-to-camel-case 这个开关是高频考点。数据库字段 create_time 和 Java 实体属性 createTime打开之后 MyBatis 自动映射不用在 XML 里给每个字段写 resultMap。当然遇到复杂联查结果比如一张表 JOIN 了四五张表返回自定义 VO这时候该写 resultMap 还是要写别偷懒。实际项目里批量操作的场景很多比如一次批量上架多款游戏。Mapper XML 里用 foreach 写批量插入insert idbatchInsertGame parameterTypelist insert into game_info (game_name, game_category, icon_path, download_url, status, sort_order) values foreach collectionlist itemitem separator, (#{item.gameName}, #{item.gameCategory}, #{item.iconPath}, #{item.downloadUrl}, #{item.status}, #{item.sortOrder}) /foreach /insert再说 TypeHandler。很多人只在面试题里见过这词实际上如果你实体里定义了枚举字段或者需要把 JSON 字符串映射成对象TypeHandler 就派上用场。比如 status 字段从数据库读出来是 tinyint业务上想直接得到 GameStatus 枚举可以写一个 TypeHandler 完成数字和枚举互转。但一般项目如果枚举不复杂直接用 Integer 存着在 Service 层做一次状态转换也够用了不必强行上 TypeHandler。分页我会用 PageHelper。原生 MyBatis 搭配 PageHelper需要加依赖PageHelper.startPage(pageNum, pageSize); ListGameVO list gameMapper.selectGameList(queryDTO); PageInfoGameVO pageInfo new PageInfo(list);注意 PageHelper 这一行必须紧跟查询语句中间不能插任何其他 SQL 操作否则分页会错乱。我见过不少项目把 MyBatis-Plus 和原生 MyBatis 的依赖混在一起用结果分页拦截器互相干扰接口返回全量数据线上数据一大直接卡死。用哪套就只引入哪套这是经验之谈。2.3 Vue 路由与页面权限实现管理后台的前端不是简单的页面堆砌而是要跟着权限体系做动态菜单。常见做法是登录成功后拿当前用户的路由权限标识前端匹配配置好的路由表通过 addRoute 动态注册。路由基础配置const routes [ { path: /login, component: () import(/views/Login.vue), hidden: true }, { path: /, component: () import(/layout/Index.vue), redirect: /dashboard, children: [ { path: dashboard, name: Dashboard, component: () import(/views/Dashboard.vue), meta: { title: 数据看板, roles: [admin, operator] } }, { path: game/list, name: GameList, component: () import(/views/game/GameList.vue), meta: { title: 游戏管理, roles: [admin] } } ] } ]路由守卫里做登录校验router.beforeEach((to, from, next) { const token localStorage.getItem(token) if (!token to.path ! /login) { next({ path: /login }) return } next() })Vue 路由传参是另一处容易混淆的点。query 和 params 的区别多说一句query 传参会显示在 URL 里比如 ?type1page2刷新页面参数还在params 配合 name 使用正常情况下不会出现在地址栏但刷新后可能丢失。后台管理系统里涉及筛选条件的跳转我建议优先用 query因为用户翻页、刷新后浏览器地址栏还能继续保留筛选状态体验好很多。2.4 跨域处理与 axios 统一封装前后端分离开发时前端跑在 8080后端跑在 8081Ajax 请求默认就是跨域。开发环境最简单是前端 devServer 配代理生产环境用 Nginx 反向代理但后端最好也开 CORS 兜底不然前端同学调试起来很痛苦。SpringBoot 里配全局 CORSConfiguration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }前端 axios 封装主要做两件事拦截响应统一处理业务错误码和 401 跳登录把 token 加到请求头。utils/request.js 里一开始就要把这两件事做好后续所有接口直接引用这个实例不用每个页面重复写一堆模板代码。3. 完整实现流程与核心环节落地3.1 环境准备与骨架初始化拿到这套源码第一步搭环境。我建议的版本组合是JDK 1.8 或 JDK 11SpringBoot 2.7.x 兼容这两个版本如果换到 SpringBoot 3.x就必须上 JDK 17。数据库用 MySQL 5.7 或 8.0推荐 8.0避开老版本在字符集和时区上的一些坑。Maven 3.6Node.js 14Vite 或 Vue CLI 都行注意 Node 和 Vite 的版本兼容。环境装好之后按这个顺序来建库CREATE DATABASE game_admin DEFAULT CHARACTER SET utf8mb4;导入项目提供的 sql 文件表结构和基础数据一次到位。改后端 application.yml 里的数据库账号密码。前端 npm install 装依赖npm run dev 启动开发服务器。后端 mvn spring-boot:run 或直接跑主类。默认端口按项目实际情况改 yml 和 vite.config.js。这里多说一句别嫌初始化 sql 麻烦直接在库里手工建表的人后面基本都会后悔字段注释写不全、索引漏建等联调的时候全暴露出来了。3.2 后端核心代码登录、鉴权与分页查询登录接口是后台系统的入口。密码不能明文存我常用 BCrypt 或 MD5 加盐。如果不引入 Spring Security用框架自带的工具类也能做加密比较关键是加盐逻辑必须统一别一个模块一种算法。登录成功后的令牌有人用 Redis 存 Session有人用 JWT。JWT 的方式后端写一个拦截器或过滤器从请求头取 Token验签通过后把用户信息放到 ThreadLocal 里后续业务逻辑直接拿当前操作人public class AuthInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token request.getHeader(Authorization); // 校验token失败返回401成功把用户信息放ThreadLocal return true; } }分页查询在 Service 层建议这样写PageHelper.startPage(pageNum, pageSize); ListGameVO list gameMapper.selectGameList(queryDTO); PageInfoGameVO pageInfo new PageInfo(list); return Result.ok(pageInfo);还有一个安全细节容易被忽略。后台如果有富文本编辑器比如游戏介绍、公告内容这些输入如果不做处理等于把 XSS 攻击面敞开。我一般会在后端加一个全局过滤器拦截请求参数把 script 标签之类的危险关键词做转义处理。涉及文件上传比如运营传海报图或者 PDF 说明文档不要只看扩展名还要校验 Content-Type 和文件头否则伪装成图片上传个可执行文件的事不是不可能。这套源码规模不大但安全基建从第一天就要立起来。3.3 前端核心代码列表页、搜索表单与状态切换前端列表页套路非常固定顶部搜索表单中间表格底部翻页。配合 Element Plus 写起来很快el-table :datatableData stripe el-table-column propgameName label游戏名称 / el-table-column propstatus label状态 template #default{ row } el-tag :typestatusTag(row.status){{ statusText(row.status) }}/el-tag /template /el-table-column el-table-column label操作 template #default{ row } el-button sizesmall clickeditGame(row)编辑/el-button el-button sizesmall typedanger clicktoggleStatus(row)上架/下架/el-button /template /el-table-column /el-table el-pagination v-model:current-pagepage v-model:page-sizesize :totaltotal layouttotal, prev, pager, next current-changeloadList /新手容易犯的错是在每个页面里写 if/else 处理状态文案。把“0草稿、1待审核、2已上架、3已下架”这类字典抽成公共映射文件页面里统一引用。后期状态一多改一处忘一处前端显示和后端数据对不上排查起来相当浪费时间。3.4 打包部署从开发环境到线上开发完部署的常规流程# 前端构建 npm run build # 产物在 dist 目录 # 后端打包 mvn clean package -DskipTests # 产物是 target 目录下的 xxx.jar一般用 Nginx 托管前端 dist把 /api 路径代理到 SpringBootserver { listen 80; server_name your-domain.com; root /usr/share/nginx/html; index index.html; location /api/ { proxy_pass http://127.0.0.1:8081; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }后端进程用 systemd 托管或者 nohup 启动都行。我建议至少写一个启动脚本带上 JVM 内存参数避免默认堆内存过小导致接口频繁 GCnohup java -Xms512m -Xmx1024m -jar game-admin.jar app.log 21 如果涉及图片上传除了本地存储也可以接 MinIO 这类私有对象存储SpringBoot 集成不算复杂后续有需要可以单独展开。4. 常见问题与排查技巧实录4.1 数据库连接和 MyBatis 报错速查这套源码里出现频率最高的报错我整理成一张速查表现象原因解决方案连接 MySQL 报 SSL 错误MySQL 8 默认启用 SSL驱动协商失败连接串加 useSSLfalsePublic Key Retrieval 报错caching_sha2_password 认证需要公钥连接串加 allowPublicKeyRetrievaltrue中文乱码数据库表不是 utf8mb4建库指定 utf8mb4连接串加 characterEncodingutf8时间相差 8 小时连接串没指定时区明确 serverTimezoneAsia/ShanghaiMapper 接口和 XML 找不到关系路径写错或没配 mapper-locations检查 XML 路径和 namespace提示 Mapped Statements collection already contains value依赖混用或 SQL id 重复清理依赖保证 XML 的 id 唯一分页不生效startPage 和查询中间夹了其他 SQL确保 startPage 紧跟查询语句查询结果字段全为 null实体属性没走驼峰映射打开 map-underscore-to-camel-case关于 MyBatis 缓存的问题也顺便说一句。一级缓存默认开启作用域是 SqlSession范围很小二级缓存默认不开启一旦开启且使用不当容易出现脏数据。后台管理系统查询条件多、数据更新频繁我建议保持默认不要盲目开二级缓存。真要提速优先从 SQL 索引和分页方案下手缓存不是万能药。4.2 Vue 高频踩坑点前端踩过的坑主要集中在这几处。路由传参用 params 然后用户刷新页面参数丢了。后台筛选页强烈建议 query 传参。动态路由 addRoute 之后用户刷新页面路由又没了。需要在路由守卫里判断该路由是否已注册避免重复添加。Vue2 和 Vue3 的写法容易混用。如果用 Vue3组件库就配 Element Plus别把 Vue2 时代的习惯硬套进去。npm install 时依赖版本冲突最有效也最省事的办法是删掉 node_modules 和 package-lock.json 重装。手动改版本号去猜经常越改越乱。axios 拦截器里要约定接口返回结构。到底是直接返回 data 还是返回整个响应体团队内部必须先统一不然后端和前端互相看不懂。4.3 前后端联调阶段的排查路径前后端分开跑的时候排查路径一般是这样先在浏览器 Network 面板看请求有没有发出再看返回状态码。如果 404先看后端控制台的异常日志别一上来就怀疑前端。如果 403/401先查 Token 有没有正确塞进请求头。联调最容易浪费时间的地方其实是字段名。后端实体用驼峰 createTime前端也写 createTime本来没事但前端手误写成 create_time结果表格列全是 undefined。我建议联调前先跑一遍 Swagger 或者 mock 数据哪怕只有最简单的接口也能提前暴露一半字段问题。接口文档定字段、定状态码、定错误信息联调时才不会变成扯皮现场。如果接口返回跨域错误先分清是浏览器拦截还是后端没配置。浏览器报 CORS直接看响应头有没有 Access-Control-Allow-Origin没有就检查后端的 CorsConfig 和拦截器有没有把 OPTIONS 请求放行。4.4 写在项目交接后的几句经验最后分享几点源码里不会写、但实际项目里很值钱的经验。第一权限控制千万不要只做前端隐藏菜单。真正安全的接口后端每个接口都要做角色校验。前端隐藏菜单只是提升体验不是安全手段。有人直接拿 Postman 调 API 绕过前端这种情况下你前端做得再花哨也没用。第二游戏上下架这种状态变更最好用操作日志记录操作人、变更前后值、变更时间。复盘数据时这条日志比什么猜测都管用。我习惯在项目里加一张 operation_log 表很多管理系统源码没带这个功能如果你自己扩展价值立竿见影。第三接口返回给前端的业务码要统一。约定“0 成功非 0 失败”具体错误码再细分不要在有的接口返回 200、有的返回 true、有的又变成字符串 success。这套约定花半天定下来后面能省一个星期。再补一个小技巧每次改完数据库表结构顺手把 ALTER 语句和对应的初始化数据放到项目的 sql 目录下按版本号命名。别人拉最新代码按顺序执行脚本就能把库从旧版本平滑升到新版本。做过几套管理后台之后你就会明白这套源码真正值钱的不是那几行跑得通的代码而是这些能让人少熬夜的规矩。