SSM + Django 双技术栈打造视频资源库：上传、转码与播放鉴权全解析-平芜编程栈

1. 项目全貌：这套学习视频资源库系统到底做了什么

先说结论：这是一个典型的双技术栈混合项目。管理端用 Java 生态里的 SSM（Spring + SpringMVC + MyBatis）来写，负责后台管理、用户体系、视频审核、数据统计；视频业务端用 Python 的 Django 来做，负责视频的上传、转码调度、播放接口、搜索推荐。两个端共用一个 MySQL 数据库，前端用 Bootstrap 加 video.js 撑起页面。

我第一眼看到这个技术选型的时候，第一反应是“这怎么混着来”。但真正把它跑起来、维护过一轮之后，会发现这个组合在特定场景下其实是合理的：Java 端承担的是重业务逻辑和高并发管理接口，Django 端承担的是快速迭代的内容分发和媒体处理。很多高校的毕业设计、企业内部的学习平台、甚至一些培训机构的课程管理系统，都喜欢用这种“既有 Java 深度、又有 Python 效率”的架构来展示综合能力。

这套系统适合几类人：

正在做毕设或者课程设计的学生，需要一个能写清楚、能演示、能写进论文里的完整业务系统；
刚入门 SSM 和 Django 的后端开发者，想看看两种主流框架如何在同一个项目里协同配合；
企业内部要做学习培训平台的技术同学，可以参考它的权限设计、视频存储和播放鉴权思路。

我手上这套东西，交付物是标准的“源码 + LW（论文/文档）+ 调试文档 + 讲解”。源码是完整可运行的，LW 里把需求分析、数据库设计、接口设计、测试报告都写好了，调试文档记录了每个模块的启动步骤、环境变量、常见报错处理方式，讲解部分则对应着一套视频或直播录屏，带着你从建表开始把项目跑起来。

这里想提醒一句：不要被“学习视频资源库”这个名字骗了，觉得它就是个简单的视频列表加播放页面。真正往深了做，它涉及文件上传、断点续传、视频转码、播放权限控制、搜索排序、行为记录、后台统计等一整套链路。任何一个模块拿出来，都能单独水一篇技术笔记。

2. 核心设计拆解：从表结构到接口语义

2.1 数据库设计：九张核心表怎么串起来

这套系统的数据库设计是典型的 SSM 管理端思维：用户、角色、菜单、权限分开建表，走 RBAC 权限模型；视频资源、分类、评论、收藏、播放记录单独成表，走内容业务模型。

我梳理了一遍，核心表大致如下：

表名	作用	关键字段
sys_user	用户表（管理员、普通用户）	username、password、role_id、status
sys_role	角色表	role_name、role_key
sys_menu	菜单/权限表	menu_name、parent_id、perms
video_category	视频分类表	category_name、sort、status
video_info	视频信息表	title、cover_url、video_url、category_id、uploader_id、status
video_comment	评论表	video_id、user_id、content、create_time
video_favorite	收藏表	video_id、user_id、create_time
play_record	播放记录表	video_id、user_id、play_time、duration
sys_log	操作日志表	user_id、operation、method、params、ip、create_time

这些表之间的关系并不复杂：video_info 通过 category_id 关联分类，通过 uploader_id 关联上传用户；评论、收藏、播放记录都通过各自的 video_id 和 user_id 做多对一关联。权限上，sys_user 挂 sys_role，sys_role 通过中间表关联 sys_menu，形成“用户-角色-权限”的经典模型。

我在实际复现时特别注意两个字段：一个是 video_info 表的 status 字段，它不只是“上架/下架”两态，还涉及视频的审核状态，比如待审核、审核通过、审核拒绝、已下架。很多萌新在这个字段上只放一个 int 类型，但没想清楚状态流转，导致后面的视频管理模块写得稀烂。另一个是 play_record 表，它一定要记录视频总时长和用户实际观看时长，这不仅是播放记录，更是后续做“学习进度”和“完成率统计”的数据基础。

2.2 Java 管理端的关键模块实现

SSM 管理端的核心职责是：登录认证、用户管理、视频审核、分类维护、数据统计。这里面的两个关键点是 SpringMVC 的接口语义和 MyBatis 的动态 SQL。

登录认证我建议用拦截器加 Session 的方式，而不是一上来就上 Spring Security。原因很简单：SSM 项目的定位是中小型后台管理系统，Spring Security 的过滤器链配置对新手不友好，出了问题很难排查。而拦截器加 Session 的做法，逻辑直白，写论文也好解释。具体做法是定义一个 LoginInterceptor，在 preHandle 里判断 Session 中是否有登录用户，没有就跳转到登录页并携带 redirect 参数，登录成功后原路跳回。

视频审核模块的查询条件通常包括：标题模糊搜索、分类筛选、状态筛选、上传时间区间。这正好是 MyBatis 动态 SQL 的用武之地。mapper.xml 里用标签把多个拼起来，注意参数名要用 @Param 注解明确指定，否则 MyBatis 会因为参数名解析问题抛异常。这里有个我踩过的坑：如果用 Java 8 编译且没有开启 -parameters 编译参数，mapper 接口里写多参数时必须加 @Param，否则启动时直接报 BindingException。

数据统计模块可以简单地用 MyBatis 写聚合查询：按分类统计视频数、按天统计新增用户数、统计总播放量。这些指标不需要实时精确，做个定时任务每天凌晨跑一次，把结果写入统计表即可。一定不要图省事直接在管理首页每次请求都查全表聚合，数据量一上来，页面就会卡到你怀疑人生。

2.3 Django 视频端的鉴权与流媒体处理

Django 端在这套系统里承担的是用户端 API 和视频内容服务。它和 Java 端共用同一套 MySQL，但连接的是不同的业务表。用户端看到的视频列表、搜索、播放地址获取，都由 Django 提供。

Django 创建应用的常规操作是python manage.py startapp video，然后去 settings.py 里注册。模型层我强烈建议用 Django 自带的 ORM，而不是裸 SQL，因为 Django 对模型迁移（makemigrations、migrate）支持得很好，可以和 MySQL 中的表结构保持同步，省去大量手工建表的工作。

有个细节：如果 Java 端已经用 MyBatis 建好了表，Django 这边用 ORM 反向建模时，注意所有模型类要加上db_table = 'xxx'明确指定表名，并且 Meta 类里设置managed = True。如果设置成 False，Django 会认为表由外部管理，迁移时会跳过建表，这对我们没好处。

视频播放接口的核心是鉴权。最粗浅的方案是视频地址直接暴露给前端，任何人拿到链接都能下载。好一点的方案是 Django 端生成一个带过期时间的签名播放地址，比如把 video_id、过期时间戳、随机数拼在一起做 MD5/HMAC 签名，前端播放器拿到的视频地址形如/api/video/play?vid=1001&exp=1700000000&sign=xxxxx，Django 在视图里校验签名和时间戳，合法才返回文件流或重定向到转码后的文件地址。这套思路实现成本低，但已经能挡住绝大多数白嫖链接的爬虫。

视频转码是 Django 端最容易被人忽略的部分。如果只是本地文件系统存原视频，直接用 video.js 或 hls.js 播放，浏览器兼容性会很差。我建议在服务器上安装 FFmpeg，Django 收到上传请求后丢给 FFmpeg 转成 HLS 格式的 m3u8 分片（ts），转码完成后再把 m3u8 地址写回数据库。步骤是：

ffmpeg -i input.mp4 -profile:v baseline -level 3.0 -s 1280x720 -start_number 0 -hls_time 6 -hls_list_size 0 -f hls output.m3u8

这个命令把视频压成 720p 的 H.264 流，每个分片 6 秒。Note 一下：-hls_time 太小分片太多，播放时频繁请求；太大秒开体验差。6 秒是常规选择。

3. 从零复现：环境搭建与关键代码落点

3.1 环境准备：JDK、Maven、Python、MySQL 的版本搭配

这套项目跑起来的版本组合，我建议按下面这套来，跟着这套走能少踩一大半坑：

JDK 1.8（不是 11 也不是 17，SSM 项目大多是老底子，JDK 1.8 最稳）
Maven 3.6.3 或 3.8.x
Tomcat 8.5 或 9.0
Python 3.8 到 3.10（Django 3.2 或 4.0 都行，别上 5.0 太新的版本，部分依赖可能没跟上）
MySQL 5.7 或 8.0（注意 8.0 的驱动包要用 mysql-connector-java 8.x，驱动类名是 com.mysql.cj.jdbc.Driver，连接串要加 serverTimezone=Asia/Shanghai）

Java 环境变量配置是老生常谈，但每次都会有人卡住。JAVA_HOME 指向 JDK 安装目录，Path 里追加%JAVA_HOME%\bin，然后命令行执行java -version验证。注意别把 JDK 的 bin 路径写成绝对路径，后面换版本很痛苦。

Python 这边建议建虚拟环境，不要全局安装依赖。激活虚拟环境后，pip install django==3.2 mysqlclient，其中 mysqlclient 在 Windows 上经常编译失败，可以改用 pymysql，然后在 Django 项目目录下import pymysql; pymysql.install_as_MySQLdb()，写进__init__.py里。

3.2 SSM 管理端配置与常见注解用法

SSM 工程的标准结构是：controller、service、mapper、entity 四层。启动后先看 spring-mvc.xml 和 spring-mybatis.xml 两个配置文件，这是整个项目的命脉。

面试里最高频的“SSM 常用注解”，实际上就是这套项目里每天都在写的东西：

@Controller：SpringMVC 的控制器层标注；
@RequestMapping/@GetMapping/@PostMapping：映射 URL 和方法；
@RequestParam：接收请求参数，配合 required 和 defaultValue 使用；
@PathVariable：接收 URL 路径中的参数，比如/video/delete/{id}；
@ResponseBody：把返回值序列化为 JSON 写回前端，和 Jackson 依赖配套；
@Autowired/@Resource：依赖注入，推荐用 @Resource 按名称注入，避免同类型多个 Bean 时冲突；
@Transactional：事务注解，在视频删除、更新用户状态这类需要保证原子性的方法上加。

配置文件里最容易出错的是 MyBatis 的 mapper 扫描路径。spring-mybatis.xml 里要配置MapperScannerConfigurer，把basePackage指向 mapper 接口所在的包，这样容器启动时才会为每个接口生成代理 Bean。否则你在 service 里 @Autowired 一个 mapper 接口，启动直接报NoSuchBeanDefinitionException。

3.3 Django 创建 App 与视频上传接口

Django 侧我是这样组织的：项目叫 video_server，里面创建名为 api 的 App 和一个名为 file 的 App。api 处理业务请求，file 处理视频文件上传和读取。

上传接口的核心逻辑不复杂：接收 POST 请求，从 request.FILES 取出文件，做类型校验（扩展名和 MIME 双重检查，防止别人传个 .exe 伪装成 .mp4），然后保存到媒体目录。保存时文件名别直接用原始文件名，否则会产生中文乱码、路径穿越之类的问题。我是用uuid4().hex生成新文件名，保留原始扩展名：

import uuid from django.core.files.storage import FileSystemStorage def handle_upload(file): ext = file.name.rsplit('.', 1)[-1].lower() allowed = ['mp4', 'avi', 'mkv', 'mov', 'webm'] if ext not in allowed: raise ValueError('不支持的文件类型') new_name = f"{uuid.uuid4().hex}.{ext}" fs = FileSystemStorage(location=settings.MEDIA_ROOT) filename = fs.save(new_name, file) return filename

上传后要异步触发转码。最省事的做法是直接用 Django 的django-q或者celery，但很多毕设项目不想引入太重的东西，我见过不少直接把 FFmpeg 命令通过subprocess.Popen丢到后台进程执行的方案，也能用，但要注意进程数和执行环境的隔离问题。

Django 的查询与删除这里顺手提一下，Model.objects.filter(video_id=1).delete() 会返回删除数量，但如果你有外键关联且没有设置 CASCADE，删除会被保护。所以设计表结构时，评论、收藏这类关联表的外键要明确on_delete=models.CASCADE，否则清理数据时会报 ProtectedError。

3.4 前后端联调与跨域处理

前端页面如果直接请求 Django 和 Java 两个端，会产生跨域问题。Java 端的 SSM 接口通常和前端同源，问题不大；Django 端如果独立端口运行，就需要处理 CORS。

最简单的做法是安装 django-cors-headers，在 INSTALLED_APPS 和 MIDDLEWARE 里各加一条，然后在 settings.py 里配置：

CORS_ALLOWED_ORIGINS = [ "http://localhost:8080", "http://127.0.0.1:8080", ] CORS_ALLOW_CREDENTIALS = True

这里千万注意：如果要携带 Cookie 做登录态认证，CORS_ALLOW_CREDENTIALS 必须为 True，且 ALLOWED_ORIGINS 里不能写*，否则浏览器会直接拦截响应。

联调接口时，我一直用 Postman 或者 Apifox 做接口自测。把接口文档整理好，前端同学对接起来效率能高一倍。调试文档里应该记录每一个接口的请求方式、URL、参数示例和返回 JSON 案例，这套系统交付内容里的调试文档就是这么写的，实测照着文档调不出来接口的情况基本没有。

4. 部署、调试与维护实录

4.1 部署方案：Tomcat 加 uWSGI 还是 Nginx 反代

部署这块，我推荐一套非常稳妥的组合：整个体系跑在一台 Linux 服务器上（比如腾讯云、阿里云的 2C4G 轻量服务器），Java 端用 Tomcat 运行在 8080 端口，Django 端用 uWSGI 或 Gunicorn 跑在 8000 端口，最前方用 Nginx 监听 80/443 做反向代理和静态文件服务。

Nginx 的配置可以这样写：

server { listen 80; server_name yourdomain.com; location /api/java/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } location /api/video/ { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } location /media/ { alias /data/media/; expires 7d; add_header Cache-Control public; } }

把 Java 和 Django 的接口路径前缀区分开，Nginx 按路径分流，这样前后端联调时只面对一个域名，跨域问题几乎消失。静态媒体文件交给 Nginx 直接返回，别让 Django 和 Tomcat 处理文件 IO，能省掉大量不必要的性能损耗。

Tomcat 部署 Java 项目时，我习惯打成 WAR 包放到 webapps 目录，或者在 IDEA 里配置好 Artifact 直接跑。但线上环境别用 IDEA 的内置 Tomcat，老老实实mvn clean package生成 WAR，再丢到独立的 Tomcat 里。部署后留意 catalina.out 日志，确认没有异常堆栈再绑域名。

uWSGI 启动 Django 的命令，我一般写成一行：

uwsgi --http 127.0.0.1:8000 --module video_server.wsgi:application --processes 4 --threads 2 --stats 127.0.0.1:9191

注意 module 参数是“项目配置目录.wsgi 模块”，不是项目根目录。这里写错会直接报 ModuleNotFoundError。生产环境还可以再套一层--chdir指定项目的绝对路径，避免相对路径找不到模块。

4.2 调试文档怎么用：断点、日志与复现路径

这套项目的调试文档我翻过一遍，质量不错，不像网上很多“只有截图没有逻辑”的应付文档。它的结构是：每个模块一个章节，先说明功能，再给关键的配置和代码片段，最后是常见的报错信息与解决办法。

真到排查 bug 的时候，我建议按这个路径来：

先看浏览器开发者工具里 Network 面板的请求状态码，区分是 404、500 还是 302；
如果是 500，去后端日志里搜异常堆栈的第一行，基本能定位到是空指针、SQL 语法、还是类型转换问题；
定位到代码行后，用 IDEA 的 Debug 模式打断点，注意检查断点是落在方法入口、循环内部，还是返回语句；
如果涉及前端传参，先把请求参数和响应 JSON 复制出来，单独用 Postman 复现，排除前端问题。

这里分享一个非常实用的技巧：Django 和 SpringMVC 日志里，出现最频繁的报错是空指针和字段不存在。MyBatis 里如果返回的结果集字段与实体类属性对不上，默认不会报错，而是把该字段设为 null，后续业务逻辑踩到就出空指针。排查这种问题，先看数据库查询语句的列名和实体类的驼峰属性是否一致，是否开启了 mapUnderscoreToCamelCase。

调试文档里还提到了一个很好的习惯：给每个接口写一个“复现路径”，即“用什么账号、带什么参数、调什么接口、预期返回什么”。把这套路径维护好，后面接手的人能省下大量时间。我个人的经验是，哪怕项目已经交付，也要把调试文档当成活文档持续维护，每次线上问题修复后补一条记录，三个月后你会发现问题排查速度提升了不止一倍。

4.3 线上问题的常见排查思路

线上最常见的四类问题，我逐一列一下排查思路：

第一，页面能打开但视频播放不了。先 ping 一下视频域名或 IP，再用 curl 去请求 m3u8 文件，看返回码。如果是 403，大概率是鉴权校验失败或防盗链规则拦截；如果是 200 但返回空内容，检查服务器磁盘是否满了；如果 m3u8 能打开、ts 分片打不开，检查 Nginx 的 alias 路径和分片文件权限。

第二，Java 端接口动不动就超时。先看 MySQL 慢查询日志，把执行时间超过 1 秒的 SQL 捞出来，用 EXPLAIN 看有没有走索引。视频列表页的查询最容易翻车，因为我前文提到 video_info 表数据量变大后，不带索引的分类筛选会全表扫描。解决方案是给 category_id 和 status 建联合索引，查询条件里也用同样的字段顺序。

第三，Django 内存占用越来越高。通常是开启 debug 模式导致的，Django 在 DEBUG=True 时会缓存大量调试信息。生产环境必须把 DEBUG 设成 False，同时设置 ALLOWED_HOSTS。如果跑着跑着内存还是涨，检查是不是用了同步方式跑视频转码，导致进程阻塞时间太长。把转码改成异步队列之后，内存表现会立刻改善。

第四，上传视频后列表没有更新。多数情况是缓存问题。Java 端和 Django 端调用的是同一个数据库，但有些开发者会在接口层加 Redis 缓存视频列表，缓存过期时间设得太长，就会造成“库里有了、页面没更新”。排查这类问题，先确认是否引入了缓存，再手动删掉对应 key 测试。

4.4 升级与优化：从单机到按需扩展

这类学习视频资源库系统，初期单机部署够用，但视频业务增长很快，我这里给出一个实用的升级路线，按投入产出来排序：

第一步，把视频文件从本地磁盘迁到云存储，比如阿里云 OSS、腾讯云 COS。迁移后，Nginx 不再需要处理媒体文件请求，服务器磁盘压力骤降。Django 端只需要生成带签名的临时访问链接即可。

第二步，把视频转码丢到消息队列加独立 Worker。视频转码是 CPU 密集型任务，和 Web 服务混在一台机器上，高峰期会互相拖累。用 Redis 队列 + 独立 Worker 的方式，既能削峰，又能让 Worker 单独扩容。

第三步，给 MySQL 做读写分离。Java 管理端和管理员操作走主库，Django 用户端的列表查询、播放记录写入走从库。这一步建议在业务量真起来之后再做，否则只是徒增复杂度。

第四步，引入 Redis 做播放排行、热门推荐、用户 Session 集中存储。Session 集中存储的意义在于，后面如果 Java 端要横向扩容成多节点，Session 不落在单机内存里，登录状态就不会丢失。

我见过太多人一上来就想上微服务、上 K8s，结果项目复杂度翻了十倍，体量却只有百人规模。对这个项目来说，单机加云存储加队列，已经能撑住非常可观的用户量。升级的本质是解决问题，不是炫技。

5. 避坑手册：视频系统独有的那些坑

5.1 文件上传与磁盘管理

视频文件普遍几百 MB 到几个 GB，和后端常见的图片上传根本不是一回事。表单上传时，Django 的 DATA_UPLOAD_MAX_MEMORY_SIZE 默认是 2.5MB，超过这个值的文件必须走流式写入，不要直接 read 到内存；Nginx 的 client_max_body_size 默认 1MB，不改这个配置，上传大文件会直接返回 413，这是个必踩的坑。

配置建议：

client_max_body_size 2g; proxy_read_timeout 300s; proxy_send_timeout 300s;

Django 这边我强烈建议设置文件大小上限校验，比如单文件不超过 1GB，否则有人会上传一个大几十 GB 的文件把磁盘塞爆。磁盘监控也要做，最简单的就是写个 crontab 脚本，每天检查媒体目录磁盘占用率，超过 80% 就报警。

生成文件名时用 UUID 是必须的，这一点我再强调一遍。用原始文件名，中文、空格、特殊字符都会成为隐患，遇到同名文件还会覆盖。排障时看到文件名满屏乱码，排查成本非常高。

5.2 并发播放与数据库压力

视频播放本身不太消耗后端资源，因为文件在 Nginx 或云存储那一层就返回了，但“记录播放记录”这个操作会在高并发下对数据库产生压力。每次播放、每 6 秒上报一次进度，如果表里没有索引，数据库很快撑不住。

我的处理方式是把播放记录写入改成异步。前端每 10 秒上报一次进度，Django 收到后先写到 Redis 的 Hash 结构里，key 为play_record:{video_id}:{user_id}，value 为播放进度。定时任务每 5 分钟把 Redis 数据批量写入 MySQL 的 play_record 表。这样用户量不大时，数据库几乎零压力。

这里还要注意一个播放器选择的问题。pc 端用 video.js，移动端用 hls.js，都要配置好。如果你只输出 mp4 文件，不做 HLS 切片，很多移动端浏览器的 video 标签是能播，但拖动进度条时体验很差，尤其是 AMR 这种格式，浏览器直接不认。我给的方案就是统一转码成 HLS，然后在 video.js 里配置type: 'application/x-mpegURL'。

5.3 权限校验与安全问题

这套系统涉及两种完全不同的用户：管理员和普通学习者。如果权限校验只做在前端隐藏按钮，后端接口不校验，那等于把管理后端脱光暴露在公网，随便调删除接口就能删库。

Java 管理端的每个写操作接口，应该在 intercept 里校验当前登录用户的角色，并在 Controller 方法里校验操作的目标资源是否归属当前用户。Django 用户端的播放鉴权，按前面说的签名 URL 方案做，但签名密钥要放在环境变量里，不要写死在代码或者提交到仓库。

还有一个很容易被忽略的安全点：视频文件目录不要直接可浏览。Nginx 配置里打开autoindex off，云存储的 bucket 权限也要设为私有读。视频链接全部走后端签名临时地址，过期时间设 15 到 30 分钟，既能防盗链又能防止别人批量下载。

登录接口的密码存储也提一句：Java 端和 Django 端都不要用明文密码或者简单 MD5。用 Spring Security 的 BCryptPasswordEncoder（Java 端）和 Django 自带的make_password/check_password（Python 端）来做哈希校验。就算数据库泄漏，想从哈希还原密码也要费很大力气。

6. 个人实操中的一些心得

整套项目我现在维护已经超过半年，期间踩过的坑不算少，最后分享几条实际感触最深的经验。

第一，双技术栈项目最容易出问题的是两边对数据状态的定义不一致。Java 端说“status=1 代表上架”，Django 端也必须完全一致，这个一定要在开发前期用一个文档统一固定下来，两边代码里都不要出现魔法数字，都定义成枚举常量。我之前碰到过 Java 端的 0/1 和 Django 端的 1/2 对不上，两个端查出来同一个视频状态相反，折腾了整整一个下午才定位到问题。

第二，调试文档里记录的报错信息一定要配套当时的解决方案，不要只复制异常堆栈。我的习惯是每条记录里写清楚：异常信息、影响范围、排查步骤、解决方案、后续预防措施。这五要素写全，调试文档才真正有引用价值。

第三，视频资源库这类系统，内容版权审核要放在业务里考虑，而不只是技术上做到能播就行。上传入口要有内容审核，管理员端要有下架机制，这些功能就算暂时不做，也要在数据库设计里把 status 字段预留好。别等需要的时候再改表结构，那时候每加一个字段都要牵动两端代码。

这个项目给我最大的收获，其实是让我把 Java 和 Python 两套生态都串了起来。如果你也正在搞类似的系统，我的建议是别只盯着某一种语言的技术细节，多想想数据怎么在两个端之间流动，权限怎么才能一致，资源怎么才能管好。把这些想通了，一套系统跑起来、跑稳了，比单独写一百个 Demo 都管用。