SpringBoot+Vue+MyBatis+MySQL：Web及游戏管理后台搭建实战指南

做管理后台这件事，说难不难，说简单也真不简单。尤其像标题里这种“Web及游戏管理平台管理系统”，一听就知道既要管用户、管内容，又要管游戏服务器的运营状态和玩家数据，涉及的模块相当杂。我前后接过好几个类似的项目，技术栈正好都是SpringBoot+Vue+MyBatis+MySQL这套组合，实际踩坑下来积累了不少经验，这篇文章就把整个搭建过程掰开揉碎讲一遍，从项目拆解、后端落地、前端配合到部署上线，完整走一遍，顺便把那些文档里不写的坑也一并说出来。

先说一句：这套技术栈放到2025年依然是中小型管理系统最稳的组合，没有之一。SpringBoot负责接口和业务，MyBatis控制SQL粒度，MySQL存储核心数据，Vue（尤其Vue3）负责页面交互，四者配合非常成熟，招聘市场上能接手的人也最多，后续维护不用发愁。

1. 这个管理系统到底要管什么：先做需求边界划分

很多人在拿到这类项目的时候第一反应就是拉个工程开始写代码。这是最容易翻车的做法。管理系统的难点从来不是某个技术点，而是“需求到底有多大”。所以动手之前，先把业务模块和边界理清楚是最重要的一步。

1.1 通用管理后台的五个基础模块

不管你的管理平台是管电商、管内容、还是管游戏，业务上总有那么几个绕不开的通用模块。我通常把它们归为管理系统的基础底座，优先搭建：

• 用户管理：账号的增删改查、状态禁用/启用、角色分配。注意这里说的是“后台账号”，比如运营人员、客服、管理员，不是游戏玩家的账号。
• 角色与权限管理：RBAC模型（角色-权限关联），这是后台系统权限控制的核心，后面专门讲。
• 菜单管理：动态生成前端路由的菜单树，通常也是后端返回接口数据，而不是前端写死。
• 操作日志：谁在什么时间干了什么事，这笔账必须记清楚。
• 数据字典：很多字段的值是有限的（比如状态为启用/禁用、类型为PC/移动端），把这些枚举值统一存到字典表里，避免代码里到处写魔法数字。

1.2 游戏管理模块的特殊之处

游戏管理平台的业务模块跟普通管理系统有明显区别。它有很强的实时性、多源数据上报、以及内网部署要求。大致会涉及下面几个子功能：

• 游戏服管理：每个游戏服务器（区服）的状态监控，在线上人数、在线状态、更新状态。这一块通常需要定时拉取或者由游戏服上报心跳。
• 玩家数据管理：查询玩家的等级、充值、登录记录、封禁状态。查询条件多，需要做组合查询和导出。
• 运营活动配置：配置游戏内的运营活动，比如充值返利、限时礼包。配置之后要同步给游戏服。
• 游戏拉取的服务端接口：后端需要对接游戏服暴露的HTTP接口（或者RPC），从游戏服拉取玩家数据、更新封禁状态。

这点也要提前想清楚，你的管理后台是一个“解析监控中枢”还是一个“主动指令下发系统”。前者简单，后者要考虑接口的幂等性、超时重试、并发控制，复杂度完全不同。

2. 后端骨架搭建：SpringBoot+MyBatis+MySQL的落地细节

后端是整个管理系统的发动机。骨架搭得好不好，直接决定后面开发速度。这里我按我的习惯分享一套可复用的搭建过程，顺带解释几个容易踩坑的环节。

2.1 项目结构和依赖配置

现在创建SpringBoot项目，强烈建议直接上Java 17以上版本配合Spring Boot 3.x。如果你还在用Spring Boot 2.x，新项目里就不推荐了，毕竟是2025年了，Spring Boot 2的维护期已经过去，依赖生态也慢慢不更新了。

这里给出一个最基础且好用的pom.xml依赖清单，我实测过Spring Boot 3.2.x版本，稳定靠谱：

<parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>3.2.5</version> <relativePath/> </parent> <dependencies> <!-- Web 模块 --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <!-- MyBatis Starter --> <dependency> <groupId>org.mybatis.spring.boot</groupId> <artifactId>mybatis-spring-boot-starter</artifactId> <version>3.0.3</version> </dependency> <!-- MySQL 驱动 --> <dependency> <groupId>com.mysql</groupId> <artifactId>mysql-connector-j</artifactId> <scope>runtime</scope> </dependency> <!-- 参数校验 --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-validation</artifactId> </dependency> <!-- Lombok --> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency> </dependencies>

这里有个版本适配的注意点：MyBatis Starter的版本跟Spring Boot主版本不一定同步。比如Spring Boot 3.x对应的是mybatis-spring-boot-starter的3.x版本，你如果用2.x的MyBatis Starter去配Spring Boot 3.x，启动会直接报ClassNotFoundException。这就是很多新手“springboot版本太高”问题的主要来源。

2.2 数据库设计与MyBatis映射的实战要点

数据库设计方面，管理系统的核心表并没有那么玄学，但有几个设计习惯要养成：

• 每张表都带上id、create_time、update_time，前两个必加，更新字段视情况。管理后台查询列表经常需要按时间排序，没有时间字段会很被动。
• 状态字段用tinyint，注释里写清楚每个值代表什么。别用varchar存状态，后面写SQL判断会很痛苦。
• 逻辑删除字段deleted，管理后台的删除操作通常是假删除，数据审计要用，别物理删。
• 金额字段用decimal(10,2)，整数用bigint，int对于玩家ID、渠道号这类字段未来可能溢出。

MyBatis的使用上有几个关键配置，值得多说几句。

第一个是驼峰映射。数据库下划线字段名自动映射到Java驼峰属性。在application.yml里配置：

mybatis: configuration: map-underscore-to-camel-case: true mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.admin.entity

这个配置一旦开了，你写select的resultType时几乎不用写resultMap，非常省事。很多老项目里还在手写几百行的resultMap，看着都累。

第二个是分页插件。我推荐用PageHelper，虽然有人说它维护状态一般，但简单好用，配合Spring Boot 3.x选pagehelper-spring-boot-starter的1.4.7以上版本即可。用法很直观：

PageHelper.startPage(pageNum, pageSize); List<UserVO> list = userMapper.selectUserList(query); PageInfo<UserVO> pageInfo = new PageInfo<>(list);

这里有个隐患：PageHelper.startPage必须紧跟在你要分页的那条Mapper查询调用之前，中间不能再插入其他SQL操作，否则分页会作用到错误的查询上。这是PageHelper最典型的误用场景。

第三个是TypeHandler。MySQL里有些字段类型跟Java对象对不上，比如存储JSON字符串的字段，或者枚举类型。MyBatis的TypeHandler就是干这个的，实现一个BaseTypeHandler，重写setNonNullParameter和getNullableResult方法，把数据库值和Java对象互相转换。比如把JSON字符串转成List ，实测在游戏配置模块里会频繁用到。

2.3 事务与多表联查，怎么设计才不会乱

管理后台的后端逻辑大部分是单表CRUD，但一旦涉及“修改用户角色”“上下架菜单”这类多表联动操作，事务就变得非常关键。

事务的落地，最直接的还是用@Transactional注解，加在Service层的方法上。但注意三个坑：

• 同类内部方法调用，@Transactional会失效。因为Spring事务是通过代理类实现的，内部this.method()调用不会经过代理。解决办法是把需要事务的方法拆到另一个Bean里，或者自己注入自己的代理。
• 事务里不要做RPC调用或长时间的外部请求，比如往游戏服下发指令。一旦外部服务无响应，数据库连接会被长时间占用，连接池很容易被打满。
• 只读查询可以加@Transactional(readOnly = true)，只做优化标记，不会有副作用，但也没有必要每个查询都加。

多表联查这块，我的建议是：复杂统计查询走XML自定义SQL，简单关联用注解或单表多次查询。不要什么都嵌套在Mapper XML里。MyBatis的<foreach>、<where>、<choose>这些动态SQL标签非常强，但写多了以后可读性确实差，维护成本高。折中的做法是：

• 列表分页查询用XML动态SQL，因为条件多，必须动态拼。
• 单条详情、下拉选项这类接口，用几条简单查询组合完成，不要强行连表。
• 报表统计类查询，要么写标准SQL，要么直接交给MySQL的视图或者临时表，不要在Java层做内存聚合，量大必卡。

另外关于MyBatis缓存，管理后台项目我基本都是全部关闭，只保留一级缓存（SqlSession级别），二级缓存不要开。原因很简单：后台数据频繁修改，缓存刷新逻辑一旦疏忽就会出现权限改了用户还在用旧角色的问题。缓存带来的性能提升在这个场景下不值当，真的。

3. 权限认证与管理后台安全的命门所在

管理系统跟C端网站最大的不同，就是它对权限的敏感度极高。一个普通运营误点了删除按钮，如果没有权限控制，后果很严重。所以权限设计是管理平台的重中之重。

3.1 Token认证方案：JWT还是Session

2025年的管理系统，前后端分离架构下基本都用Token认证，主流方案是JWT。我不建议用Session管理后台登录态，原因很简单：

• 前后端分离后前端可能部署在不同域名，Session处理跨域、跨站点时很别扭。
• Session需要服务端存储，多实例部署要引入Redis做Session共享，复杂度高于JWT的无状态特性。
• JWT天然携带用户基本信息，后端解析后即可拿到用户ID和角色，减少查库次数。

SpringBoot 3.x下推荐用Spring Security结合JWT，配置比较繁琐，但有完整的Filter链路可以控制。如果你不想引入那么重的Security，也可以用一个自定义拦截器（HandlerInterceptor）配合JWT工具包，管理后台这种场景完全够用。

@Component public class AuthInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 放行登录等白名单接口 String uri = request.getRequestURI(); if (uri.startsWith("/api/auth/")) { return true; } String token = request.getHeader("Authorization"); if (StringUtils.hasText(token) && token.startsWith("Bearer ")) { token = token.substring(7); } else { throw new BusinessException(401, "未登录或登录已过期"); } // 解析JWT Claims claims = JwtUtil.parseToken(token); Long userId = Long.valueOf(claims.get("userId").toString()); // 用户信息放入ThreadLocal或Request attribute request.setAttribute("userId", userId); return true; } }

这里要说明，自定义拦截器做登录态校验没问题，但细粒度的权限校验我建议放到注解+AOP层面，比如自定义@RequirePermission("system:user:delete")，AOP切面里校验当前用户是否拥有该权限码。这种方式的代码侵入性最小，新加一个接口，只需要在方法上标注权限码，非常直观。

3.2 后端权限校验的流程设计

一个标准的管理后台权限校验流程，应该做到下面这份清单的每一项：

• 用户请求先经过登录态拦截器，确认Token有效并且没过期。
• 根据用户ID获取其角色（一个用户可有多个角色），角色关联权限码集合。
• 当前请求的URI或注解权限码，与用户的权限码集合做比对。
• 命中则放行，没命中则返回403。

这套逻辑要在后端做，前端只负责“隐藏不该看到的按钮”，真正安全防线还是后端。我在很多项目里见过前端把按钮隐藏了，但后端接口完全没有鉴权的情况。这种代码上线后很容易出内部数据泄露事故，注意避坑。

对于角色的权限数据，直接查数据库即可。管理后台的用户量级别通常不超过几千人，不要过早引入Redis缓存权限，除非你的系统定位是大型平台。简单直接地每次请求查一次权限，配合数据库索引，性能完全够。真要优化，等有瓶颈再上缓存，这也符合过度设计能不做就不做的原则。

3.3 操作日志怎么记录才有价值

操作日志不是简单的“用户A点击了按钮B”，而是要记录：谁、在什么时间、从哪个IP、调用了哪个接口、传入参数是什么、结果如何。这样才能在出问题时反查操作链路。

我推荐用AOP记录操作日志，而不是在业务代码里手动写log。设计一个@OperationLog(value = "删除用户")注解，AOP切面上统一记录：

@Aspect @Component public class OperationLogAspect { @Around("@annotation(operationLog)") public Object around(ProceedingJoinPoint pjp, OperationLog operationLog) throws Throwable { // 记录开始时间、请求参数 long start = System.currentTimeMillis(); try { Object result = pjp.proceed(); // 记录成功日志：操作人、操作内容、耗时 return result; } catch (Exception e) { // 记录失败日志 + 异常信息 throw e; } } }

注意一点：日志记录本身不能影响主流程，最好把日志保存逻辑放在异步线程池里，或者用@Async注解，避免日志存储拖慢接口响应。但是事务范围内的日志和业务操作要区分开，否则业务回滚时日志也丢了，这种过度耦合也会造成问题。

4. 前端Vue实战：管理后台页面架构与路由设计

前端选型上，2025年主流就是Vue 3配合Vite、Element Plus、Pinia。Vue 2已经到了维护尾声，新项目就别再用了。

4.1 Vue3项目搭建与动态路由

用Vite创建项目非常快：

npm create vite@latest admin-web -- --template vue cd admin-web npm install npm install vue-router pinia element-plus axios sass

这里我特别想说说动态路由。管理后台的菜单往往是根据当前登录用户权限动态生成的。如果你的菜单是写死在前端路由表里的，那新增菜单就要改前端代码重新打包，这在运营后台里是不可接受的。正确的做法是：

• 登录成功后，后端返回当前用户的菜单列表（树形结构）。
• 前端根据菜单数据动态注册路由，而不是启动时一次性注册全部路由。
• 每个路由的component字段通过import.meta.glob动态加载对应组件。

// 后端返回菜单示例 const menuData = [ { path: '/system/user', name: '用户管理', component: 'system/user/index', icon: 'User' }, { path: '/game/server', name: '游戏服管理', component: 'game/server/index', icon: 'Monitor' } ]; // 动态导入组件 const modules = import.meta.glob('../views/**/*.vue'); function buildRoutes(menus) { return menus.map(menu => { const component = modules[`../views/${menu.component}.vue`]; return { path: menu.path, name: menu.name, component: component }; }); }

这个import.meta.glob写法在Vite里非常常用，注意路径拼接方式，坑点在于组件的路径必须能对应上实际文件路径，否则编译不会报错但运行时白屏。这个我踩过，后来用了一段脚本在构建前检查菜单配置的组件路径是否都能匹配到文件。

4.2 Axios封装与接口联调的坑

Axios在管理后台里基本都会统一封装，主要为了两件事：统一处理Token、统一处理错误码。

import axios from 'axios'; const request = axios.create({ baseURL: '/api', timeout: 15000 }); // 请求拦截器：附加Token request.interceptors.request.use(config => { const token = localStorage.getItem('admin_token'); if (token) { config.headers.Authorization = `Bearer ${token}`; } return config; }); // 响应拦截器：统一处理业务错误 request.interceptors.response.use( response => { const res = response.data; if (res.code !== 200) { // 统一错误提示 if (res.code === 401) { // 跳转登录页 router.push('/login'); } return Promise.reject(new Error(res.message)); } return res.data; }, error => { // 网络错误、超时处理 return Promise.reject(error); } );

除了这些常规逻辑，我还有几个实际项目里总结的注意点：

• 请求超时时间不宜太长，管理后台默认10~15秒足够。游戏服接口的同步调用另说，可能需要在网关层单独配置更长的超时。
• 下载文件时，不要用JSON的响应拦截，要单独用原生axios的responseType: 'blob'，否则下载下来的Excel文件会损坏。这个坑非常经典，几乎每个项目都会有人中招。
• 导出大列表建议时间不能太长，比如导出全部玩家数据，这类耗时操作可以做成异步任务，前端轮询导出进度，做好了再下载。不要拿浏览器同步请求去等一两分钟。

4.3 表格、表单和弹窗页面怎么组织最舒服

管理后台的页面组成，说来说去就是表格+搜索表单+新增/编辑弹窗+删除确认这一套。Element Plus里有一套完整组件，但用起来有些规划上的建议：

• 搜索表单复用：不要每个页面上都写一套表单的HTML，最好封装成通用组件，比如SearchForm，通过配置项生成搜索框，配置项里包括字段名、类型（输入框/下拉/日期范围）、默认值。这样后续新增页面时，只需要维护配置对象。
• 弹窗模式：新增和编辑弹窗建议用同一个组件，传入一个formData对象，空对象就是新增，有值就是编辑。提交时判断是否有id字段，有就调更新接口，没有就调新增接口。
• 删除操作必须二次确认，并且提示不可恢复。尤其游戏管理里删除一个玩家角色，可能直接导致该玩家数据回档，所以删除前一定要写清楚影响范围。
• 表格列宽、排序状态、搜索条件要尽量保留在URL参数上，刷新页面后还能恢复。这块在复杂管理后台里体验提升很明显，但需要额外的一些代码处理，可做成通用工具。

4.4 Vue打包后塞进SpringBoot的操作

本地开发时前端通过Vite代理转发后端请求，上线时可以有两种部署方式：一是前端独立部署到Nginx，二是把前端打包产物直接放进SpringBoot的static目录。后者在一些私有化部署的游戏管理平台里特别常见，因为客户往往只给你一台服务器，不想再装Nginx。

打包时把Vite的代理关掉，直接用相对路径或同源部署：

// vite.config.js 中配置 build: { // 使用相对路径，避免子目录部署时资源404 assetsDir: 'static' }

然后执行npm run build，把dist目录下的文件复制到SpringBoot的src/main/resources/static目录下。接着要配置一个特殊路由，让所有非/api的请求都转发到index.html，交给前端路由处理。SpringBoot 3.x下可以自己写一个Controller或实现WebMvcConfigurer的addViewControllers方法：

@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addViewControllers(ViewControllerRegistry registry) { // 前端路由的兜底，避免刷新页面404 registry.addViewController("/{path:^(?!api|static).*$}") .setViewName("forward:/index.html"); } }

这里也有注意点：如果后端接口没有统一加/api前缀，这个兜底正则写起来会很痛苦。所以我后面的项目都会要求接口统一以/api开头，前端代理和部署兜底都简单。这不是什么高深技巧，但绝对是让整个项目少掉很多奇怪的404问题的关键。

5. 游戏管理模块：从监控到运营指令的完整闭环

回到这个系统的另一个重头——游戏管理平台模块。这一块是把“通用管理系统”变成“游戏管理系统”的核心差异所在。

5.1 游戏服的心跳上报与状态监控

游戏服务器通常跟Web后台不在同一个内网或部署环境。管理后台需要实时看到游戏服状态，最简单也最稳妥的机制是心跳上报：

• 每个游戏服启动时向管理后台注册一个实例信息（区服ID、区服名、版本号、IP端口）。
• 游戏服定时（比如每30秒）向管理后台上报一次心跳，上报在线人数、内存、CPU等基础状态。
• 管理后台维护一个心跳表，每次收到心跳就更新对应区服的last_heartbeat_time。
• 后台展示时，判断last_heartbeat_time是否在最近60秒内，如果超过则标记“离线”，否则“在线”。

这套机制比管理后台主动发心跳请求要合理，因为游戏服数量多、内网防火墙策略复杂，被动上报比主动拉取更容易打通网络。

实现时后端代码逻辑很简单：

@PostMapping("/api/game/heartbeat") public Result<Void> receiveHeartbeat(@RequestBody ServerHeartbeatDTO dto) { // 更新区服状态 gameServerService.updateHeartbeat(dto.getServerId(), dto.getOnlineCount()); return Result.success(); }

要额外注意的点是上报接口要加一个简单的Token校验，防止随便谁都能打这个接口伪造在线数据或刷脏数据。同时心跳表不需要保留太多历史明细，定时任务定期清理即可，否则几个月下来这张表会膨胀到可怕。

5.2 玩家数据查询与运营工具的设计

游戏管理后台查玩家数据，查询条件跟普通用户完全不同，通常有：

• 玩家ID（唯一标识）
• 角色名（模糊查询）
• 区服ID（精确查询）
• 注册时间范围
• 充值区间
• 最近登录时间范围

这些条件在Mapper XML里做成动态SQL非常多，但要注意一个细节：游戏玩家的数据量通常远大于后台管理账号数据量，可能达到百万甚至千万级。所以玩家表的查询一定要用索引覆盖，不能全表扫描。

一个优化建议是给玩家表建一个组合索引：

ALTER TABLE game_player ADD INDEX idx_server_register (server_id, register_time, player_name);

这种索引顺序的设计有讲究：区服是等值查询，放最前面；注册时间是范围查询，放中间；角色名是模糊查询，放在最后辅助排序。当然实际业务字段不同，索引设计需要你自己重新评估一遍。不要照抄，但要理解这个思想。

如果列表查询仍然很慢，还可以引入ES做玩家搜索，管理后台的玩家模糊搜索、多条件组合搜索是ES的典型场景。但这是后话，一般中小型游戏管理平台MySQL先顶住，等数据量真的上来了再演进，千万别上来就ES，运维成本不小。

5.3 运营活动配置与同步下发

运营活动的配置和管理，本质是一个“配置中心”的功能。运营在后台创建活动，设置时间、奖品、条件，然后通过后台发布，把配置同步给游戏服。这里有两个核心问题：

第一，配置的版本管理。活动配置不像普通文章，它是被游戏服实时读取的。如果运营改了一半配置就发布了，游戏服读到的可能是半个残缺配置。所以设计上要区分“编辑态”和“发布态”。编辑态是草稿，发布时才生成一条新版本记录，游戏服只会拉取最新发布版本。

第二，下发的幂等性。后端向游戏服同步配置可能失败，失败后要重试。重试时不能让游戏服重复计发一个礼包。所以每次同步请求要带上配置版本号，游戏服根据版本号判断是否已应用过。类似的消息可靠投递语义，在管理系统对接游戏服的场景里非常常见。

第三，发布前的校验。运营活动配置里时间格式、奖励物品ID是否存在、数值范围，最好在后端保存时做一次校验。不要等到游戏服应用时才发现配置报错，到时候玩家可能都已经在活动里领了一轮异常产出了。这类事故处理起来不仅技术麻烦，客服和舆情压力更大。

6. 部署与调试阶段最容易踩的坑，以及我推荐的排查路线

项目写到能跑通接口、页面能调通数据，只是开始。真正让人心累的往往是部署阶段和上线后的诡异问题。这一章把我这些年积累的部署和问题排查经验集中写出来，按重要性排序。

6.1 打包和部署的环境差异

本地开发好好的，放到服务器上起不来的问题，占了部署阶段问题的一半以上。最常见的几个原因如下，我直接列成一份排查清单：

MySQL时区这个问题我要多说一句，它几乎在每个新项目里都会出现。mysql-connector-j8.x以上版本对timezone很敏感，如果连接串不指定serverTimezone，高版本会直接启动报错。指定了但写错了（比如写成UTC），存进去的时间比北京时间少8小时。解决方案很简单：

spring: datasource: url: jdbc:mysql://127.0.0.1:3306/admin_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai

顺便一提，MySQL驱动从8.0开始，连接串里的com.mysql.jdbc.Driver要改成com.mysql.cj.jdbc.Driver，老代码里如果还在用旧驱动类，直接连不上。

6.2 慢查询与数据库连接池问题

管理系统上线后最常遇到的性能瓶颈往往是数据库。不是说你服务器性能差，更多是因为SQL写得糙或者连接池设置不合理。

连接池我推荐用HikariCP，Spring Boot 2.x以上自带的连接池默认就是它，性能足够优秀。配置上至少要关注三个参数：

spring: datasource: hikari: maximum-pool-size: 20 minimum-idle: 5 connection-timeout: 30000

maximum-pool-size并不是越大越好。数据库的压力不随连接数线性增长，每个连接背后都有一个进程或线程在消耗资源。我以前做过一个项目，把连接池调到100，结果数据库CPU直接飙到90%以上，反而把连接池调回30以后整个系统稳定了。一概而论，但对于MySQL部署在普通云服务器上的情况，默认值20到50之间是比较安全的区间。

慢SQL排查，最好的方法是打开MySQL的慢日志：

SET GLOBAL slow_query_log = ON; SET GLOBAL long_query_time = 2;

跑一段业务后，去查慢日志里记录的高耗时SQL，针对性地看执行计划EXPLAIN，检查是否命中索引。管理系统列表页变慢，90%的原因就是列表查询里某个字段没走索引，或者因为前端的or条件导致索引失效。遇到or条件尽量改写成两个查询用union all合并，这招能解决很多慢查询问题。

6.3 上线前的安全自检清单

管理平台是内网系统，但内网不等于绝对安全。尤其游戏管理平台，账号权限一旦泄露，影响的可能就是所有区服玩家数据。我每次上线前都会按下面这份清单过一遍：

• 默认密码强制修改，管理员账号开启二次验证。管理系统里像admin/admin123这种初始密码在2025年绝不能出现，这是最低底线。
• Swagger或者Knife4j接口文档，生产环境必须关闭或者加权限保护。接口文档会把所有接口细节暴露出来，配合弱口令就是灾难现场。
• 接口参数校验不能只靠前端，后端必须加@Validated校验，尤其是分页参数、ID参数这类容易被恶意构造的地方。
• 文件上传接口要校验文件后缀和文件头，不要只信文件名。管理后台的头像上传、活动图片上传都会是攻击面。
• 敏感操作（封禁玩家、删除数据）都要求二次确认，前端弹窗确认只是一层，后端最好对高危接口再加一个确认参数confirm_reason，强制运营填写原因。

安全这块没有上限，但这份清单的每一项都不复杂。我见过太多公司把精力放在C端App的代码防护上，结果后台系统搞得像筛子一样，最后数据全是从后台泄露的。作为开发者，我们写管理后台时就要有这个意识，这是职业底线，不是可有可无的加分项。

7. 这套项目做完以后，我个人最大的三个体会

项目做到收尾阶段，回过头来看这套SpringBoot+Vue+MyBatis+MySQL的管理系统，有几个心得，可能比具体的技术细节更有价值。

第一个体会是：管理系统的核心价值在业务抽象，不在新技术。用当下最流行的微服务架构把一个后台系统拆成十个服务，运营配个活动还要跨三个系统审批，这种架构是给自己找麻烦。中小型管理平台，单体应用+清晰的分层模块，就已经是极佳方案。技术栈的新旧不妨碍系统好用，关键是模块边界和数据结构是否经得起业务演进。

第二个体会是：权限和日志永远值得多花时间。很多项目后期维护最大的痛点不是性能，而是“出事了不知道是谁干的”。权限边界模糊和日志缺失，会让每一次线上事故的排查都变成猜谜。前期把RBAC、操作日志、登录日志老老实实做透，后面省下的心力是十倍不止。

第三个体会是：部署一键化要提早做。哪怕项目只有一台服务器，也建议用一个脚本把打包、上传、重启、日志查看串起来。不要手动在服务器上敲java -jar。2025年更推荐做一套简单的Docker容器化部署，至少不用再纠结Java版本、字体库、时区这些环境差异。我在好几个项目里因为环境不一致白白浪费了整整一天，后来全换成Docker以后这类问题基本绝迹。

最后分享一个小技巧：开发管理后台时，数据库建表脚本、初始化菜单数据、种子账号一定要做成可重复执行的SQL脚本，放在项目里持续维护。新同学拉下代码，执行一条命令就能把库建好，把后台跑起来。这看起来是件小事，但能让团队的协作体验提升一个档次，非常值得。