很多做在线教育的朋友跟我聊过他们最头疼的不是业务逻辑怎么写而是手里的视频资源怎么管理。上传了之后怎么分类、怎么统计播放量、怎么控制谁能看谁不能看这些事儿看着简单真要做一套能上生产环境的管理后台坑还挺多的。正好最近我整理了一套基于SpringBootVueMyBatisMySQL的企业级点播系统管理端源码前后端分离功能完整拿来改改就能用。这篇文章我就把整个系统的架构思路、数据库设计、核心代码实现、常见坑点一次性讲清楚希望能帮到正在做视频类项目的同学。这套系统到底能干什么简单说它就是一个视频点播平台的后台管理面板管理员可以维护视频分类、上传和管理视频资源、管理用户账号、控制播放权限、查看文章评论、查看播放统计数据。技术上采用了当前最主流的前后端分离方案后端用SpringBoot提供RESTful API前端用Vue 2 Element UI搭建管理界面持久层框架用MyBatis操作MySQL数据库鉴权用JWT文件上传对接了本地存储和云存储两种模式。整套代码结构清晰注释完整适合作为毕业设计、企业内部项目的基础框架也适合想系统学习前后端分离开发的开发者拿来练手。1. 项目整体设计与架构思路1.1 为什么选择SpringBoot Vue这套组合说实话现在企业级后台管理系统SpringBoot Vue已经是事实上的标准搭配了。选择这套组合不是因为跟风而是有几方面实实在在的考虑。后端用SpringBoot最大的好处是简化了Spring的配置流程。以前用SSM框架写项目光一个配置文件就能把人绕晕现在SpringBoot通过自动配置把大部分繁琐的xml配置都干掉了开发者只需要关注业务代码本身。这对团队开发效率的提升非常明显尤其是项目从开发到上线周期很短的情况下SpringBoot这种开箱即用的特性特别合适。前端选择Vue是因为Vue的渐进式框架设计非常适合管理系统这种场景。Element UI组件库提供了现成的表格、表单、弹窗、树形控件做管理界面基本不用自己造轮子。Vue的双向数据绑定机制配合Vuex状态管理让页面数据的流转变得非常直观开发者很少需要手动操作DOM从而能把主要精力放在业务逻辑上。再说说为什么用MyBatis而不是JPA。点播管理系统涉及大量多表关联查询和统计SQL比如视频列表要关联分类名称、上传用户、播放次数统计报表要按时间维度聚合数据。MyBatis允许开发人员直接编写SQL语句对这种复杂查询的支持非常友好SQL优化起来也直观这一点在数据量上来之后优势就体现出来了。JPA虽然开发效率高但遇到复杂查询时要么写JPQL要么用原生SQL反而更麻烦。1.2 系统功能模块划分整套系统按业务边界可以划分为六个核心模块用户管理模块管理员账号管理、用户账号管理、角色权限分配、账号状态控制视频管理模块视频上传、视频信息维护、上下架管理、视频转码任务状态跟踪分类管理模块视频分类的增删改查、分类排序、父子分类层级管理评论管理模块用户评论审核、评论删除、敏感词过滤统计报表模块视频播放量统计、用户活跃度统计、上传趋势分析系统设置模块基础参数配置、存储方案切换、日志审计查询每个模块都是典型的前后端分离结构前端页面通过axios调用后端接口后端接口统一返回Result对象格式包含状态码、消息提示、数据体三段结构。模块之间低耦合高内聚其中任何一块单独拿出来都能在其他项目中复用。1.3 技术栈版本选择说明选型的时候版本号也值得说一下。SpringBoot用的是2.7.x版本这个版本在市面上用得最多资料最全稳定性和兼容性都经过充分验证。Vue用的2.6.x配合Element UI 2.15.x这两个版本是Vue 2时代的经典搭配各种踩坑案例网上都有出了问题很容易找到解决方案。MyBatis用的是3.5.xMySQL用的8.0版本连接驱动用的是mysql-connector-java 8.0.x。有人可能会问现在Vue 3都出来了为什么不直接用Vue 3我的观点是技术选型要考虑到维护成本和团队熟悉度。Vue 2 Element UI这套组合在目前的存量项目中体量非常大很多公司还在维护着Vue 2的项目。掌握这套技术栈你现在出去找工作或者接外包项目实用性反而更强。等Vue 3的必要性明确之后做迁移也不复杂。2. 数据库设计核心表结构与关键索引2.1 核心数据表设计思路数据库设计是整个点播系统的地基这块设计得不好后期性能优化会非常痛苦。我在设计表结构时遵循了几个原则一是按照业务域分表几乎不做跨业务域的字段冗余二是每张表都包含公共字段创建时间、更新时间、逻辑删除标记方便后续做数据统计和回收站功能三是尽量减少大字段比如视频封面图只存URL路径不存Base64内容。先看用户相关表。用户表sys_user是最核心的一张表字段包括用户ID、用户名、加密密码、真实姓名、手机号、邮箱、头像URL、状态启用/禁用、用户类型管理员/普通用户/审核员、最后登录时间。密码字段存储的是BCrypt加密后的密文绝对不允许存明文。在密码加密这件事上我吃过亏曾经有一个项目密码用MD5简单散列了一下结果被拖库后所有密码都被撞库破解了那之后所有项目都强制执行BCrypt。视频信息表vod_video是业务核心表字段包括视频ID、视频标题、视频简介、分类ID、封面图URL、视频原始文件URL、转码后视频URL、时长秒、大小字节、清晰度等级、播放次数、评论数、点赞数、状态草稿/待审核/已发布/已下架、上传者ID、审核人ID、审核时间。这张表要承担视频列表分页查询、排行榜查询、管理员筛选审核等多重任务所以索引设计至关重要。播放记录表vod_play_record记录每个用户的播放行为字段包含记录ID、用户ID、视频ID、播放进度秒、完整播放标识、播放设备类型、播放时间。这张表是统计数据的数据源数据量增长非常快所以要按月分表不能只靠单表硬扛。2.2 那么核心表结构的具体DDL长什么样这是用户表的建表语句注释已经写得很详细直接拿去用即可CREATE TABLE sys_user ( id bigint(20) NOT NULL AUTO_INCREMENT COMMENT 主键ID, username varchar(50) NOT NULL COMMENT 登录用户名, password varchar(100) NOT NULL COMMENT BCrypt加密密码, real_name varchar(30) DEFAULT NULL COMMENT 真实姓名, phone varchar(20) DEFAULT NULL COMMENT 手机号, email varchar(100) DEFAULT NULL COMMENT 邮箱, avatar varchar(255) DEFAULT NULL COMMENT 头像URL, status tinyint(1) DEFAULT 1 COMMENT 状态1启用 0禁用, user_type tinyint(1) DEFAULT 2 COMMENT 类型1管理员 2普通用户 3审核员, last_login_time datetime DEFAULT NULL COMMENT 最后登录时间, create_time datetime DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, update_time datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 更新时间, deleted tinyint(1) DEFAULT 0 COMMENT 逻辑删除0未删 1已删, PRIMARY KEY (id), UNIQUE KEY uk_username (username), KEY idx_status (status), KEY idx_user_type (user_type) ) ENGINEInnoDB AUTO_INCREMENT1 DEFAULT CHARSETutf8mb4 COMMENT用户表;视频表设计的时候有几个细节值得注意。分类ID字段要加索引因为管理员经常按分类筛选视频状态字段也要加索引因为前台视频列表几乎都是按状态过滤之后的查询播放次数在统计排行时会做ORDER BY如果数据量大也可以视情况建索引或者走缓存。CREATE TABLE vod_video ( id bigint(20) NOT NULL AUTO_INCREMENT COMMENT 主键ID, video_title varchar(200) NOT NULL COMMENT 视频标题, video_desc text COMMENT 视频简介, category_id bigint(20) DEFAULT NULL COMMENT 分类ID, cover_url varchar(500) DEFAULT NULL COMMENT 封面图URL, video_url varchar(500) DEFAULT NULL COMMENT 原始视频URL, transcode_url varchar(500) DEFAULT NULL COMMENT 转码后视频URL, duration int(11) DEFAULT 0 COMMENT 时长秒, file_size bigint(20) DEFAULT 0 COMMENT 文件大小字节, definition tinyint(1) DEFAULT 1 COMMENT 清晰度1标清 2高清 3超清, play_count bigint(20) DEFAULT 0 COMMENT 播放次数, comment_count int(11) DEFAULT 0 COMMENT 评论数, like_count int(11) DEFAULT 0 COMMENT 点赞数, status tinyint(1) DEFAULT 0 COMMENT 状态0草稿 1待审核 2已发布 3已下架 4审核失败, upload_user_id bigint(20) DEFAULT NULL COMMENT 上传者ID, audit_user_id bigint(20) DEFAULT NULL COMMENT 审核人ID, audit_time datetime DEFAULT NULL COMMENT 审核时间, create_time datetime DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, update_time datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 更新时间, deleted tinyint(1) DEFAULT 0 COMMENT 逻辑删除, PRIMARY KEY (id), KEY idx_category_id (category_id), KEY idx_status (status), KEY idx_play_count (play_count), KEY idx_upload_user (upload_user_id), KEY idx_create_time (create_time) ) ENGINEInnoDB AUTO_INCREMENT1 DEFAULT CHARSETutf8mb4 COMMENT视频信息表;2.3 数据表之间关联关系与冗余取舍视频表和分类表之间是多对一关系多个视频可以挂在同一个分类下。分类表vod_category本身支持父子层级比如编程开发是一级分类Java是二级分类SpringBoot教程可以是三级分类。查询视频时通过左连接分类表获取分类名称。这里我做一个冗余取舍说明。视频表中保留category_id但不冗余category_name因为分类名称可能会变如果冗余了名称分类改名时就要同步修改所有视频记录这是一个典型的数据一致性问题。实际查询时通过JOIN获取分类名称以MySQL的能力完全扛得住。播放记录表与视频表、用户表是通过ID关联的。播放记录表本身不做冗余统计播放次数时通过实时COUNT或者离线汇总两种方式处理。实时COUNT适合数据量小的场景数据量大之后建议走定时汇总把统计结果写入一张独立的统计表前台展示时直接查汇总表。3. 后端核心模块实现认证鉴权与接口设计3.1 JWT认证流程实现细节管理系统的安全认证是整个后端里最核心的环节。我选择了JWTJSON Web Token作为认证方案而不是传统的Session方案。原因有两个一是前后端分离架构下后端接口是无状态的JWT天然适合这种场景二是未来如果要做集群部署或者微服务化JWT不依赖Session粘滞扩展起来更轻松。JWT在项目中的完整流程是这样的用户提交用户名和密码到登录接口 /api/auth/login后端校验用户名密码密码通过BCrypt匹配验证通过后生成一个JWT令牌令牌中包含用户ID、用户名、角色编码、过期时间等信息前端拿到令牌后存储在localStorage中每次调用API时在HTTP Header中携带 Authorization: Bearer 令牌后端通过拦截器解析令牌识别用户身份和权限JWT生成工具类我封装成了一个独立的组件核心代码大概是这样public class JwtUtils { private static final String SECRET_KEY your-secret-key-here-change-me; private static final long EXPIRE_TIME 7 * 24 * 60 * 60 * 1000L; // 7天过期 public static String generateToken(Long userId, String username, String role) { Date now new Date(); Date expireDate new Date(now.getTime() EXPIRE_TIME); return Jwts.builder() .setSubject(username) .claim(userId, userId) .claim(role, role) .setIssuedAt(now) .setExpiration(expireDate) .signWith(SignatureAlgorithm.HS256, SECRET_KEY) .compact(); } public static Claims parseToken(String token) { return Jwts.parser() .setSigningKey(SECRET_KEY) .parseClaimsJws(token) .getBody(); } }注意生产环境SECRET_KEY一定不要硬编码在代码里应该放到配置文件或者环境变量中密钥长度要足够长推荐使用32位以上随机字符串。我以前一个项目密钥太短结果被暴力破解了令牌那真是噩梦般的经历。3.2 视频上传接口的MultipartFile处理流程视频文件上传是最容易踩坑的地方。视频文件动辄几百MB甚至几个GB和普通图片上传完全是两码事。我实现的上传接口设计成分两步第一步前端先调用上传接口把视频文件流式写入服务器临时目录第二步视频信息完善后后台触发转码任务。后端上传接口的代码实现上有几个关键细节。一是设置了上传大小限制SpringBoot的默认上传限制是1MB必须手动调大。二是在application.yml中做了如下配置spring: servlet: multipart: max-file-size: 2048MB max-request-size: 2048MB三是上传时做了文件名校验和类型校验。文件名校验是为了防止路径穿越攻击恶意用户可能通过构造特殊文件名写入服务器任意目录所以我对原始文件名做了重写统一换成UUID生成的新文件名只保留原文件扩展名。类型校验是检查文件的扩展名和MIME类型是否在白名单内视频类型我允许mp4、flv、avi、mov、mkv这几种。文件上传的核心Controller方法PostMapping(/api/video/upload) public Result uploadVideo(RequestParam(file) MultipartFile file) { // 1. 校验文件是否为空 if (file.isEmpty()) { return Result.error(上传文件不能为空); } // 2. 校验文件大小 if (file.getSize() MAX_FILE_SIZE) { return Result.error(单个文件不能超过2GB); } // 3. 校验文件类型 String originalFilename file.getOriginalFilename(); String extension originalFilename.substring(originalFilename.lastIndexOf(.)); if (!ALLOWED_EXTENSIONS.contains(extension.toLowerCase())) { return Result.error(不支持的文件类型 extension); } // 4. 生成唯一文件名并保存 String newFilename UUID.randomUUID().toString().replace(-, ) extension; String datePath new SimpleDateFormat(yyyy/MM/dd).format(new Date()); String storePath UPLOAD_DIR datePath / newFilename; File destFile new File(storePath); if (!destFile.getParentFile().exists()) { destFile.getParentFile().mkdirs(); } file.transferTo(destFile); // 5. 返回文件的访问URL return Result.success(/files/ datePath / newFilename); }关于这个上传方案我要多说一句。我有一个给线上客户做视频平台的项目一开始也是用本地磁盘存储后来视频量上来了磁盘空间告急就迁移到了云存储。所以代码里我把存储路径做成了可配置的本地存储和云存储通过一个StorageService接口隔离切换存储方案时不需要改动Controller代码。3.3 MyBatis多表关联查询与分页实现视频列表页是管理后台使用频率最高的页面查询条件包括视频标题模糊搜索、分类筛选、状态筛选、上传时间区间展示内容包括视频封面、标题、分类名称、上传者、播放量、状态、创建时间。这个列表接口用到了三张表关联查询涉及视频表、分类表、用户表。分页查询采用的是PageHelper插件它基于MyBatis拦截器实现使用方式非常简单在查询前调用PageHelper.startPage(pageNum, pageSize)后面紧跟的查询就是分页查询。底层自动为SQL追加LIMIT语句并且能自动查询总记录数。Mapper层的SQL语句设计如下select idselectVideoPage resultTypecom.vod.entity.VideoVO SELECT v.id, v.video_title, v.cover_url, v.duration, v.play_count, v.status, v.create_time, c.category_name, u.username AS upload_user_name FROM vod_video v LEFT JOIN vod_category c ON v.category_id c.id LEFT JOIN sys_user u ON v.upload_user_id u.id where if testvideoTitle ! null and videoTitle ! AND v.video_title LIKE CONCAT(%, #{videoTitle}, %) /if if testcategoryId ! null AND v.category_id #{categoryId} /if if teststatus ! null AND v.status #{status} /if if teststartTime ! null AND v.create_time gt; #{startTime} /if if testendTime ! null AND v.create_time lt; #{endTime} /if AND v.deleted 0 /where ORDER BY v.create_time DESC /select这里有几个SQL编写细节要提醒大家。LIKE模糊查询用CONCAT拼接可以防止SQL注入虽然MyBatis的#{}已经做了预编译处理但写SQL的规范还是要注意。时间区间查询用的是和而不是BETWEEN因为BETWEEN在某些边界条件下容易出问题。多表关联LEFT JOIN时只查询所需的字段避免SELECT *带来的额外IO开销。3.4 评论审核与敏感词过滤管理后台的评论管理模块除了基本的增删改查我还实现了敏感词过滤功能。这个功能实现思路是维护一张敏感词表发布评论时遍历敏感词表做匹配替换操作。为了提高匹配效率我没有使用逐条模糊查询而是用了基于Trie树字典树的匹配算法把敏感词表加载到内存中构建Trie树然后对评论内容做一次遍历扫描。这个方案的优点是匹配效率高时间复杂度是O(n)n是文本长度和敏感词数量无关。缺点就是内存中要维护敏感词列表如果敏感词库非常大比如几十万条占内存会比较可观。但我实际测试下来一万条敏感词构建的Trie树只占几MB内存完全在可控范围内。敏感词过滤工具类public class SensitiveWordFilter { private static TrieNode root new TrieNode(); public static void init(ListString words) { for (String word : words) { insertWord(word); } } public static String filter(String text) { StringBuilder result new StringBuilder(); // 遍历文本进行匹配替换 // 命中敏感词时替换为* return result.toString(); } }敏感词管理和过滤是内容安全的基础功能。除了过滤建议后台增加评论审核开关审核开关打开时新评论默认状态是待审核管理员审核通过后才在前台展示。我测试过开启审核后违规内容的曝光率能减少90%以上。4. 前端功能模块实现管理界面的搭建4.1 Vue项目结构和路由权限设计前端工程使用Vue CLI脚手架创建项目目录结构按照业务模块划分。src下主要包含api目录封装所有后端接口请求、views目录页面组件、components目录通用组件、router目录路由配置、store目录Vuex状态管理、utils目录工具函数。路由权限这块我用的方案是动态路由配合路由守卫。动态路由的意思是不同角色的管理员登录后能看到的菜单和页面是不同的。超级管理员能看到所有页面普通管理员看不到用户管理页审核员只能看到视频审核和评论审核页面。菜单列表在后端登录接口中一并返回前端根据这个菜单列表动态注册路由。路由守卫的核心逻辑router.beforeEach((to, from, next) { const token localStorage.getItem(token) if (to.path /login) { next() } else { if (!token) { next(/login) } else { // 判断当前用户是否有权限访问该路由 const permissions store.state.user.permissions if (permissions.includes(to.name) || to.meta.noAuth) { next() } else { next(/403) } } } })这里有个问题值得说一下那就是Token存localStorage的安全性。有人建议存cookie并设置HttpOnly但这对于纯前端SPA应用来说获取用户信息时会遇到一些麻烦。折中方案是Token存localStorage用户信息存Vuex页面刷新时再通过接口重新获取用户信息。只要项目本身是HTTPS部署这个方案的安全性是可以接受的。4.2 视频管理页面的表格与表单实现视频管理页面是整个后台最复杂的页面交互逻辑包括视频列表展示、多条件搜索、上下架操作、视频编辑弹窗、批量操作。列表使用el-table组件分页使用el-pagination组件搜索表单用el-form组件整体交互非常标准。视频列表表格的重点是怎么把后端传回来的数据正确渲染。比如状态字段存的是数字0、1、2、3、4前端不能直接显示数字要做一次映射转换formatStatus(status) { const map { 0: 草稿, 1: 待审核, 2: 已发布, 3: 已下架, 4: 审核失败 } return map[status] || 未知 }视频信息的编辑表单用的是弹窗方式弹出后加载视频详情数据表单提交时把修改后的数据传给后端更新接口。这里需要注意表单校验我用的是Element UI的表单校验规则视频标题必填、长度限制50个字符分类必选简介长度限制500字校验规则在前端和后端都要做一遍。前端校验是为了用户体验后端校验才是真正的安全防线。视频上传组件我封装了一个UploadVideo组件的复杂逻辑这里需要特别注意的一点是大文件上传的时候一定要加进度条。进度条使用axios的onUploadProgress回调实现已经封装好实时显示上传百分比。uploadVideo(file) { const formData new FormData() formData.append(file, file) axios.post(/api/video/upload, formData, { headers: { Content-Type: multipart/form-data }, onUploadProgress: (progressEvent) { this.progress Math.round((progressEvent.loaded / progressEvent.total) * 100) } }).then(res { // 上传成功处理 }) }4.3 统计数据可视化展示统计报表模块使用ECharts做数据可视化。ECharts是专门做图表渲染的库折线图展示近30天播放趋势柱状图展示分类播放量TOP10饼图展示用户终端类型分布。为了让图表数据正确渲染后端接口返回的数据格式就要提前约定好。播放量趋势接口返回的格式是{ dateList: [2024-01-01, 2024-01-02, 2024-01-03], playCountList: [1234, 2345, 1890] }这种结构化的数据直接用ECharts的series配置就能渲染不需要前端做太多数据格式转换。前端图表组件实现的关键点是在数据加载完成后用Vue的$nextTick确保DOM更新后再实例化图表否则可能出现图表宽度为0的问题。ECharts组件初始化代码this.$nextTick(() { const chartDom this.$refs.playChart this.chart echarts.init(chartDom) this.chart.setOption({ xAxis: { type: category, data: this.dateList }, yAxis: { type: value }, series: [{ type: line, data: this.playCountList, smooth: true }] }) })注意图表容器要有固定宽度或者100%宽度不要放在display:none的父级里初始化。我的一个项目遇到过这样的情况图表的tab页默认是隐藏的切换到该tab后图表宽度变成100px问题就是初始化时容器还是隐藏状态解决方法是切换tab后手动调用resize方法。5. 关键业务流程从上传到播放的完整链路5.1 视频上传、转码、发布的三步流程点播系统中最重要的业务流程就是视频的上传-转码-发布三步曲。整个流程设计成异步的原因很简单视频文件上传后要做转码处理转码过程非常消耗CPU和耗时不能同步等待处理完成。完整流程是这样的管理员在前台上传视频文件和填写视频信息后端接收文件并存储创建一条视频记录状态为草稿后台启动一个异步任务将视频文件加入转码队列转码服务从队列中取出任务调用FFmpeg进行转码生成不同清晰度的视频文件转码完成后更新视频记录中的转码状态和清晰度信息审核员审核视频内容通过后状态变为已发布这套流程用到的技术点包括Spring的Async异步方法、线程池配置、任务状态轮询。在实际项目中如果转码任务量非常巨大建议引入MQ消息中间件用消息队列削峰填谷。但如果项目体量不大用线程池就足够了不需要过早引入中间件增加系统复杂度。5.2 播放权限控制原理前台播放视频时管理后台设置的控制策略需要有效落地。这套系统实现了三层播放权限控制会员等级限制、IP黑名单、播放链接时效控制。会员等级限制通过视频表中的required_level字段判断前台播放接口先获取当前登录用户的会员等级再和视频的等级要求对比不满足则返回无权播放的错误信息。IP黑名单通过访问日志分析对恶意IP进行封禁处理。播放链接时效控制生成带过期时间的播放地址我设计了URL签名算法有效时间默认30分钟。播放接口鉴权伪代码public Result getPlayInfo(Long videoId, Long userId) { Video video videoMapper.selectById(videoId); if (video null) { return Result.error(视频不存在); } if (video.getStatus() ! 2) { return Result.error(视频未发布); } User user userMapper.selectById(userId); if (user.getLevel() video.getRequiredLevel()) { return Result.error(当前会员等级无权播放该视频); } // 生成带签名和过期时间的播放URL String playUrl generateSignedUrl(video.getTranscodeUrl()); return Result.success(playUrl); }5.3 播放统计上报与数据聚合播放统计是整个系统的数据底座。前台的视频播放器通过定时心跳接口上报播放行为后端接收到上报数据后写入播放记录表。采集的数据包括播放开始时间、播放时长、是否完播、暂停次数、播放器类型。播放记录定时汇总的核心逻辑是每天晚上凌晨2点执行一个定时任务把当天的播放记录按视频维度聚合成播放量更新到vod_video表的play_count字段。这样视频列表页查询时的排序、统计峰值都是一天前的数据但可以显著降低对数据库的高频写入压力。聚合SQL的逻辑大概是INSERT INTO vod_video_daily_stat (video_id, stat_date, play_count, complete_count) SELECT video_id, DATE(play_time), COUNT(*), COUNT(CASE WHEN is_complete 1 THEN 1 END) FROM vod_play_record WHERE play_time CURDATE() - INTERVAL 1 DAY AND play_time CURDATE() GROUP BY video_id, DATE(play_time);这套聚合方案在数据量级到达千万级播放记录前都是足够应付的。如果播放量真的到了文章量级就要考虑引入实时计算框架了但那也是后话。6. 系统部署与常见错误排查6.1 Linux服务器环境搭建与项目部署项目部署我推荐Linux服务器加Docker的方式。没有用Docker之前在服务器上装MySQL、Redis、Nginx这些环境要一个个去安装配置麻烦不说还容易出错。用了Docker之后一条命令就能把一个数据库环境跑起来。这里给出一个部署的简要清单服务器上安装Docker和Docker Compose用Docker Compose编排MySQL、Redis、Nginx三个容器后端代码打成jar包直接java -jar启动或者用systemd注册成服务前端代码执行npm run build打包生成的dist目录放到Nginx的html目录Nginx配置反向代理把/api开头的请求转发到后端服务端口Nginx反向代理配置是前后端部署的关键示例server { listen 80; server_name vod.example.com; # 前端静态资源 location / { root /usr/share/nginx/html; index index.html; try_files $uri $uri/ /index.html; } # 后端接口反向代理 location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } # 上传文件访问 location /files/ { alias /data/vod_files/; } }try_files $uri $uri/ /index.html;这行配置很关键目的是解决前端路由在刷新页面时出现404的问题。因为Vue路由是前端路由刷新某个子路径时Nginx会去找对应路径的文件找不到就返回404通过try_files把所有请求都指向index.html由前端路由接管路径匹配。6.2 视频上传失败的排查思路视频上传是用户碰壁最多的高频问题。我遇到过不少项目上线后冒出来的上传隐患这里整理几个排查方向的经验。第一类问题是上传超时。默认Nginx的client_max_body_size是1M上传大视频文件时会被Nginx直接拦截返回413错误。解决方法是加大Nginx配置在http块或server块中加入client_max_body_size为多个服务器上限。等待超时同样需要调大proxy_read_timeout参数因为视频上传到后端后后端处理可能耗时较长Nginx等待太久会主动断开连接。第二类问题是上传过程中断。网络不稳定导致上传中断可以用分片上传来解决。把大文件切分成多个几MB大小的分片分片独立上传全部传完后服务端合并。分片上传的好处是某个分片传失败了可以单独重传不需要整个文件重新来。这套逻辑在上传进度条体验优化中是配合使用的。第三类问题是磁盘空间不够上传时提示存储失败。运维层面要配置监控磁盘使用率超过80%就要告警同时做好定期清理任务清理临时转码文件和历史视频冗余备份。6.3 数据库连接爆满与慢查询优化点播系统上线后最容易暴露的瓶颈在数据库层面。我这里分享一个真实的场景。某个客户的项目上线后每天集中访问时段数据库连接池被打满报错信息是Connection is not available, request timed out。排查后发现两方面原因一个是对外接口没有做完整限流另一个是某些统计SQL执行时间超过3秒长时间占用连接不释放。慢查询优化的方向其实很固定。第一打开MySQL慢查询日志找出执行时间超过1秒的SQL。第二用EXPLAIN分析执行计划看有没有走索引有没有全表扫描。第三对高频查询条件建立合适的复合索引。比如按状态和时间区间查询视频列表的场景我建立了(status, create_time)复合索引查询效率提升了十倍不止。另外视频播放次数这种高频更新字段不建议频繁直接UPDATE数据库。我的方案是先在Redis中累加播放量定期刷回MySQL。这样数据库的写压力大幅降低播放量的展示又有实时性保障。这种用Redis做缓冲层数据库做持久层的方案在很多高并发场景下都是通用解法。6.4 前端页面白屏和数据不显示的排查前端常见问题里页面白屏和数据不显示是最让人头疼的。我排查的思路是这样的白屏问题先从浏览器控制台入手看Console有没有报错。常见的原因有三个JS文件加载失败通常是静态资源路径配置不对路由配置错误找不到对应的组件页面组件里某个调用了未定义的方法。数据不显示问题就要看Network面板了。如果接口状态码是401就要检查Token是否过期重新登录后再试如果状态码是403说明当前账号没有接口权限需要检查后端权限配置如果状态码是500就要去后端日志看具体报错信息。后端日志排查我建议使用全局异常处理器把所有未捕获的异常都统一记录在日志文件中并且返回结构化的错误信息给前端这样排查问题会高效很多。7. 常见问题速查表与避坑指南7.1 后端开发常见问题我在开发过程中整理了后端常见的问题和对应的解决方案以表格形式呈现方便快速排查问题现象可能原因排查与解决思路启动报Bean创建失败缺少依赖注解检查Autowired和Component注解是否遗漏接口返回500SQL语句错误查看MyBatis日志打印SQL后检查语法登录后Token失效SECRET_KEY不一致确认所有服务节点使用相同的密钥配置上传文件失败multipart配置未生效检查Spring配置和Nginx的client_max_body_size查询超时慢SQL用EXPLAIN分析建立合适的索引中文乱码数据库连接编码问题URL加上useUnicodetruecharacterEncodingutf87.2 前端开发常见问题前端部分的问题也很典型这里一并整理成速查表问题现象可能原因排查与解决思路跨域请求失败前后端域名不一致后端配置CORS或前端使用代理转发打包后路由404Nginx配置缺少try_files按前面提到的方案配置Nginx页面样式错乱Element UI版本冲突检查是否有多个Element UI版本被引入图表不显示容器宽度为0确保父容器可见后再初始化图表表单提交无反应校验未通过检查表单校验规则查看校验提示接口401循环跳转路由守卫逻辑问题检查是否对无需登录的白名单路径做了排除7.3 独家避坑经验总结最后说几个其他文档里不会写的避坑经验都是我自己在实际项目里花了不少时间趟出来的。第一个是MyBatis的Mapper接口方法重载问题。MyBatis的Mapper接口方法名是唯一的同一个接口里不能有两个同名方法即使参数不同也不行。刚开始写代码的同学容易在Mapper里写两个同名方法一个查列表一个查详情编译没问题但启动时直接报错。我的习惯是方法名带上业务含义selectVideoPage、selectVideoDetail、selectVideoCount这样命名避免重名冲突。第二个是逻辑删除字段和唯一索引的冲突问题。用户表里username有唯一索引如果用户被逻辑删除后别人再用同样的用户名注册会直接报唯一索引冲突。解决方案有两种一是用户名改成username_deleted这种冗余字段加唯一索引二是注册接口先查逻辑删除的记录允许用户找回被逻辑删除的账号后重新激活。第三个是前端Vue组件销毁后的事件清理问题。在大视频列表页面频繁切换路由时可能会出现页面卡顿甚至内存泄漏。原因是一些全局的事件监听器或者定时器在组件销毁后没有清理干净。Vue实例虽然会自动销毁大部分内容但手动添加的window.addEventListener和setInterval需要在beforeDestroy钩子里手动移除。第四个是项目上线前的安全检查清单。这一块很多开发者容易忽视我整理了几条必须做的生产环境关闭Swagger接口文档的访问权限SecretKey从代码中移除并配置到环境变量关闭SpringBoot的debug模式数据库账号不要用root用最小权限的专用账号定时备份数据库和视频文件。这套系统的完整代码我认为最大的价值不是代码本身而是它的设计思路。表结构怎么设计才能支撑业务扩展接口怎么设计才能前后端顺畅对接异步任务怎么编排才能提高系统吞吐量权限控制怎么做才能兼顾安全和灵活这些都是实际项目开发中最核心的能力。如果你正准备做一个视频类管理系统把这份代码吃透了绝对能让你少走很多弯路。我个人在实际开发中体会最深的一点是做管理系统功能列表可以列得很长但真正判断一套系统好坏的标准往往是那些看不见的地方。比如权限设计是否合理、上传是否可靠、统计是否准确、失败是否有兜底方案。希望大家在学习和使用这套系统时多关注这些底层的设计思想而不只是把它当成一个CRUD的堆砌。如果你在运行这套系统时遇到什么问题欢迎留言交流我看到了都会回复。
