企业官网建设流程全解析

先说一句大实话：很多初学者拿到一套"企业级点播系统"源码，第一反应是赶紧把代码跑起来，看到登录页出来了就开始沾沾自喜。但等你真正在公司里维护过这类系统之后才会明白，跑起来只是万里长征第一步。企业级这三个字背后，藏着的是权限设计、数据一致性、并发处理、部署回滚这一整条链路。这篇文章我会结合市面上常见的教学级源码和实际生产环境中的做法，把这套SpringBoot+Vue+MyBatis+MySQL架构的点播系统从头到尾拆一遍，重点放在那些源码里没写明白、但面试和生产中又一定会问的东西上。

这套系统的定位不需要我说太多：视频上传、分类管理、用户管理、播放记录、后台统计，标准的点播管理后台功能。如果你手里正好有一份类似结构的源码，或者你想从零手写一个企业级点播系统，这篇文章都适用。我会直接把建表语句、核心接口设计、前后端交互逻辑、部署注意事项全部展开讲，不绕弯子。

1. 为什么点播系统要选这套技术栈：选型背后的真实考量

1.1 市面上常见的点播系统方案对比

先聊一个很多人都没认真想过的问题：点播系统为什么非要用SpringBoot+Vue+MyBatis这套组合？我这边接触过不少做视频平台的团队，最常见的方案其实有三类：

第一类是直接用成熟的云点播服务，比如各家云厂商的VOD产品。视频上传、转码、播放都直接用现成的SDK，后端只负责管理视频的元数据和播放凭证。这种方案上线最快，但成本高，而且你基本没有改造空间，只能按人家的规则玩。

第二类是纯PHP或者Node.js + 原生小程序，很多校园项目、小团体内部视频站很喜欢这么做。优点是轻量，缺点是代码一多就乱，权限模型稍微复杂一点就撑不住。

第三类就是这套SpringBoot+Vue+MyBatis的经典Java EE组合。企业级系统最讲究的就是稳定、规范、边界清晰。Java生态里做权限、做事务、做日志、做监控，工具链太完整了。SpringBoot把配置简化到极致，Vue把前后端分离做得干净利落，MyBatis作为数据访问层足够灵活——复杂SQL你可以在XML里直接写，比JPA那种自动生成SQL的方式可控性强得多。

1.2 这套组合在企业实战中的真实地位

别被"企业级"这三个字吓到。说实话，真正一线互联网大厂内部，点播系统可能用微服务做得更重，甚至引入独立的文件服务、消息队列、搜索引擎。但我们要讨论的这套SpringBoot+Vue+MyBatis单体架构，恰恰是中小型公司、创业团队、以及很多内部培训平台最常用的形态。

它的核心价值在于：单体架构足够简单，一个jar包+一套前端静态文件就能跑起来，运维成本极低。而MyBatis带来的SQL可控性意味着，即使某天你的视频表数据量上来了，你依然可以手动优化SQL、加索引、做分页，不会像一些重度ORM那样拖后腿。

我见过一个很有意思的案例，某团队早期用云点播服务，后来为了降低成本、把转码能力掌握在自己手里，又回退到自研点播系统。结果发现最合适的骨架就是这套SpringBoot+Vue+MyBatis。他们把FFmpeg做成独立服务，SpringBoot只做业务逻辑和数据管理，整个系统依然跑得很稳。

提示：技术选型没有绝对的好坏，关键是你要清楚自己系统的规模边界。单机版点播系统扛得住日均几十万播放量，前提是数据库索引建对了、视频走CDN分发。如果哪天你的业务量涨到日均千万级，再考虑把转码、播放统计、权限中心拆成独立服务也不迟。

2. 数据库设计是系统的地基：从表结构谈权限与资源的关系

2.1 点播系统的核心表设计

拿到源码之后，第一件事不是急着启动，而是打开数据库脚本文件把表结构过一遍。一个企业级点播系统，核心表一定不止"视频表+用户表"两张，至少应该包含以下几张：

用户表（sys_user）：用户ID、用户名、密码（加密存储）、昵称、邮箱、手机号、状态、创建时间。

角色表（sys_role）：角色ID、角色名称、角色编码（如ADMIN、OPERATOR、VIEWER）、状态。

用户角色关联表（sys_user_role）：用户ID和角色ID的多对多关联，这是企业系统的标配。

菜单权限表（sys_menu）：菜单ID、菜单名称、父级ID、路由地址、组件路径、权限标识（如system:video:list）、类型（目录/菜单/按钮）、排序、状态。

视频分类表（vod_category）：分类ID、分类名称、父级ID、排序、状态。树形结构，用来支撑视频的分类管理。

视频信息表（vod_video）：视频ID、标题、描述、封面图URL、视频源文件URL、转码后的播放地址、分类ID、上传人ID、状态（0草稿/1上架/2下架）、播放次数、时长、文件大小、创建时间、更新时间。

播放记录表（vod_play_record）：记录ID、用户ID、视频ID、播放进度（秒）、是否看完、播放时间。

这张表的组合逻辑，本质上是在回答三个问题：谁能登录系统？登录之后能操作哪些菜单和按钮？用户和视频资源之间的关系是什么？

注意用户表和角色表为什么要分开？因为真实场景里权限的颗粒度不是"用户"而是"角色"。你给管理员配置角色，用户只需要挂到角色下面就能继承权限。如果直接把权限字段写在用户表里，后面加一个新角色就要改用户表结构，维护起来非常痛苦。

2.2 MyBatis动态SQL在权限管理中的实战写法

MyBatis在这个系统里的核心价值，是它的动态SQL能力。拿视频列表接口举例，界面上的筛选条件通常有：标题模糊搜索、分类ID、状态、上传时间范围。如果用Java代码拼SQL，又臭又长还容易出SQL注入漏洞，用MyBatis的<where>标签一次搞定：

<select id="selectVideoPage" resultType="com.example.entity.Video"> SELECT v.*, c.category_name FROM vod_video v LEFT JOIN vod_category c ON v.category_id = c.id <where> <if test="title != null and title != ''"> AND v.title LIKE CONCAT('%', #{title}, '%') </if> <if test="categoryId != null"> AND v.category_id = #{categoryId} </if> <if test="status != null"> AND v.status = #{status} </if> <if test="createTimeStart != null"> AND v.create_time &gt;= #{createTimeStart} </if> <if test="createTimeEnd != null"> AND v.create_time &lt;= #{createTimeEnd} </if> </where> ORDER BY v.create_time DESC </select>

这里有几个细节值得展开讲一下：

第一，LIKE CONCAT('%', #{title}, '%')这种写法是防SQL注入的标准姿势。如果你贪图方便直接在Java里拼"%" + title + "%"传进去，一旦title里含有关键字，整个查询条件都可能被改写。

第二，<![CDATA[和>=的使用。MyBatis的XML里，>和<符号是不能直接写的，必须用转义字符。很多人在这上面踩过坑，SQL一直报错却找不到原因。

第三，为什么视频表要冗余一个category_name字段？因为列表页面几乎每次都要显示分类名称，如果每次都JOIN查一次分类表，虽然也能跑，但多表关联的开销没必要。在数据量几十万以内，直接在SQL里JOIN是更规范的做法。我这里LEFT JOIN是因为有视频可能没分类，用INNER JOIN会把没分类的视频过滤掉。

2.3 千万级视频表的分页性能问题

很多教学级源码的分页都是简单的LIMIT offset, size，但在真实的企业级点播系统里，视频表积累到几十万条之后，深分页会明显变慢。比如你要跳到第10000页，MySQL要扫描掉前面所有行才能定位到你的数据，这个代价非常高。

我自己的习惯是两层处理：第一层，如果查询条件里有分类ID，那就直接走(category_id, create_time)的联合索引，然后把order by create_time desc也放进索引，避免filesort。第二层，用子查询的方式优化深分页：

SELECT v.* FROM vod_video v INNER JOIN ( SELECT id FROM vod_video ORDER BY create_time DESC LIMIT 10000, 20 ) t ON v.id = t.id

子查询先只查主键ID，然后回表取完整数据，减少排序和回表的双重浪费。这套优化在数据量达到百万级的时候效果非常明显。当然，如果真到了千万级，就已经不是SQL优化能兜住的了，那时候应该引入分库分表或者直接将播放记录、操作日志这类日志型数据迁到ES或时序数据库去做冷热分离。

注意：方案没有银弹。我看到很多人在视频表才几万条数据的时候就急着上ES、上分库分表，纯属给自己添乱。单体MySQL+合理索引，撑到百万级数据量是完全够用的。

3. 后端核心功能实现：从登录鉴权到视频资源管理

3.1 JWT登录鉴权的完整链路

登录鉴权是每个管理系统的门面，也最容易写出安全隐患。这套系统里用的是JWT（JSON Web Token），流程大致是：用户提交用户名密码，后端校验通过后生成一个token返回给前端，前端把token存在localStorage里，之后每次请求都在header里带上Authorization: Bearer <token>，后端通过拦截器解析token得到用户信息。

JWT的优势不用多说，无状态、不用在服务端存session。但如果你直接照抄某些源码，很容易踩两个坑：

一个坑是token过期时间设置不合理。我见过有人把token有效期设成7天，甚至干脆不过期。这等于把VIP会员卡扔在大街上，谁捡到都能刷。正确做法是access_token设置短一点（比如2小时），再配合一个长期有效的refresh_token做刷新。点播后台虽然不是支付系统，但管理员的权限足以删除视频、修改用户角色，被冒用的后果很严重。

另一个坑是JWT里塞了太多东西。理论上JWT可以携带一些基本信息，但千万别把密码、手机号、身份证这类敏感字段放进去。JWT本身是Base64编码，任何人都能解码看内容，只是没法篡改而已。我的习惯是只放userId和roleCode，其他用户信息需要的时候再查库。

核心代码框架大概是这样的：

// 拦截器里的核心校验逻辑（伪代码） public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { if (HandlerMethod.class.isAssignableFrom(handler.getClass())) { String token = request.getHeader("Authorization"); if (token == null || !token.startsWith("Bearer ")) { throw new BizException(401, "未登录或token已过期"); } try { Claims claims = JwtUtil.parseToken(token.replace("Bearer ", "")); // 把userId放入ThreadLocal，后续业务代码直接获取当前用户 UserContext.set(claims.get("userId").toString()); } catch (Exception e) { throw new BizException(401, "登录状态已失效"); } } return true; }

注意一个细节：解析token放在拦截器还不够，很多时候你需要判断"当前操作的用户是否有权限执行某个动作"，这个不能只靠@RequiresPermissions注解，因为有些按钮权限是数据级的。比如普通运营可以编辑自己上传的视频，但只有管理员能删视频。这种场景我会在Service层再做一次数据权限校验，从ThreadLocal里拿当前userId，然后去查这条视频的归属。

3.2 视频上传与元数据管理的两种路线

视频上传功能可以说是这个系统里最"重"的一个环节。教学级源码常见的做法是：前端用<input type="file">选择文件，后端写一个上传接口，用MultipartFile接收后存到服务器本地目录。这种做法在演示环境跑没问题，生产环境几乎不能用。原因有三个：

第一，单体应用把视频文件存本地，一旦用Docker部署，容器重建视频就丢了。第二，几GB的大文件通过普通HTTP上传，中间断了一次就要重来，用户心态直接崩。第三，视频文件混在应用服务器上，备份、迁移都非常麻烦。

我对这类系统的建议是，至少做到分块上传。前端把一个大文件切成10MB一个的块，逐个上传，后端等所有分块都到了再合并成完整文件。这样不管网络多差，最多重传当前这一个分块，用户体验好非常多。

存哪里？如果公司预算够，直接接OSS就好，后端只负责生成上传凭证（比如临时签名URL），前端直传对象存储，绕过了应用服务器，带宽压力完全不在应用侧。如果预算紧，那就得准备单独的静态资源服务器，比如挂一个NFS盘或者用MinIO搭建私有对象存储。

后端元数据管理相对简单，视频上传成功之后，向vod_video表插入一条记录，状态置为0（待转码）。如果接入了FFmpeg转码服务，那就在转码完成之后把播放地址更新进来、状态置为1（已上架）。这里核心的坑是：千万不要在前端请求里直接传视频地址来更新数据库，合法的改动路径应该是后端根据上传凭证、文件回调、转码回调来更新状态，所有外部输入都只能作为辅助信息。否则你等于告诉所有人，只要能调接口就能把自己的视频改成任意地址，越权风险极高。

3.3 用户管理与接口权限的落地

用户管理模块的逻辑，比想象中要细碎。比如新增用户时要加密密码、分配角色；编辑用户时密码不空才改；删除用户时如果该用户还有视频关联怎么办？一般的做法是逻辑删除（状态置为禁用），而不是物理删除。因为视频表的upload_by字段还指着这个用户，物理删除了外键关联就会悬空。

我的建议是把用户状态设计成独立字段，删除只是把状态置0。查询视频列表的时候，JOIN用户表判断一下用户状态，如果用户被禁用，视频也不展示。这样做数据是干净的，代码也几乎不需要写特殊的异常分支。

接口权限这里要特别注意Shiro/Spring Security这类框架和JWT的结合方式。如果你在一套纯JWT的系统里硬上Spring Security，会碰到一堆配置冲突的问题。更轻量的做法是：自己定义一个@RequiresPermission("system:video:delete")注解，然后用AOP + 拦截器统一校验当前用户的角色菜单权限。这个方法完全够用，而且代码量很少，非常透明，出问题的时候你一眼就能定位到逻辑，不像是用框架的时候黑盒一样全靠猜。

@Aspect @Component public class PermissionAspect { @Around("@annotation(requiresPermission)") public Object checkPermission(ProceedingJoinPoint joinPoint, RequiresPermission requiresPermission) throws Throwable { String permission = requiresPermission.value(); UserInfo currentUser = UserContext.get(); if (!currentUser.getPermissions().contains(permission)) { throw new BizException(403, "无权限访问"); } return joinPoint.proceed(); } }

用这种方式，权限校验的粒度可以精确到按钮级别。比如删除按钮在前端根据权限标识动态渲染，后端接口再校验一次。记住了：前端的按钮显示只是优化用户体验，真正的安全防线永远在后端。

4. 前端管理台的实现细节：Vue如何驱动整个后台

4.1 基于Vue Router的路由权限控制

Vue在这套系统里干的事情，其实可以总结成一句话：把后端返回的菜单权限转成前端路由。很多新手会犯一个错误：所有页面路由都写死在前端router/index.js里，登录之后不管什么角色都渲染同一套菜单，然后指望后端接口挡住"无权限"的请求。结果是接口确实挡住了，但页面布局里全是空空如也的菜单，用户点了才知道没权限，体验极差。

正确的做法是动态路由。后端登录接口返回当前用户的角色和菜单列表，前端在全局守卫router.beforeEach里根据这些信息动态注册路由，渲染对应的菜单项。比如：

// 登录后根据后端返回的菜单列表生成路由 const getDynamicRoutes = (menus) => { const routes = []; menus.forEach(menu => { if (menu.type === 0 || menu.type === 1) { // 目录/菜单 const route = { path: menu.path, name: menu.name, component: () => import(`@/views/${menu.component}`), children: [] }; if (menu.children) { route.children = getDynamicRoutes(menu.children); } routes.push(route); } }); routes.push({ path: '/:pathMatch(.*)*', redirect: '/404' }); return routes; };

这个思路的关键在于后端sys_menu表里维护的菜单，既是数据库里的数据，也是前端的路由映射表。改权限只需要改数据库，不用动前端代码，这就是"配置化"。

动态路由还涉及一个全局守卫的坑：刷新页面的时候，Vue实例会重新初始化，路由又变回静态路由表了，如果你不处理，刷新后路由就丢了。解决办法是在router.beforeEach里加一个判断：如果说明当前用户已经存在且路由还没有动态添加过，先把动态路由加进去再放行，否则直接进入死循环。

4.2 视频管理页面的关键交互实现

视频管理页面是后台最重要的业务页面，一般包含表格、搜索表单、新建弹窗、编辑弹窗、删除确认。看起来是一个普通的CRUD页面，但做完才知道细节都在看不见的地方。

第一个细节：表格数据刷新与分页联动。当你在第5页修改了一条数据，返回列表时不能直接重新拉第5页数据，因为第5页可能已经没数据了，此时应该回到第1页。正确做法是在新增、编辑成功之后，把当前页码重置为1，再调用查询接口。

第二个细节：视频封面的处理。视频封面上传通常和视频文件上传不是同一个接口。你可以在新建视频弹窗里直接放一个封面上传控件，上传成功后返回一个图片URL，存到表单的coverUrl字段，提交时随着表单一起写入数据库。

第三个细节：播放次数的展示。有些视频平台播放次数是虚假繁荣，后台统计页面展示的数字比真实数据大很多。这个问题通常都不是后端统计错，而是前端播放器发送统计请求的方式太粗暴。比如视频一打开就上报一次播放，用户刷新三次就记了三次，看着数字很热闹，实际上没有意义。比较稳妥的做法是至少播放5秒后才上报一次播放量，并且用sessionStorage记录当前用户在当前视频上已经上报过，防止同一次会话内重复统计。这个逻辑虽小，但直接影响后台数据的可信度。

4.3 前后端联调中的常见问题

联调是整个开发过程中最磨人的阶段。我自己调试这类SpringBoot+Vue项目的时候，见得最多的四类问题是这样的：跨域（CORS）、token丢失、时间格式不一致、Base64上传的坑。

跨域的解法有两类：一类是在后端加@CrossOrigin注解，或者配置CorsFilter；另一类是生产环境用Nginx做反向代理，把/api前缀的请求转发到后端8080端口，由代理层解决跨域。生产环境一定用Nginx方案，把跨域问题交给基础设施去解决。

token丢失的排查点通常在请求拦截器。前端一定要在axios的请求拦截器里统一加上Authorization头：

axios.interceptors.request.use(config => { const token = localStorage.getItem('token'); if (token) { config.headers['Authorization'] = 'Bearer ' + token; } return config; });

时间格式问题典型表现是：数据库里存的是2024-01-01 10:00:00，前端拿到的是2024-01-01T10:00:00。这是Jackson序列化LocalDateTime的默认行为。你可以在application.yml中配置spring.jackson.date-format，或者干脆在前端拿到的字符串做格式化。我倾向于在实体类的日期字段上加@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss")注解，一劳永逸。

5. 部署上线全流程：从开发环境到生产环境的经验清单

5.1 jar包构建与MySQL环境初始化

拿到源码之后，最顺利的路径是这样的：先在本地把MySQL跑起来，执行db/init.sql脚本生成全部表结构和初始数据（包括默认管理员账号）。然后修改application.yml里的数据库连接和文件上传路径配置，启动SpringBoot应用。再在Vue前端目录执行npm install和npm run dev，开发环境就全部通了。

前端构建还经常遇到一个版本兼容性问题：老项目使用的Node版本和新装的高版本Node之间存在差异，常见的症状是执行npm install时输出一堆警告甚至直接报错，执行npm run dev的时候提示"数字超出范围"。这类问题你不用死磕，用nvm切换一个旧一点的稳定版本就能过。我自己这边长期用的Node 16.x和18.x都稳定。

生产环境构建上线，后端是标准的mvn clean package -DskipTests，生成jar包后直接java -jar运行。前端npm run build之后生成dist目录，这个目录直接扔给Nginx托管。MySQL生产库，建议至少开一个只读账号给运营的报表查询用，避免测试同学一条SQL把生产库锁了。

提示：jar包启动参数里一定要设置JVM内存，比如java -Xms512m -Xmx512m -jar vod-admin.jar。不设的话默认堆内存是物理内存的1/4，一台2G的服务器上容易直接OOM。同时建议加上-Dfile.encoding=utf-8，防止日志和业务数据在Linux上出现中文乱码。

5.2 Nginx反向代理与前端部署

Nginx在整个系统里的职责有两个：托管前端静态文件、反向代理后端API。配置本身不复杂，但有两个关键细节非常容易错：

第一个是刷新页面404问题。单页应用的路由是前端的history模式，你直接访问/system/user/list，Nginx会在磁盘上寻找这个路径下的静态文件，找不到就会返回404。解决办法是配置try_files回退到index.html：

location / { root /usr/share/nginx/html; index index.html; try_files $uri $uri/ /index.html; }

第二个是API代理的超时时间。视频上传和删除这种大文件操作耗时都比较长，Nginx默认的proxy_read_timeout是60秒，如果视频文件较大，转码合并一次可能超过60秒，就会返回504。一般我会把超时调大：

location /api { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_connect_timeout 30s; proxy_read_timeout 300s; }

第三个是上传大小限制。Nginx默认的client_max_body_size只有1MB，视频上传肯定不行。你要放到至少100MB（如果要支持1GB的大文件，建议前端分块上传，每块大小控制在10MB以内，这样单文件请求不超过10MB，依然安全）。

顺手说下SSL证书的配置，企业系统上线域名必须上HTTPS，证书申请好之后在Nginx的server块里配置ssl_certificate路径，然后把80端口全部重定向到443。这里要说的是：一旦上了HTTPS，前端代码里的API请求地址绝不能写死成http://，不然浏览器会拦截混合内容，接口全挂。正确姿势是请求的相对路径/api写在前端请求拦截器里，Nginx根据域名自动区分HTTP和HTTPS。

5.3 生产环境的日志、备份与常见故障排查

日志是生产环境事故时唯一的线索。SpringBoot应用默认只输出到控制台，如果你用systemd托管服务，Ctrl+C一关，日志就全没了。所以配置里最好加上Logback的滚动文件输出，按天和大小双重切割：

<appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>/logs/vod-admin.log</file> <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy"> <fileNamePattern>/logs/vod-admin.%d{yyyy-MM-dd}.%i.log</fileNamePattern> <maxFileSize>100MB</maxFileSize> <maxHistory>30</maxHistory> </rollingPolicy> </appender>

数据库备份是最容易被忽略的生产操作。很多小团队没有专职DBA，生产MySQL裸奔，数据丢了只能干瞪眼。我的习惯是至少配置每天凌晨自动备份任务，备份文件加上日期标记，保留最近7天。恢复的时候，标准操作是先建一个原子性快照，再在当前环境之外单独导入验证，确认没有问题再回切。不要动不动就在生产库里跑恢复脚本，一个手滑就是全量覆盖事故。

生产环境最常见三个故障这里列一下：

症状一：后台接口全部502。先查后端进程还活着没，再看Nginx有没有重启，最后看MySQL连接数。很多时候是MySQL的max_connections连接数超了，连接池没释放。解决办法是调大连接数上限，但根本对策是查代码有没有连接未关闭，MyBatis的SqlSession是不是批量操作忘记关闭。

症状二：视频上传成功但列表页没有记录。大多是事务问题，上传文件和数据库写入不在同一个事务里。文件上传完成但数据库提交失败时，文件成了孤儿文件。可以加一个定时任务清理"无主上传文件"，只保留当天创建但没绑定业务记录的临时文件。

症状三：播放统计一直为0。前端播放器上报播放次数失败，通常是因为播放页没有调用统计接口，或者调用了但后端接口报错。这个问题优先看浏览器控制台网络请求，比在后端翻日志快得多。

总结与实操建议

最后说一点个人体会：这套SpringBoot+Vue+MyBatis+MySQL的点播管理系统，源码本身并不难，难的是把它真正跑进生产环境。我见过太多人卡在部署阶段，卡在动态路由刷新丢失，卡在Nginx刷新404，卡在JWT过期时间过短导致用户频繁掉线。这些坑，每一个都对应着真实业务场景里的一个具体问题。

如果你是初学者，我的建议是不要只满足于把代码跑起来。动手把数据库表结构画一遍，想清楚每张表为什么这么设计；把权限校验的代码跟到service层，搞清楚一个按钮的权限是怎么从数据库到前端渲染再到后端拦截的；亲手部署到一台云服务器上，把Nginx配置、SSL证书、日志收集这一套走完。等你能把上面任意一条链路从头讲到尾，这套源码对你的价值才算真正发挥出来。

有句话说得很对，源码只是骨架，你往里填的思考才是血肉。希望这篇文章能帮你在填血肉的时候少走几步弯路。