做微视频管理系统这个事说难不难说简单也不简单。市面上刷到的短视频App看着界面轻巧真正到自己要搭一套能跑起来、能管理、能审核、能推送的管理系统时一堆问题就冒出来了——视频怎么传、怎么存、转码要不要做、播放怎么调度、后台怎么审核、用户权限怎么分。这套基于Spring Boot和Vue的云平台微视频管理系统基本就是围绕这些真实需求展开的后端负责处理业务逻辑和数据存储前端负责展示和交互云平台负责解决视频文件的存储、访问和部署问题。我这次把这套系统的完整实现思路、核心代码逻辑、部署方式和踩坑经历整理出来适合正在做短视频类项目的同学也适合想系统了解前后端分离项目如何落地的开发者参考。我的建议是先搞清楚一个前提这不仅仅是一个增删改查的管理后台。微视频系统真正麻烦的地方在文件处理、权限控制、访问性能和部署运维这几个方向数据库表和CRUD反而是最简单的部分。接下来我从项目设计开始讲一直讲到上线部署和实际排查尽量把每一步的逻辑链条讲清楚。1. 先想清楚再动手这套系统的功能边界与设计思路1.1 微视频管理到底在管什么微视频管理系统核心管理的对象不只是视频文件本身而是围绕视频形成的一整套数据链。视频文件本身、视频封面图、视频标题和标签、分类归属、发布者信息、审核状态、播放统计数据、用户评论这些数据在系统里各有归属但又互相牵连。我习惯在动手写代码前先画一张功能清单把系统拆成几个大的模块。前台用户端需要视频列表展示、分类筛选、关键词搜索、视频播放、点赞收藏、评论互动、个人中心。后台管理端需要用户管理、视频审核、分类管理、公告管理、数据统计、敏感词过滤。这还不算系统底层的文件上传、权限认证、日志记录等基础支撑模块。把这张清单列出来数据库表怎么建、接口怎么设计就自然清楚了。这里面有几个容易忽略的地方。第一个是审核机制。很多视频不能发布后立即上架需要先经过管理员审核审核通过才能在前台展示审核不通过要能填写驳回原因。第二个是视频状态管理上下架、推荐置顶、定时发布这些状态都影响前台展示逻辑。第三个是统计数据至少要有播放量、点赞数、评论数这些基础计数后续要做推荐排序也用得上。我设计这套系统的时候把用户区分为普通用户和管理员两种角色。普通用户通过前台页面注册登录可以浏览视频、上传发布、互动评论管理员通过独立的后台入口登录可以对所有视频和用户进行操作管理。两种角色共用一套用户表通过权限字段区分这样实现成本低逻辑也足够清晰。1.2 技术选型为什么是Spring Boot加Vue的组合技术选型这事很多人一上来就追求新哪套框架热门用哪套。实际上对于微视频管理系统这种典型的中小型业务系统Spring Boot加Vue是目前综合成本最低、生态最完善、出问题最好查资料的组合。Spring Boot的优势在于它把复杂的Spring配置简化成了一堆自动配置项开发者不需要关心那些繁琐的XML配置一个启动类就能把整个后端服务带起来。更重要的是Spring Boot生态里有大量现成的集成方案连接数据库用JPA或MyBatis-Plus做安全认证用Spring Security或Sa-Token做缓存用Redis这些组件都有成熟文档遇到问题搜索一下遍地是解决方案。Vue这边我选择Vue 3加Element Plus的组合。Vue 3的Composition API在处理复杂交互逻辑时比Options API清晰得多而Element Plus是一套现成的桌面端组件库表格、表单、弹窗、分页这些后台管理系统常用的组件都有现成的实现不需要自己从头写CSS和交互逻辑开发速度能快不少。前后端分离是这个项目的架构基础。后端只提供JSON接口前端通过HTTP请求调用两者之间用Token做身份认证。这样做的好处是前后端可以并行开发前端开发用Mock数据就能先跑起来后端接口写完了再联调对接。部署上也可以分别伸缩视频访问量大了可以单独扩展后端服务实例静态资源则完全交给云平台处理。1.3 云平台在这套系统里承担的角色很多同学对云平台这个概念理解得含糊以为就是把项目部署到一台云服务器上就完了。实际上云平台在这套系统里承担了三个层面的工作计算资源、存储资源和分发加速。计算资源层面云服务器负责运行Spring Boot后端服务、Nginx反向代理、MySQL数据库和Redis缓存。我建议开发阶段用最小配置的服务器就够用部署上线后根据访问量再做弹性升级。存储资源层面视频文件和封面图片不应该存储在本地磁盘而要放在云对象存储服务上理由很直接视频文件动辄几十上百MB如果所有文件堆在应用服务器本地磁盘空间很快告急而且重启或扩容时文件迁移非常痛苦。分发加速层面对象存储本身一般自带CDN加速功能全国各地的用户访问视频时可以就近拉取内容播放体验比从单一服务器读取好得多。我在具体实现时把文件上传设计成前端直传模式。前端拿到一个临时上传凭证直接把视频文件传给对象存储服务后端只负责记录文件地址和处理业务逻辑。这样就避免了视频文件流经应用服务器造成的带宽和内存压力。这个设计对于视频类项目很重要我后面在部署那部分会专门展开讲。2. 从零构建后端项目结构、核心接口与权限设计2.1 后端工程结构和准备步骤我建立后端工程时习惯按功能模块分包而不是按技术层分包。很多教程喜欢建一堆controller、service、mapper、entity包来放所有类项目规模一大找起代码来很痛苦改一个功能要同时动四五个包里的文件。按功能模块分包的做法是一个模块对应一个包包内自己包含该模块的实体类、控制器、服务类和持久层接口比如用户模块一个包视频模块一个包评论模块一个包。工程搭建完成后先配置基础依赖。项目用到的核心依赖包括Spring Web、MyBatis-Plus框架、MySQL驱动、Redis客户端、JWT认证库。MyBatis-Plus我推荐使用它的代码生成器能根据数据库表自动生成基础增删改查代码省掉大量重复劳动而且它的分页查询封装很顺手。下面是核心依赖的配置参考dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3/version /dependency dependency groupIdcom.auth0/groupId artifactIdjava-jwt/artifactId version4.4.0/version /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-redis/artifactId /dependency数据库设计上我建了这几张核心表用户表user存储账号信息、角色字段和昵称头像视频表video存储视频元数据、文件地址、封面地址、分类ID、状态和统计字段分类表category存储视频分类评论表comment存储用户对视频的评论内容点赞表like_record记录用户点赞行为公告表notice存后台发布的通知内容。建表时有一个细节值得强调视频表里不要只存一个状态字段就完事我把状态拆成了两个维度一个是显示状态草稿、待审核、已上架、已下架一个是逻辑删除标记是否被删除。这样审核流程可以清晰表达用户删掉自己发布的视频也只是逻辑删除数据还能留底追溯。2.2 用户认证与权限控制JWT加拦截器的落地方式微视频系统的权限控制分两级一是判断请求发起者是不是有效用户二是判断这个用户有没有权限执行特定操作。我用的方案是JWT生成登录凭证加自定义拦截器校验不引入Spring Security那套复杂体系因为这个项目本身不需要太细粒度的权限模型拦截器方式代码更直白、排查问题更容易。登录接口的流程是这样的用户提交账号密码后端校验数据库中的密码是否正确校验通过后用用户ID和角色信息生成一个Token字符串返回给前端。前端把Token存在本地后续每次请求在请求头里带上。后端加一个拦截器对所有需要登录的接口统一拦截从Token解析出用户信息后存入当前请求上下文。public class AuthInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token request.getHeader(Authorization); if (token null || token.isEmpty()) { throw new BusinessException(401, 未登录); } try { JWTVerifier verifier JWT.require(Algorithm.HMAC256(SECRET)).build(); DecodedJWT jwt verifier.verify(token.replace(Bearer , )); Integer userId jwt.getClaim(userId).asInt(); request.setAttribute(userId, userId); return true; } catch (JWTVerificationException e) { throw new BusinessException(401, 登录状态无效); } } }用户表的密码存储我坚持用BCrypt加密不用MD5。MD5加不加盐都容易被彩虹表直接破解BCrypt加盐加密基本是目前行业标准做法。注册的时候对密码做加密存储登录的时候用加密库自带的校验方法验证。这里有一个常见坑Token的过期时间怎么设。设太短用户用着用着就被踢下线体验很差设太长又有关Token泄露的风险。我的方案是设置2小时过期时间同时前端在请求发现Token过期后调用一个刷新的接口用旧Token换取新Token。后端的刷新逻辑会校验旧Token是否还在有效期内以及Redis中是否有对这个Token的失效记录如果用户主动退出登录后端会把Token拉黑即使Token没过期也无法继续使用。2.3 视频上传模块分片上传与断点续传的完整实现视频上传是微视频系统里工作量最大的模块。用户上传的视频文件通常比较大网络环境也不稳定如果搞一个整体上传的接口用户体验会很差传了一半网断了就全白费。必须实现分片上传加断点续传。分片上传的思路是前端在浏览器端把大文件切分成多个小块一般是2MB到5MB一个分片然后逐个上传到后端接口。后端每收到一个分片就保存记录所有分片传完后前端通知后端合并分片后端把临时分片文件按顺序合并成完整的视频文件。这里的关键点在于分片的标识问题同一个文件的分片必须能关联起来我用的是文件的MD5值来关联前端在开始上传前先计算整个文件的MD5值每次上传分片时把这个MD5和分片序号、分片总数一起传给后端。PostMapping(/chunk) public Result uploadChunk(RequestParam String fileMd5, RequestParam Integer chunkIndex, RequestParam MultipartFile chunkFile) { // 保存分片到临时目录例如 temp/{fileMd5}/{chunkIndex} String chunkDir uploadConfig.getTempDir() fileMd5; File dir new File(chunkDir); if (!dir.exists()) { dir.mkdirs(); } chunkFile.transferTo(new File(chunkDir, chunkIndex.toString())); return Result.success(); } PostMapping(/merge) public Result mergeChunks(RequestParam String fileMd5, RequestParam Integer totalChunks, RequestParam String fileName) { File chunkDir new File(uploadConfig.getTempDir() fileMd5); File mergedFile new File(uploadConfig.getTempDir() System.currentTimeMillis() _ fileName); try (RandomAccessFile raf new RandomAccessFile(mergedFile, rw)) { for (int i 0; i totalChunks; i) { File chunk new File(chunkDir, String.valueOf(i)); byte[] bytes Files.readAllBytes(chunk.toPath()); raf.seek(i * (long) uploadConfig.getChunkSize()); raf.write(bytes); chunk.delete(); } // 合并完成后后续再上传对象存储、生成封面截图等 } return Result.success(); }前端在上传前会先调用一个检查接口告诉后端文件MD5值。后端查一下这个文件的合并记录和已上传分片列表如果之前传了一半就返回已上传的分片序号前端就能跳过这些分片直接传缺失的部分这就是断点续传的原理。分片上传还涉及一个并发控制细节前端不能设置太大的并发片数并发达多后端临时磁盘IO会飙升我的经验是控制在3个并发分片最稳。另外分片存入磁盘时的命名一定要用序号合并时的顺序才不会乱。2.4 视频处理封面生成与播放地址处理原始视频文件上传完成后还远没到可以上架展示的程度。系统得生成视频封面图、获取视频时长、甚至做格式转码这些工作如果让后端用Java代码直接操作视频但性能很差也没有现成好用的库。我采用的是调用FFmpeg进程来处理视频文件的方案。FFmpeg是视频处理领域的通用工具支持用一行命令截取视频帧作为封面、读取视频时长、转换视频编码格式。后端通过Java的ProcessBuilder启动FFmpeg命令行处理完成后读取返回结果。截取封面的命令通常是这样的ffmpeg -i input.mp4 -ss 00:00:03 -vframes 1 -f image2 cover.jpg这行命令的意思是读取input.mp4的第三秒画面截取一帧图片保存为cover.jpg。后端拿到cover.jpg后再上传到云存储并把封面地址和视频时长一起更新到数据库记录里。视频转码这个环节我建议做但不是必须做全部转码。如果项目跑在内网或者访问量不大原始格式直接播放完全没问题。如果视频要面向互联网用户考虑到不同浏览器和设备对视频编码格式的支持不同最好用FFmpeg转成H.264编码的MP4格式这种格式在浏览器里兼容性最好移动端和PC端都能流畅播放。转码是个消耗CPU的操作我的建议是用异步方式处理上传接口先把视频状态置为处理中转码完成后再更新为已上架。这个异步过程可以先用简单的线程池实现后续业务量大了再引入消息队列也不迟。3. 前端实现思路用户端与后台管理端的分工协作3.1 Vue项目的整体组织与状态管理前端工程我拆成两个独立页面区域面向普通用户的视频前台以及面向管理员的后台管理系统。虽然两者在同一个Vue工程里但通过路由做区分访问路径不同布局风格也不同。前台的关注点是视频展示和播放体验后台的关注点是表格操作和批量处理。Vue工程创建时我直接用Vite工具链搭的Vue 3项目。相比旧的Webpack方案Vite在本地开发时的热更新速度快很多组件库按需引入也更方便。路由用Vue Router状态管理用Pinia。Pinia是Vue官方推荐的状态管理方案对比老的Vuex来说API更简洁且天然支持Composition API的风格。Pinia在项目里主要存储几个全局状态当前登录用户信息、系统配置信息、未读消息数量。视频列表页的数据不建议放全局状态里它属于页面级数据应该留在组件内部管理。全局状态放多了会导致数据流混乱这是一个很容易犯的架构错误我在做这个项目时就特意控制了状态管理的使用范围。3.2 视频列表与播放详情页的交互实现视频列表页是用户打开系统后看到的第一界面。这个页面要实现视频瀑布流式的展现布局视频封面按两列或三列排布用户滚动到底时自动加载下一页数据。这种无限滚动的效果用Vue自身的能力就能实现给滚动容器绑定一个滚动事件判断滚动位置距离底部小于某个阈值时触发下一页请求。视频卡片上的信息要有封面、标题、作者昵称、播放量和点赞量。这里有一个加载性能的细节封面图必须要用懒加载不要页面一打开就把所有封面图都请求一遍。Element Plus的图片组件自带懒加载功能加上就行。视频真正的播放文件不要在列表页加载只有用户点进详情页才开始初始化播放器。详情页的播放器我用的方案是Video.js框架云存储的访问地址直接作为播放地址。如果后端将来要接视频加密或者防盗链再考虑更复杂的播放器方案。视频详情页除了播放器还需要展示视频信息、作者信息、点赞收藏按钮和评论列表。点赞和收藏按钮要与登录状态关联未登录用户点击时弹出登录引导这个交互细节比后端逻辑简单但要记得处理。3.3 后台管理界面的核心页面设计后台管理端是管理员日常使用的主要场所核心页面包括控制台概览、视频审核列表、用户列表、分类管理和评论管理。视频审核列表是这个系统后台最关键的页面。表格中展示待审核视频的缩略图、标题、上传者、上传时间和操作按钮。管理员可以点击查看视频详情也可以直接在列表里通过或驳回。驳回时必须填写原因原因会通知到上传视频的用户。我实现的方式是表格加一个抽屉组件编辑审核意见时在抽屉里操作不会打断列表浏览节奏。用户列表需要支持按用户名搜索、按角色筛选、以及禁用/启用用户的操作。禁用用户后该用户的Token即使没过期也无法访问接口这个逻辑后端要通过检查用户状态实现。分类管理是标准的增删改查页面分类变更后前台视频列表的分类展示会联动变化。整个后台界面做到看一眼就知道当前要干什么的状态。视频审核列表的待审核数量直接展示在导航栏的角标上管理员一登录就能看到有多少条视频等着处理。这种小交互对系统的实际使用体验提升很明显。4. 云平台集成与项目部署从开发到上线4.1 对象存储对接与直传流程视频文件存储是整个项目里最需要认真设计的地方。把视频文件存在应用服务器本地的问题我在前面提过了重启丢失风险、磁盘扩容麻烦、带宽占用大每一个都够让人头疼。所以我把视频和封面文件全部放到云对象存储服务上。对象存储对接的核心是签名上传机制。如果直接把存储空间的访问密钥写到前端代码里那相当于把整个存储空间的钥匙送给了别人。正确做法是后端生成一个临时上传凭证前端拿着这个凭证去上传文件。凭证一般包含访问地址、上传路径、过期时间、签名信息这些内容过期时间一般几分钟过期之后需要重新向后端申请。我在前端Video组件里封装了一个上传方法流程是先调后端的签名接口拿到上传凭证再把视频文件直接用put请求发到对象存储服务。这样视频流量完全不经过应用服务器上传速度和稳定性更好。上传完成后前端把文件URL和文件标识提交给后端后端再保存视频记录。封面图、用户头像这类小图片也是一个道理走直传流程。这里有个使用体验优化小技巧前端在上传视频过程中展示进度条上传进度信息是从对象存储服务返回的进度回调里获取的这个回调不经过后端接口完全是浏览器和存储服务之间的通信省去了后端做进度推送的复杂度。4.2 服务器部署方案与Nginx配置部署环境我用了两台云服务器一台放应用和数据库另一台单独跑Nginx做反向代理和静态资源服务。生产环境下前端Vue项目先执行构建命令打包成静态文件上传到服务器的Nginx站点目录里Nginx负责托管前端页面并向后端接口转发请求。server { listen 80; server_name video.example.com; root /var/www/dist; index index.html; location / { 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; } client_max_body_size 20m; }Nginx配置里有几个关键点。try_files这一行是为了解决Vue路由在刷新页面时404的问题它会把所有不存在的路径回退到index.html。client_max_body_size限制的是请求体大小一般只对接口上传场景有效视频文件本身走对象存储直传不会经过Nginx所以这个限制设置成20M仅用于限制普通接口请求体防止有人恶意提交超大报文。MySQL和Redis安装在应用服务器上后面为了数据安全我建议定期自动备份。刚开始可以每天凌晨用crontab定时任务把数据库导出成文件传到云存储的备份目录里。备份这件事很多人觉得麻烦就不做等真出问题的时候一定会后悔。4.3 部署上线的性能调优要点系统上线前一定要做一次全面的性能检查重点看三个地方。第一数据库连接池配置。Spring Boot默认的数据库连接池HikariCP性能很好但默认配置最大连接数是10并发访问稍微上来就可能会出现获取连接的等待。我一般把最大连接数配置到50到100之间同时设置合理的连接超时时间。连接池不是越大越好开太多会消耗数据库自身的连接资源要根据服务器的内存和数据库的吞吐量折中设置。第二数据库查询优化。视频列表接口默认要按发布时间倒序分页查询如果视频数据量大全表排序会很慢。我给视频表的时间字段和状态字段建了联合索引这样查询条件是状态为上架并按时间排序时可以走索引直接定位数据。统计播放量、点赞量这些高频更新的字段直接对数据库字段做自增操作而不是先查出来再加再更新这样可以避免并发时候的更新冲突。第三一层Redis缓存。视频分类列表、首页热门视频榜单这些不经常变化的数据放进Redis缓存里缓存5到10分钟。接口请求先查缓存缓存没命中再查数据库并回填缓存。这个优化能极大减轻数据库的读取压力实现起来也不复杂。Redis整合到Spring Boot里用官方的Spring Data Redis即可序列化策略建议直接用JSON序列化器方便排查数据问题。5. 项目开发中的典型问题与排查经验5.1 大视频上传乱窜的问题与解决我在开发过程中遇到的第一个大问题是前端上传大视频时用默认的axios配置去调接口结果几分钟后请求直接超时分片上传彻底卡住。排查发现原因是axios默认的请求超时时间是0毫司也就是不超时但Nginx网关层默认的代理超时时间只有60秒请求到Nginx那层就被掐断了。这个问题要在两层同时解决。Nginx层通过配置proxy_read_timeout、proxy_send_timeout把代理超时时间提高到300秒后端Spring Boot的spring.servlet.multipart.max-file-size和max-request-size也要调大。不过这些措施都只是兜底最正确的做法还是坚持分片上传单个分片控制在几MB任何一个分片的请求耗时都在几秒内根本不会被超时问题困扰。后来我也彻底把上传逻辑从普通axios请求换成了分片上传前端传大文件稳定多了。5.2 跨域问题排查开发联调时的常见困扰前后端分离开发时前端跑在5173端口后端跑在8080端口接口请求必然跨域。本地开发阶段我直接方案是后端配置CORS跨域规则允许前端来源访问。配置时要小心一点不要用allowedOrigins(*)加allowedMethods(*)这种全开放写法允许所有来源加允许全部方法在开发调试方便但真要暴露到公网会有安全隐患。生产环境根本不需要跨域配置前端页面和接口请求都通过同一个Nginx域名转发不存在跨域。我见过有人生产环境也配了CORS结果某个浏览器版本出现OPTIONS预检请求直接把接口拖慢的问题排查起来很费时间。5.3 视频播放地址过期导致无法播放对象存储服务的访问地址一般有两种形式私有读和公共读。如果存储空间设的是私有读那访问地址会带签名参数签名有有效期过期了视频就无法播放。我一开始图省事直接在前端保存上传完成时返回的URL。结果第二天用户反馈视频播放不了我排查发现是签名地址过期了。这里有两个解决方法。第一个方法是把存储空间设为公共读视频文件的URL永久有效但任何人都可以直接访问下载视频不太安全。第二个方法是后端对所有视频播放请求通过一个代理接口处理在接口中动态生成有效签名URL返回给前端用户播放时每次拿到都是新签名既保证安全又解决过期问题。生产环境我强烈建议用第二种方案隐私和安全性都更有保障。5.4 Token刷新与登录状态管理的小细节用户登录状态这块我一开始只做了前端接收Token并存储、请求时带Token、接口返回401时跳转登录页。但有一个场景让用户很恼火正在看视频的时候Token悄悄过期了用户点个赞突然弹出登录框之前看的进度也丢了。优化方式有两种一是前端在业务空闲时定时调用刷新接口比如每30分钟刷新一次Token二是在接口返回401时先不跳登录页而是调用刷新接口重试一次如果刷新失败才跳登录。我在实战中把这两种方式都加上了。刷新接口返回新Token后前端要更新本地存储并且用新Token重发刚才失败的请求。这个重试机制写起来不算复杂但用户体验提升很明显。另外要强调一点用户退出登录时前端除了清掉本地Token还要让后端在Redis里记录Token失效状态。否则退出后Token在有效期内还能继续访问接口这算是一个安全漏洞。我在项目上线前的安全自查中发现这个问题补上之后就稳妥了。做这套微视频管理系统前前后后我踩了不少坑从文件上传、处理缓存和Token再到部署上线。如果让我总结最值得分享的经验排序大概是这样的分片上传一定要一开始就做否则后面再改成本很高对象存储直传比后端转发靠谱得多不是可选优化而是必选方案Token失效的刷新重试机制是会直接影响用户体验的关键环节值得花心思做好生产环境部署前一定要做一次数据库索引和缓存检查。这套系统后续要扩展的方向也不少比如视频推荐排序、用户行为分析、多人协审等基础架构搭好之后往这些方向加功能就顺畅多了。
做微视频管理系统这个事说难不难说简单也不简单。市面上刷到的短视频App看着界面轻巧真正到自己要搭一套能跑起来、能管理、能审核、能推送的管理系统时一堆问题就冒出来了——视频怎么传、怎么存、转码要不要做、播放怎么调度、后台怎么审核、用户权限怎么分。这套基于Spring Boot和Vue的云平台微视频管理系统基本就是围绕这些真实需求展开的后端负责处理业务逻辑和数据存储前端负责展示和交互云平台负责解决视频文件的存储、访问和部署问题。我这次把这套系统的完整实现思路、核心代码逻辑、部署方式和踩坑经历整理出来适合正在做短视频类项目的同学也适合想系统了解前后端分离项目如何落地的开发者参考。我的建议是先搞清楚一个前提这不仅仅是一个增删改查的管理后台。微视频系统真正麻烦的地方在文件处理、权限控制、访问性能和部署运维这几个方向数据库表和CRUD反而是最简单的部分。接下来我从项目设计开始讲一直讲到上线部署和实际排查尽量把每一步的逻辑链条讲清楚。1. 先想清楚再动手这套系统的功能边界与设计思路1.1 微视频管理到底在管什么微视频管理系统核心管理的对象不只是视频文件本身而是围绕视频形成的一整套数据链。视频文件本身、视频封面图、视频标题和标签、分类归属、发布者信息、审核状态、播放统计数据、用户评论这些数据在系统里各有归属但又互相牵连。我习惯在动手写代码前先画一张功能清单把系统拆成几个大的模块。前台用户端需要视频列表展示、分类筛选、关键词搜索、视频播放、点赞收藏、评论互动、个人中心。后台管理端需要用户管理、视频审核、分类管理、公告管理、数据统计、敏感词过滤。这还不算系统底层的文件上传、权限认证、日志记录等基础支撑模块。把这张清单列出来数据库表怎么建、接口怎么设计就自然清楚了。这里面有几个容易忽略的地方。第一个是审核机制。很多视频不能发布后立即上架需要先经过管理员审核审核通过才能在前台展示审核不通过要能填写驳回原因。第二个是视频状态管理上下架、推荐置顶、定时发布这些状态都影响前台展示逻辑。第三个是统计数据至少要有播放量、点赞数、评论数这些基础计数后续要做推荐排序也用得上。我设计这套系统的时候把用户区分为普通用户和管理员两种角色。普通用户通过前台页面注册登录可以浏览视频、上传发布、互动评论管理员通过独立的后台入口登录可以对所有视频和用户进行操作管理。两种角色共用一套用户表通过权限字段区分这样实现成本低逻辑也足够清晰。1.2 技术选型为什么是Spring Boot加Vue的组合技术选型这事很多人一上来就追求新哪套框架热门用哪套。实际上对于微视频管理系统这种典型的中小型业务系统Spring Boot加Vue是目前综合成本最低、生态最完善、出问题最好查资料的组合。Spring Boot的优势在于它把复杂的Spring配置简化成了一堆自动配置项开发者不需要关心那些繁琐的XML配置一个启动类就能把整个后端服务带起来。更重要的是Spring Boot生态里有大量现成的集成方案连接数据库用JPA或MyBatis-Plus做安全认证用Spring Security或Sa-Token做缓存用Redis这些组件都有成熟文档遇到问题搜索一下遍地是解决方案。Vue这边我选择Vue 3加Element Plus的组合。Vue 3的Composition API在处理复杂交互逻辑时比Options API清晰得多而Element Plus是一套现成的桌面端组件库表格、表单、弹窗、分页这些后台管理系统常用的组件都有现成的实现不需要自己从头写CSS和交互逻辑开发速度能快不少。前后端分离是这个项目的架构基础。后端只提供JSON接口前端通过HTTP请求调用两者之间用Token做身份认证。这样做的好处是前后端可以并行开发前端开发用Mock数据就能先跑起来后端接口写完了再联调对接。部署上也可以分别伸缩视频访问量大了可以单独扩展后端服务实例静态资源则完全交给云平台处理。1.3 云平台在这套系统里承担的角色很多同学对云平台这个概念理解得含糊以为就是把项目部署到一台云服务器上就完了。实际上云平台在这套系统里承担了三个层面的工作计算资源、存储资源和分发加速。计算资源层面云服务器负责运行Spring Boot后端服务、Nginx反向代理、MySQL数据库和Redis缓存。我建议开发阶段用最小配置的服务器就够用部署上线后根据访问量再做弹性升级。存储资源层面视频文件和封面图片不应该存储在本地磁盘而要放在云对象存储服务上理由很直接视频文件动辄几十上百MB如果所有文件堆在应用服务器本地磁盘空间很快告急而且重启或扩容时文件迁移非常痛苦。分发加速层面对象存储本身一般自带CDN加速功能全国各地的用户访问视频时可以就近拉取内容播放体验比从单一服务器读取好得多。我在具体实现时把文件上传设计成前端直传模式。前端拿到一个临时上传凭证直接把视频文件传给对象存储服务后端只负责记录文件地址和处理业务逻辑。这样就避免了视频文件流经应用服务器造成的带宽和内存压力。这个设计对于视频类项目很重要我后面在部署那部分会专门展开讲。2. 从零构建后端项目结构、核心接口与权限设计2.1 后端工程结构和准备步骤我建立后端工程时习惯按功能模块分包而不是按技术层分包。很多教程喜欢建一堆controller、service、mapper、entity包来放所有类项目规模一大找起代码来很痛苦改一个功能要同时动四五个包里的文件。按功能模块分包的做法是一个模块对应一个包包内自己包含该模块的实体类、控制器、服务类和持久层接口比如用户模块一个包视频模块一个包评论模块一个包。工程搭建完成后先配置基础依赖。项目用到的核心依赖包括Spring Web、MyBatis-Plus框架、MySQL驱动、Redis客户端、JWT认证库。MyBatis-Plus我推荐使用它的代码生成器能根据数据库表自动生成基础增删改查代码省掉大量重复劳动而且它的分页查询封装很顺手。下面是核心依赖的配置参考dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3/version /dependency dependency groupIdcom.auth0/groupId artifactIdjava-jwt/artifactId version4.4.0/version /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-redis/artifactId /dependency数据库设计上我建了这几张核心表用户表user存储账号信息、角色字段和昵称头像视频表video存储视频元数据、文件地址、封面地址、分类ID、状态和统计字段分类表category存储视频分类评论表comment存储用户对视频的评论内容点赞表like_record记录用户点赞行为公告表notice存后台发布的通知内容。建表时有一个细节值得强调视频表里不要只存一个状态字段就完事我把状态拆成了两个维度一个是显示状态草稿、待审核、已上架、已下架一个是逻辑删除标记是否被删除。这样审核流程可以清晰表达用户删掉自己发布的视频也只是逻辑删除数据还能留底追溯。2.2 用户认证与权限控制JWT加拦截器的落地方式微视频系统的权限控制分两级一是判断请求发起者是不是有效用户二是判断这个用户有没有权限执行特定操作。我用的方案是JWT生成登录凭证加自定义拦截器校验不引入Spring Security那套复杂体系因为这个项目本身不需要太细粒度的权限模型拦截器方式代码更直白、排查问题更容易。登录接口的流程是这样的用户提交账号密码后端校验数据库中的密码是否正确校验通过后用用户ID和角色信息生成一个Token字符串返回给前端。前端把Token存在本地后续每次请求在请求头里带上。后端加一个拦截器对所有需要登录的接口统一拦截从Token解析出用户信息后存入当前请求上下文。public class AuthInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token request.getHeader(Authorization); if (token null || token.isEmpty()) { throw new BusinessException(401, 未登录); } try { JWTVerifier verifier JWT.require(Algorithm.HMAC256(SECRET)).build(); DecodedJWT jwt verifier.verify(token.replace(Bearer , )); Integer userId jwt.getClaim(userId).asInt(); request.setAttribute(userId, userId); return true; } catch (JWTVerificationException e) { throw new BusinessException(401, 登录状态无效); } } }用户表的密码存储我坚持用BCrypt加密不用MD5。MD5加不加盐都容易被彩虹表直接破解BCrypt加盐加密基本是目前行业标准做法。注册的时候对密码做加密存储登录的时候用加密库自带的校验方法验证。这里有一个常见坑Token的过期时间怎么设。设太短用户用着用着就被踢下线体验很差设太长又有关Token泄露的风险。我的方案是设置2小时过期时间同时前端在请求发现Token过期后调用一个刷新的接口用旧Token换取新Token。后端的刷新逻辑会校验旧Token是否还在有效期内以及Redis中是否有对这个Token的失效记录如果用户主动退出登录后端会把Token拉黑即使Token没过期也无法继续使用。2.3 视频上传模块分片上传与断点续传的完整实现视频上传是微视频系统里工作量最大的模块。用户上传的视频文件通常比较大网络环境也不稳定如果搞一个整体上传的接口用户体验会很差传了一半网断了就全白费。必须实现分片上传加断点续传。分片上传的思路是前端在浏览器端把大文件切分成多个小块一般是2MB到5MB一个分片然后逐个上传到后端接口。后端每收到一个分片就保存记录所有分片传完后前端通知后端合并分片后端把临时分片文件按顺序合并成完整的视频文件。这里的关键点在于分片的标识问题同一个文件的分片必须能关联起来我用的是文件的MD5值来关联前端在开始上传前先计算整个文件的MD5值每次上传分片时把这个MD5和分片序号、分片总数一起传给后端。PostMapping(/chunk) public Result uploadChunk(RequestParam String fileMd5, RequestParam Integer chunkIndex, RequestParam MultipartFile chunkFile) { // 保存分片到临时目录例如 temp/{fileMd5}/{chunkIndex} String chunkDir uploadConfig.getTempDir() fileMd5; File dir new File(chunkDir); if (!dir.exists()) { dir.mkdirs(); } chunkFile.transferTo(new File(chunkDir, chunkIndex.toString())); return Result.success(); } PostMapping(/merge) public Result mergeChunks(RequestParam String fileMd5, RequestParam Integer totalChunks, RequestParam String fileName) { File chunkDir new File(uploadConfig.getTempDir() fileMd5); File mergedFile new File(uploadConfig.getTempDir() System.currentTimeMillis() _ fileName); try (RandomAccessFile raf new RandomAccessFile(mergedFile, rw)) { for (int i 0; i totalChunks; i) { File chunk new File(chunkDir, String.valueOf(i)); byte[] bytes Files.readAllBytes(chunk.toPath()); raf.seek(i * (long) uploadConfig.getChunkSize()); raf.write(bytes); chunk.delete(); } // 合并完成后后续再上传对象存储、生成封面截图等 } return Result.success(); }前端在上传前会先调用一个检查接口告诉后端文件MD5值。后端查一下这个文件的合并记录和已上传分片列表如果之前传了一半就返回已上传的分片序号前端就能跳过这些分片直接传缺失的部分这就是断点续传的原理。分片上传还涉及一个并发控制细节前端不能设置太大的并发片数并发达多后端临时磁盘IO会飙升我的经验是控制在3个并发分片最稳。另外分片存入磁盘时的命名一定要用序号合并时的顺序才不会乱。2.4 视频处理封面生成与播放地址处理原始视频文件上传完成后还远没到可以上架展示的程度。系统得生成视频封面图、获取视频时长、甚至做格式转码这些工作如果让后端用Java代码直接操作视频但性能很差也没有现成好用的库。我采用的是调用FFmpeg进程来处理视频文件的方案。FFmpeg是视频处理领域的通用工具支持用一行命令截取视频帧作为封面、读取视频时长、转换视频编码格式。后端通过Java的ProcessBuilder启动FFmpeg命令行处理完成后读取返回结果。截取封面的命令通常是这样的ffmpeg -i input.mp4 -ss 00:00:03 -vframes 1 -f image2 cover.jpg这行命令的意思是读取input.mp4的第三秒画面截取一帧图片保存为cover.jpg。后端拿到cover.jpg后再上传到云存储并把封面地址和视频时长一起更新到数据库记录里。视频转码这个环节我建议做但不是必须做全部转码。如果项目跑在内网或者访问量不大原始格式直接播放完全没问题。如果视频要面向互联网用户考虑到不同浏览器和设备对视频编码格式的支持不同最好用FFmpeg转成H.264编码的MP4格式这种格式在浏览器里兼容性最好移动端和PC端都能流畅播放。转码是个消耗CPU的操作我的建议是用异步方式处理上传接口先把视频状态置为处理中转码完成后再更新为已上架。这个异步过程可以先用简单的线程池实现后续业务量大了再引入消息队列也不迟。3. 前端实现思路用户端与后台管理端的分工协作3.1 Vue项目的整体组织与状态管理前端工程我拆成两个独立页面区域面向普通用户的视频前台以及面向管理员的后台管理系统。虽然两者在同一个Vue工程里但通过路由做区分访问路径不同布局风格也不同。前台的关注点是视频展示和播放体验后台的关注点是表格操作和批量处理。Vue工程创建时我直接用Vite工具链搭的Vue 3项目。相比旧的Webpack方案Vite在本地开发时的热更新速度快很多组件库按需引入也更方便。路由用Vue Router状态管理用Pinia。Pinia是Vue官方推荐的状态管理方案对比老的Vuex来说API更简洁且天然支持Composition API的风格。Pinia在项目里主要存储几个全局状态当前登录用户信息、系统配置信息、未读消息数量。视频列表页的数据不建议放全局状态里它属于页面级数据应该留在组件内部管理。全局状态放多了会导致数据流混乱这是一个很容易犯的架构错误我在做这个项目时就特意控制了状态管理的使用范围。3.2 视频列表与播放详情页的交互实现视频列表页是用户打开系统后看到的第一界面。这个页面要实现视频瀑布流式的展现布局视频封面按两列或三列排布用户滚动到底时自动加载下一页数据。这种无限滚动的效果用Vue自身的能力就能实现给滚动容器绑定一个滚动事件判断滚动位置距离底部小于某个阈值时触发下一页请求。视频卡片上的信息要有封面、标题、作者昵称、播放量和点赞量。这里有一个加载性能的细节封面图必须要用懒加载不要页面一打开就把所有封面图都请求一遍。Element Plus的图片组件自带懒加载功能加上就行。视频真正的播放文件不要在列表页加载只有用户点进详情页才开始初始化播放器。详情页的播放器我用的方案是Video.js框架云存储的访问地址直接作为播放地址。如果后端将来要接视频加密或者防盗链再考虑更复杂的播放器方案。视频详情页除了播放器还需要展示视频信息、作者信息、点赞收藏按钮和评论列表。点赞和收藏按钮要与登录状态关联未登录用户点击时弹出登录引导这个交互细节比后端逻辑简单但要记得处理。3.3 后台管理界面的核心页面设计后台管理端是管理员日常使用的主要场所核心页面包括控制台概览、视频审核列表、用户列表、分类管理和评论管理。视频审核列表是这个系统后台最关键的页面。表格中展示待审核视频的缩略图、标题、上传者、上传时间和操作按钮。管理员可以点击查看视频详情也可以直接在列表里通过或驳回。驳回时必须填写原因原因会通知到上传视频的用户。我实现的方式是表格加一个抽屉组件编辑审核意见时在抽屉里操作不会打断列表浏览节奏。用户列表需要支持按用户名搜索、按角色筛选、以及禁用/启用用户的操作。禁用用户后该用户的Token即使没过期也无法访问接口这个逻辑后端要通过检查用户状态实现。分类管理是标准的增删改查页面分类变更后前台视频列表的分类展示会联动变化。整个后台界面做到看一眼就知道当前要干什么的状态。视频审核列表的待审核数量直接展示在导航栏的角标上管理员一登录就能看到有多少条视频等着处理。这种小交互对系统的实际使用体验提升很明显。4. 云平台集成与项目部署从开发到上线4.1 对象存储对接与直传流程视频文件存储是整个项目里最需要认真设计的地方。把视频文件存在应用服务器本地的问题我在前面提过了重启丢失风险、磁盘扩容麻烦、带宽占用大每一个都够让人头疼。所以我把视频和封面文件全部放到云对象存储服务上。对象存储对接的核心是签名上传机制。如果直接把存储空间的访问密钥写到前端代码里那相当于把整个存储空间的钥匙送给了别人。正确做法是后端生成一个临时上传凭证前端拿着这个凭证去上传文件。凭证一般包含访问地址、上传路径、过期时间、签名信息这些内容过期时间一般几分钟过期之后需要重新向后端申请。我在前端Video组件里封装了一个上传方法流程是先调后端的签名接口拿到上传凭证再把视频文件直接用put请求发到对象存储服务。这样视频流量完全不经过应用服务器上传速度和稳定性更好。上传完成后前端把文件URL和文件标识提交给后端后端再保存视频记录。封面图、用户头像这类小图片也是一个道理走直传流程。这里有个使用体验优化小技巧前端在上传视频过程中展示进度条上传进度信息是从对象存储服务返回的进度回调里获取的这个回调不经过后端接口完全是浏览器和存储服务之间的通信省去了后端做进度推送的复杂度。4.2 服务器部署方案与Nginx配置部署环境我用了两台云服务器一台放应用和数据库另一台单独跑Nginx做反向代理和静态资源服务。生产环境下前端Vue项目先执行构建命令打包成静态文件上传到服务器的Nginx站点目录里Nginx负责托管前端页面并向后端接口转发请求。server { listen 80; server_name video.example.com; root /var/www/dist; index index.html; location / { 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; } client_max_body_size 20m; }Nginx配置里有几个关键点。try_files这一行是为了解决Vue路由在刷新页面时404的问题它会把所有不存在的路径回退到index.html。client_max_body_size限制的是请求体大小一般只对接口上传场景有效视频文件本身走对象存储直传不会经过Nginx所以这个限制设置成20M仅用于限制普通接口请求体防止有人恶意提交超大报文。MySQL和Redis安装在应用服务器上后面为了数据安全我建议定期自动备份。刚开始可以每天凌晨用crontab定时任务把数据库导出成文件传到云存储的备份目录里。备份这件事很多人觉得麻烦就不做等真出问题的时候一定会后悔。4.3 部署上线的性能调优要点系统上线前一定要做一次全面的性能检查重点看三个地方。第一数据库连接池配置。Spring Boot默认的数据库连接池HikariCP性能很好但默认配置最大连接数是10并发访问稍微上来就可能会出现获取连接的等待。我一般把最大连接数配置到50到100之间同时设置合理的连接超时时间。连接池不是越大越好开太多会消耗数据库自身的连接资源要根据服务器的内存和数据库的吞吐量折中设置。第二数据库查询优化。视频列表接口默认要按发布时间倒序分页查询如果视频数据量大全表排序会很慢。我给视频表的时间字段和状态字段建了联合索引这样查询条件是状态为上架并按时间排序时可以走索引直接定位数据。统计播放量、点赞量这些高频更新的字段直接对数据库字段做自增操作而不是先查出来再加再更新这样可以避免并发时候的更新冲突。第三一层Redis缓存。视频分类列表、首页热门视频榜单这些不经常变化的数据放进Redis缓存里缓存5到10分钟。接口请求先查缓存缓存没命中再查数据库并回填缓存。这个优化能极大减轻数据库的读取压力实现起来也不复杂。Redis整合到Spring Boot里用官方的Spring Data Redis即可序列化策略建议直接用JSON序列化器方便排查数据问题。5. 项目开发中的典型问题与排查经验5.1 大视频上传乱窜的问题与解决我在开发过程中遇到的第一个大问题是前端上传大视频时用默认的axios配置去调接口结果几分钟后请求直接超时分片上传彻底卡住。排查发现原因是axios默认的请求超时时间是0毫司也就是不超时但Nginx网关层默认的代理超时时间只有60秒请求到Nginx那层就被掐断了。这个问题要在两层同时解决。Nginx层通过配置proxy_read_timeout、proxy_send_timeout把代理超时时间提高到300秒后端Spring Boot的spring.servlet.multipart.max-file-size和max-request-size也要调大。不过这些措施都只是兜底最正确的做法还是坚持分片上传单个分片控制在几MB任何一个分片的请求耗时都在几秒内根本不会被超时问题困扰。后来我也彻底把上传逻辑从普通axios请求换成了分片上传前端传大文件稳定多了。5.2 跨域问题排查开发联调时的常见困扰前后端分离开发时前端跑在5173端口后端跑在8080端口接口请求必然跨域。本地开发阶段我直接方案是后端配置CORS跨域规则允许前端来源访问。配置时要小心一点不要用allowedOrigins(*)加allowedMethods(*)这种全开放写法允许所有来源加允许全部方法在开发调试方便但真要暴露到公网会有安全隐患。生产环境根本不需要跨域配置前端页面和接口请求都通过同一个Nginx域名转发不存在跨域。我见过有人生产环境也配了CORS结果某个浏览器版本出现OPTIONS预检请求直接把接口拖慢的问题排查起来很费时间。5.3 视频播放地址过期导致无法播放对象存储服务的访问地址一般有两种形式私有读和公共读。如果存储空间设的是私有读那访问地址会带签名参数签名有有效期过期了视频就无法播放。我一开始图省事直接在前端保存上传完成时返回的URL。结果第二天用户反馈视频播放不了我排查发现是签名地址过期了。这里有两个解决方法。第一个方法是把存储空间设为公共读视频文件的URL永久有效但任何人都可以直接访问下载视频不太安全。第二个方法是后端对所有视频播放请求通过一个代理接口处理在接口中动态生成有效签名URL返回给前端用户播放时每次拿到都是新签名既保证安全又解决过期问题。生产环境我强烈建议用第二种方案隐私和安全性都更有保障。5.4 Token刷新与登录状态管理的小细节用户登录状态这块我一开始只做了前端接收Token并存储、请求时带Token、接口返回401时跳转登录页。但有一个场景让用户很恼火正在看视频的时候Token悄悄过期了用户点个赞突然弹出登录框之前看的进度也丢了。优化方式有两种一是前端在业务空闲时定时调用刷新接口比如每30分钟刷新一次Token二是在接口返回401时先不跳登录页而是调用刷新接口重试一次如果刷新失败才跳登录。我在实战中把这两种方式都加上了。刷新接口返回新Token后前端要更新本地存储并且用新Token重发刚才失败的请求。这个重试机制写起来不算复杂但用户体验提升很明显。另外要强调一点用户退出登录时前端除了清掉本地Token还要让后端在Redis里记录Token失效状态。否则退出后Token在有效期内还能继续访问接口这算是一个安全漏洞。我在项目上线前的安全自查中发现这个问题补上之后就稳妥了。做这套微视频管理系统前前后后我踩了不少坑从文件上传、处理缓存和Token再到部署上线。如果让我总结最值得分享的经验排序大概是这样的分片上传一定要一开始就做否则后面再改成本很高对象存储直传比后端转发靠谱得多不是可选优化而是必选方案Token失效的刷新重试机制是会直接影响用户体验的关键环节值得花心思做好生产环境部署前一定要做一次数据库索引和缓存检查。这套系统后续要扩展的方向也不少比如视频推荐排序、用户行为分析、多人协审等基础架构搭好之后往这些方向加功能就顺畅多了。
