简介一份基于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 表是后台管理的中心字段设计要同时满足运营展示和播放鉴权两个目的。下面是一版在真实项目中能直接落地的字段划分字段类型用途备注titleCharField(200)视频标题加 db_index后台搜索靠它categoryFK(Category)所属分类用 PROTECT防止误删分类带走视频coverImageField封面图上传路径按年月分目录video_fileFileField源文件与媒体服务约定路径格式durationPositiveIntegerField时长秒存整数不存 00:12:34 字符串statusCharField(16)草稿/待审/上架/下架见 2.3is_freeBooleanField是否免费付费点播时的开关play_countPositiveBigIntegerField播放量防止 21 亿次后溢出分类用自关联外键做树形结构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_APPSDATABASES 按实际库名和账号改好再执行后两条命令生成迁移文件并建表。把模型写进video/models.py后迁移文件是源码的一部分不要扔进 .gitignore。团队协作时另一个环境只需要python manage.py migrate就能把表结构追平。字段后续变更一律走 makemigrations直接改表是后面排查问题时最麻烦的历史遗留。class Meta: ordering [-created_at] indexes [ models.Index(fields[status, published_at]), ]这个 Meta 里的联合索引对应后台列表页最常见的筛选组合按状态过滤、按上架时间排序。索引字段顺序要和查询条件对齐状态在前、时间在后走索引时过滤和排序一次完成视频量到十万级时效果比单字段索引明显。2.3 状态字段当软删除用下架不删文件播放记录按月归档后台管理界面里永远不要提供太直接的「删除」按钮。视频文件动辄几百 MBDjango 的 ORM 删除记录不会同时删掉磁盘文件记录删了文件还在就成了孤儿文件日积月累占满存储。常见做法是把删除区分成两种语义下架等于软删除状态置为 offline列表页默认过滤掉彻底删除则由一个 management command 定期扫描回收站确认到期后先删文件再删记录。Video.objects.filter(statusoffline).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 stylecolor:{}{}/span, colors.get(obj.status, black), obj.get_status_display()) admin.action(description批量上架) def make_online(self, request, queryset): queryset.update(statuspublished, published_attimezone.now()) admin.action(description批量下架) def make_offline(self, request, queryset): queryset.update(statusoffline) actions [make_online, make_offline]list_display 里不要直接写 categoryDjango 会为每个实例多查一次分类表。这里用 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单值外键 JOIN 预取列表需要显示分类名等关联字段list_per_page控制每页条数行宽大、字段多的视频列表date_hierarchy按日期钻取筛选published_at 有索引时使用list_select_related 只对单值外键有效作用是让 ORM 查询主表时用 JOIN 把关联对象一次取出。对应到 Video 到 Category 这种关系直接命中。如果列表页还要显示多对多字段比如视频标签就得用 prefetch_relatedadmin 里需要重写 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: bytes0-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, pkvideo_id, statuspublished) 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_contentFileWrapper(open(path, rb), 8192), status206, content_typecontent_type, ) response[Content-Range] fbytes {start}-{end}/{file_size} response[Content-Length] str(end - start 1) response[Accept-Ranges] bytes return response response StreamingHttpResponse( streaming_contentFileWrapper(open(path, rb), 8192), content_typecontent_type, ) response[Content-Length] str(file_size) response[Accept-Ranges] bytes return responseparse_range 要自己处理三种情况只有起始位置、带结束位置、非法范围。206 状态码表示部分内容Content-Range 告诉播放器这一片对应文件的哪个区间。FileWrapper 的第二个参数是分块大小8192 字节适合本地磁盘读取走网络存储时可以调大但块太大挤占内存。Range 头处理状态码bytes0-从 0 到文件末尾206bytes100-199指定区间206非法区间返回 416416django 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_seconds3600): 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(bindTrue, max_retries3) def transcode_video(self, video_id): video Video.objects.get(pkvideo_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_outputTrue) if proc.returncode ! 0: raise self.retry(countdown60) 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 抓 N1再把热点榜和签名地址挂进缓存。5.1 先抓 N1列表页和播放记录是重灾区安装 django-debug-toolbar 后在 settings 的 INSTALLED_APPS 里加入并配置 INTERNAL_IPS 为本机地址。打开后台视频列表页右侧会出现调试面板重点看 SQL 面板里的查询条数。正常分页列表应该只有一条主查询加少量辅助查询如果看到每个视频都带一条 category 查询那就是 N1说明 list_select_related 没生效或模型关系换了写法。播放记录这类反向外键的场景更隐蔽。后台要展示最近观看记录及其视频标题时PlayRecord.objects.all()默认不会带出 video模板里每访问一次record.video.title就多一条查询。修正方式是重写 querysetfrom django.db.models import Prefetch def get_recent_records(user_id, limit50): return (PlayRecord.objects .filter(user_iduser_id) .select_related(video) .prefetch_related( Prefetch(video__category, to_attrcategory_cache) )[:limit])select_related 负责单值外键 videoPrefetch 把 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(statuspublished) .order_by(-play_count)[:20] .values(id, title, duration, play_count) ) cache.set(HOT_VIDEOS_KEY, hot, timeout300) return hot这个写法把 20 条热点数据整体缓存 5 分钟key 里带 v1 版本号以后字段调整时改版本号就能强制刷新。缓存的是 values() 返回的字典列表直接从内存出数据不再占数据库连接。签名地址也可以做类似处理视频源文件不常变更时按 video_id 缓存最近生成的签名串注意缓存过期时间要比签名有效期短比如签名有效期 3600 秒时缓存设 3000 秒两者之间的差值就是安全余量避免缓存里掏出已经过期的地址。这两个动作做完播放列表页和后台首页的查询压力基本都能降一个量级。本文还有配套的精品资源点击获取