Django视频点播后台管理系统设计：模型、admin与播放链路源码解析

简介：一份基于Django框架的视频点播后台管理系统源码，面向Python Web开发者与需要搭建管理后台的项目人员。系统涵盖用户管理、权限控制、视频上传与分组等核心功能，采用MVC分层设计，借助Django自带Admin与ORM简化数据操作，便于视频内容的统一管理与扩展。资源包共43个文件，约1022KB，包含16个Python源码、12个Python字节码、7个XML配置、SQL数据库及说明文档等，分别承担系统逻辑、运行缓存、项目配置、数据初始化与使用说明，结构清晰，便于本地部署与二次开发。项目中迁移文件记录了数据表演进过程，适合作为课程设计、毕业设计或快速搭建点播管理原型的参考。目前已有281人学习下载，可帮助开发者缩短开发周期，掌握Django后台系统的完整落地思路。

1. 视频点播后台管理系统，掉链子的从来不是播放器

视频点播后台管理系统，最难的不是播放页那个<video>标签，而是后台管理这一层：视频表怎么建、批量上下架怎么不出错、播放地址怎么防扒、数据上万条后查询还快不快。「基于Django框架的视频点播后台管理系统设计源码」这个标题背后其实是三件事：Django 自带 admin 和 ORM，天生适合内容管理后台；点播又比普通 CMS 多了文件流、鉴权和异步转码；源码要能复现，就得把模型、admin、播放链路一层层说清。适合正在用 Django 搭内容系统的人，也适合拿到别人源码后知道先翻哪几个文件。

2. 点播后台的数据模型设计：Django 里先把 Video 这张表立住

任何 Django 视频点播项目，源码里最值得先读的都是 models.py。播放器换了组件还能跑，表结构错了后期要动就是伤筋动骨。以最常见的运营场景为例：运营要维护分类和上下架，用户端要按分类浏览、播放并记录进度，后台要统计播放量。这三件事对应三张核心表：Category、Video、PlayRecord。把字段和关系定清楚，后台管理界面后面只是把这些字段摆出来而已。

2.1 视频主表、分类树与播放记录：三张表撑起点播后台的骨架

Video 表是后台管理的中心，字段设计要同时满足运营展示和播放鉴权两个目的。下面是一版在真实项目中能直接落地的字段划分：

分类用自关联外键做树形结构，parent 为空表示一级分类。on_delete 别用 CASCADE：分类被删除时级联语义在后台很容易造成整批视频显示异常。用 PROTECT 后，删除分类会被 Django 拦截，运营只能先转移视频再删分类，这个兜底对后台系统很重要。

PlayRecord 记录用户观看行为，字段是 user、video、duration_watched、created_at 四件套，外加 user 和 video 的联合索引。它不参与后台管理主流程，但播放量统计和「继续观看」功能都依赖它，属于点播系统源码里容易被忽略、实际查询压力最大的一张表。接下来看它怎么通过 Django 迁移落到数据库里。

2.2 从 startapp 到 migrate：用 Django 迁移把模型落到 MySQL

常见做法是新建项目后单独起 video 这个 app，职责清晰。以 MySQL 为库，最小命令序列是：

pip install django mysqlclient django-admin startproject vod_admin . python manage.py startapp video python manage.py makemigrations video python manage.py migrate

第一条命令里 mysqlclient 在部分 Linux 发行版上需要先装系统依赖 libmysqlclient-dev，装不上时可以改用 PyMySQL，并在项目的__init__.py里执行pymysql.install_as_MySQLdb()作为降级方案。settings.py 里要把 video 加进 INSTALLED_APPS，DATABASES 按实际库名和账号改好，再执行后两条命令生成迁移文件并建表。

把模型写进video/models.py后，迁移文件是源码的一部分，不要扔进 .gitignore。团队协作时另一个环境只需要python manage.py migrate就能把表结构追平。字段后续变更一律走 makemigrations，直接改表是后面排查问题时最麻烦的历史遗留。

class Meta: ordering = ['-created_at'] indexes = [ models.Index(fields=['status', 'published_at']), ]

这个 Meta 里的联合索引对应后台列表页最常见的筛选组合：按状态过滤、按上架时间排序。索引字段顺序要和查询条件对齐，状态在前、时间在后，走索引时过滤和排序一次完成，视频量到十万级时效果比单字段索引明显。

2.3 状态字段当软删除用：下架不删文件，播放记录按月归档

后台管理界面里永远不要提供太直接的「删除」按钮。视频文件动辄几百 MB，Django 的 ORM 删除记录不会同时删掉磁盘文件，记录删了文件还在就成了孤儿文件，日积月累占满存储。常见做法是把删除区分成两种语义：下架等于软删除，状态置为 offline，列表页默认过滤掉；彻底删除则由一个 management command 定期扫描回收站，确认到期后先删文件再删记录。

Video.objects.filter(status='offline').delete()

这段代码要谨慎执行，它会真正删除选中的记录。delete() 是立刻提交的批量操作，不会触发每个实例的 save()，如果有自定义信号依赖这里要另想办法。运营日常操作落在批量更新上下架的状态上，而不是物理删除上，这是点播后台源码和普通 CRUD 项目差别最大的地方。

PlayRecord 是增长最快的表，日活一万的系统一天就可能产生几十万行。建议按 created_at 分表或定期归档，保留最近 90 天热数据，更早的导出后从业务表清理。这样后台统计播放量时查的是汇总表，不拖慢主流程。

3. 用 Django admin 装配点播管理端：从注册模型到批量上下架

后台管理系统如果从头写一套页面，工作量几乎翻倍。Django admin 的价值在于：模型字段已经定义好，注册后列表、编辑、筛选、权限这些基础能力全部自带，运营后台这类内部工具用它最划算。下面把视频管理页从注册到批量操作完整过一遍，这也是理解这套源码时最直观的入口。

3.1 admin 注册与列表展示：list_display 和 list_filter 怎么搭配

# video/admin.py from django.contrib import admin from django.utils import timezone from django.utils.html import format_html from .models import Video, Category @admin.register(Video) class VideoAdmin(admin.ModelAdmin): list_display = ('id', 'title', 'category_name', 'status_colored', 'duration', 'is_free', 'play_count', 'published_at') list_filter = ('status', 'is_free', 'category') search_fields = ('title', 'id') list_select_related = ('category',) list_per_page = 50 date_hierarchy = 'published_at' @admin.display(description='分类') def category_name(self, obj): return obj.category.name @admin.display(description='状态') def status_colored(self, obj): colors = {'published': 'green', 'offline': 'gray', 'pending': 'orange', 'draft': 'red'} return format_html('<span style="color:{}">{}</span>', colors.get(obj.status, 'black'), obj.get_status_display()) @admin.action(description='批量上架') def make_online(self, request, queryset): queryset.update(status='published', published_at=timezone.now()) @admin.action(description='批量下架') def make_offline(self, request, queryset): queryset.update(status='offline') actions = ['make_online', 'make_offline']

list_display 里不要直接写 category，Django 会为每个实例多查一次分类表。这里用 category_name 方法配合 list_select_related，列表页的 SQL 只有一条带 JOIN 的主查询加一条分页查询，运营翻页时才不会卡。status_colored 用 format_html 输出带颜色的状态标签，比纯文本直观得多。

批量操作是后台管理的高频场景：专题活动上线时要一次性上架几十个视频，活动结束再整体下架。上面两个 action 注册进 actions 后，列表页下拉框里就会出现「批量上架」「批量下架」，勾选后一键执行。用 queryset.update 走的是单条 UPDATE 语句，不逐条加载对象，几十万行也能秒级完成。

3.2 三个必调参数：list_select_related、list_per_page、date_hierarchy

刚接触 Django admin 的人最容易漏掉这三个参数，它们直接决定列表页在高数据量下好不好用。

list_select_related 只对单值外键有效，作用是让 ORM 查询主表时用 JOIN 把关联对象一次取出。对应到 Video 到 Category 这种关系直接命中。如果列表页还要显示多对多字段（比如视频标签），就得用 prefetch_related，admin 里需要重写 get_queryset，第 5 章会提到。

list_per_page 默认 100 条，在视频这种行宽很大的列表上体验很差，压到 50 比较合适。它影响分页查询的 LIMIT 值，配合 2.2 节的联合索引，翻页查询基本都能落在几十毫秒内。

date_hierarchy 会在列表页顶部生成一个按日期钻取的筛选条，背后按 published_at 做范围查询。这个参数要求对应字段有索引，没有索引时手滑点一次全表扫描就来了。设置之后，运营按「某天上架」筛选时执行的 SQL 语义清晰，也方便做慢查询分析。

提示：list_editable 可以把字段变成列表页直接编辑，但和批量 action 一起用容易误触保存，运营后台不建议开。

3.3 admin 界面美化与前后端分离的取舍

原生 admin 界面外观朴素，内部工具不需要对外展示时，简单换肤就够。django-simpleui 是常见选择，pip install django-simpleui后把它加到 INSTALLED_APPS 且放在 django.contrib.admin 之前，菜单和按钮会立刻换成现代风格，几乎零配置。django-grappelli 是另一条路，样式更老派但生态更稳，两者按团队审美选一个就行，不要同时启用。

真正需要想清楚的是什么时候放弃 admin 走前后端分离。如果点播系统还要面向 C 端用户提供浏览、搜索、播放页，用户端页面用 Django 模板或 Vue 都行，但管理端继续留在 admin 里，这是成本最低的划分。只有当运营后台需要复杂交互组件，比如拖拽排序、批量上传队列、实时转码进度条时，才值得用 Django REST framework 提供 API、前端单独写管理页面。判断标准是 admin 默认能力能不能覆盖需求，能覆盖就继续用，不要为了技术栈好看给内部工具增加维护成本。django 前后端分离在项目里经常被提起，但对点播后台这种内部系统，分离的收益主要在用户端，不在管理端。

4. 点播播放地址的实现：Range 请求、签名防盗链与转码任务

后台管理把视频管起来了，接下来是点播最核心的一环：播放地址怎么给到用户端。直接返回文件路径的做法在局域网小项目里能用，生产环境必须处理三件事：大文件拖进度条要支持 Range 请求、播放地址要防抓取盗链、不同分辨率要依赖转码任务。这一章按这三个问题逐个落地。

4.1 用 StreamingHttpResponse 接 Range 请求，content_type 与 content-disposition 不能错

浏览器播放 MP4 时，拖进度条会向服务端发 Range 头，格式是Range: bytes=0-1023。如果服务端忽略 Range 直接返回 200 全量文件，播放器只能重新从头缓冲，体验直接崩掉。Django 的 FileResponse 处理小文件没问题，但点播场景通常要自己控制响应头，常见做法是用 StreamingHttpResponse 配合 Range 解析。

import os from django.http import StreamingHttpResponse, Http404 from wsgiref.util import FileWrapper def stream_video(request, video_id): video = get_object_or_404(Video, pk=video_id, status='published') path = video.video_file.path if not os.path.exists(path): raise Http404('视频文件不存在') file_size = os.path.getsize(path) content_type = video.video_file.file.content_type or 'video/mp4' range_header = request.headers.get('Range') if range_header: start, end = parse_range(range_header, file_size) response = StreamingHttpResponse( streaming_content=FileWrapper(open(path, 'rb'), 8192), status=206, content_type=content_type, ) response['Content-Range'] = f'bytes {start}-{end}/{file_size}' response['Content-Length'] = str(end - start + 1) response['Accept-Ranges'] = 'bytes' return response response = StreamingHttpResponse( streaming_content=FileWrapper(open(path, 'rb'), 8192), content_type=content_type, ) response['Content-Length'] = str(file_size) response['Accept-Ranges'] = 'bytes' return response

parse_range 要自己处理三种情况：只有起始位置、带结束位置、非法范围。206 状态码表示部分内容，Content-Range 告诉播放器这一片对应文件的哪个区间。FileWrapper 的第二个参数是分块大小，8192 字节适合本地磁盘读取，走网络存储时可以调大，但块太大挤占内存。

django streaminghttpresponse 的 content_type 和 content-disposition 参数是这里的两个坑。content_type 必须是有效的视频 MIME，写错成 text/plain 时播放器拒绝播放；content-disposition 是 attachment 时浏览器直接下载，所以要显式设为 inline，只有下载接口才用 attachment 加文件名。另外视频文件走 Django 进程读出再返回的效率不高，文件量大时常见做法是 Django 只做鉴权，校验通过后返回一个 X-Accel-Redirect 响应头，把实际文件发送交给静态文件服务处理，这正是 4.2 节签名地址要配合的场景。

注意：Range 解析失败时不要静默返回 200 全量文件，应该回 416，否则播放器会陷入反复请求的循环。

4.2 播放地址加签名：过期时间与 HMAC 校验

一个播放地址如果长期有效，被人分享出去就变成公开资源。签名防盗链的思路是：播放地址带上过期时间戳和签名，服务端校验签名合法且未过期才允许播放。用 HMAC 而不是简单的哈希拼接，因为 HMAC 带密钥，别人无法伪造。

import hashlib import hmac import time from django.conf import settings from django.urls import reverse def sign_play_url(video_id, expire_seconds=3600): expire = int(time.time()) + expire_seconds play_path = reverse('play', args=[video_id]) message = f'{play_path}:{expire}' sign = hmac.new( settings.PLAY_SIGN_KEY.encode('utf-8'), message.encode('utf-8'), hashlib.sha1, ).hexdigest() return f'{play_path}?expire={expire}&sign={sign}'

调用时在视频列表接口里为每个视频生成带签名的播放链接，用户端拿到的是 expire 和 sign 两个参数。服务端校验时用同一个密钥对「路径:过期时间」重新计算签名，再拿hmac.compare_digest和请求带来的签名比对。compare_digest 是关键，它用常数时间比较，避免通过响应时间差破解签名。密钥单独放在 settings 里，不要复用 SECRET_KEY，这样即使泄露一个密钥也不影响 session 加密。

校验通过后，4.1 节的 stream_video 视图正常返回视频流，失败统一返回 403。expire 的粒度到秒即可，常见做法是 30 到 60 分钟，太短导致播放中过期，太长放大盗链风险。配合 X-Accel-Redirect，签名校验和文件发送完全解耦，签名地址只暴露给有权限的用户，静态模块只认接入层传过来的内部地址。

4.3 转码任务：用 Celery 异步跑 FFmpeg

点播后台的必备能力是转码。用户上传的原始视频编码五花八门，直接播放兼容性差，常见流程是上传完成后异步转成 H.264 + AAC 的 MP4。这步不能放在请求里同步执行，几十分钟的片子转码耗时超过任何请求超时时间，要用消息队列异步跑。

# video/tasks.py import os import subprocess from celery import shared_task @shared_task(bind=True, max_retries=3) def transcode_video(self, video_id): video = Video.objects.get(pk=video_id) src_path = video.video_file.path base, ext = os.path.splitext(src_path) target_path = f'{base}_h264.mp4' cmd = [ 'ffmpeg', '-i', src_path, '-c:v', 'libx264', '-preset', 'fast', '-crf', '23', '-c:a', 'aac', '-b:a', '128k', '-movflags', '+faststart', '-y', target_path, ] proc = subprocess.run(cmd, capture_output=True) if proc.returncode != 0: raise self.retry(countdown=60) video.video_file.name = target_path.replace(settings.MEDIA_ROOT, '').lstrip('/') video.status = 'published' video.save(update_fields=['video_file', 'status', 'updated_at'])

参数里 -preset fast 在转码速度和文件大小之间取平衡，-crf 23 是 x264 的默认质量档，数值越小质量越高文件越大。-movflags +faststart 把元数据移到文件头部，让播放器不用等整个文件下载完就能开始播放，这个参数在点播场景几乎是必须的。任务失败时 Celery 按 countdown 重试，重试前把 video 状态留在 pending，转码成功才置为 published，这套状态流转和 2.3 节的状态字段是配套设计的。

5. 上线前用 Django Debug Toolbar 给点播后台做查询审计，热点榜顺手挂上缓存

源码能跑起来只是起点，点播后台真正考验人的是视频量大之后的查询效率。上线前花半天做一次查询审计，比上线后加机器划算得多。这一章给两个具体做法：先用 Debug Toolbar 抓 N+1，再把热点榜和签名地址挂进缓存。

5.1 先抓 N+1：列表页和播放记录是重灾区

安装 django-debug-toolbar 后，在 settings 的 INSTALLED_APPS 里加入，并配置 INTERNAL_IPS 为本机地址。打开后台视频列表页，右侧会出现调试面板，重点看 SQL 面板里的查询条数。正常分页列表应该只有一条主查询加少量辅助查询，如果看到每个视频都带一条 category 查询，那就是 N+1，说明 list_select_related 没生效或模型关系换了写法。

播放记录这类反向外键的场景更隐蔽。后台要展示最近观看记录及其视频标题时，PlayRecord.objects.all()默认不会带出 video，模板里每访问一次record.video.title就多一条查询。修正方式是重写 queryset：

from django.db.models import Prefetch def get_recent_records(user_id, limit=50): return (PlayRecord.objects .filter(user_id=user_id) .select_related('video') .prefetch_related( Prefetch('video__category', to_attr='category_cache') )[:limit])

select_related 负责单值外键 video，Prefetch 把 video 的分类一起缓存到内存，50 条记录从可能的上百条查询压到 3 条以内。审计时如果发现某条 SQL 走了全表扫描，把慢查询日志里的语句拿到数据库里 EXPLAIN 一下，看是否命中 2.2 节建的联合索引，没有命中就按实际查询重新建索引。

5.2 热点榜与签名地址的缓存写法

点播后台的首页通常要展示播放量排行，每次请求都 ORDER BY play_count 全表排序，数据量大时没有必要。用 Django 的缓存框架按固定周期刷新即可：

from django.core.cache import cache HOT_VIDEOS_KEY = 'vod:hot_videos:v1' def get_hot_videos(): hot = cache.get(HOT_VIDEOS_KEY) if hot is None: hot = list( Video.objects.filter(status='published') .order_by('-play_count')[:20] .values('id', 'title', 'duration', 'play_count') ) cache.set(HOT_VIDEOS_KEY, hot, timeout=300) return hot

这个写法把 20 条热点数据整体缓存 5 分钟，key 里带 v1 版本号，以后字段调整时改版本号就能强制刷新。缓存的是 values() 返回的字典列表，直接从内存出数据，不再占数据库连接。签名地址也可以做类似处理，视频源文件不常变更时按 video_id 缓存最近生成的签名串，注意缓存过期时间要比签名有效期短，比如签名有效期 3600 秒时缓存设 3000 秒，两者之间的差值就是安全余量，避免缓存里掏出已经过期的地址。这两个动作做完，播放列表页和后台首页的查询压力基本都能降一个量级。

本文还有配套的精品资源，点击获取