简介基于 Python 语言结合 Django 框架与 Vue.js 前端技术构建了一套完整的视频点播网站毕业设计项目。系统围绕用户认证、视频分类、在线播放与管理等核心功能展开涵盖后端逻辑、前端展示、数据库管理和媒体资源存储等关键环节适合计算机专业毕业生与前后端分离开发初学者参考。压缩包内整理有四百六十二个文件大小约三十点八四兆字节包含四十四个 Python 源码、四十个 Vue 组件、四十九个视频切片、二十四个 MP4 视频以及图片、图标、样式和数据库脚本等资源按 Django 与 Vue 模块划分可直接导入开发工具运行调试。除源码外还附带项目说明文档、后端模型与路由配置备份文件可对照学习数据库表结构与 URL 映射配合界面截图快速定位页面与代码的对应关系降低二次开发成本。目前已有九十四人学习下载项目完整度高适合作为毕业设计或课程设计的参考资料。1. 视频点播网站怎么选型PythonDjangoVue 能撑起一个什么样的点播平台视频点播网站听起来复杂实际上拆分下来就是三件事视频文件怎么存、播放列表怎么出、播放权限怎么控。用 Python Django Vue 这一套组合来做最大好处是后端生态里文件处理、用户认证、数据库操作都是现成的前端 Vue 又正好能把播放器、列表、搜索这些交互做成单页应用开发节奏比从零手写快一倍以上。这套方案在毕业设计和中小型项目里很常见适合需要快速出成果、又不想在基础设施上花太多时间的场景。下面我会从后端接口、前端播放器、联调部署到常见坑位把整个链路讲清楚末尾再给两个能直接抄的进阶做法。2. 后端设计用 Django 把视频上传、存储与播放接口串起来2.1 数据模型设计Video、Category、User 三张表的字段取舍后端最先要落地的就是模型。视频点播的模型并不复杂核心是把视频文件本身和它的业务属性分开。User 直接用 Django 自带的 auth.UserCategory 存分类Video 存视频文件信息和播放属性。这样拆的好处是后面加标签、加评论、加收藏时不需要改动 Video 表本身只要在它周围加外键就行。一个常见的模型写法如下from django.db import models from django.contrib.auth.models import User class Category(models.Model): name models.CharField(max_length50, uniqueTrue) sort models.IntegerField(default0, help_text排序权重越小越靠前) created_at models.DateTimeField(auto_now_addTrue) class Meta: ordering [sort, -id] verbose_name 视频分类 def __str__(self): return self.name class Video(models.Model): title models.CharField(max_length200, verbose_name视频标题) category models.ForeignKey( Category, on_deletemodels.SET_NULL, nullTrue, blankTrue, related_namevideos ) video_file models.FileField(upload_tovideos/%Y/%m/, verbose_name视频文件) cover_image models.ImageField(upload_tocovers/%Y/%m/, blankTrue, verbose_name封面图) duration models.IntegerField(default0, verbose_name时长(秒)) uploader models.ForeignKey(User, on_deletemodels.CASCADE, related_namevideos) play_count models.IntegerField(default0, verbose_name播放次数) is_published models.BooleanField(defaultFalse, verbose_name是否上架) created_at models.DateTimeField(auto_now_addTrue) updated_at models.DateTimeField(auto_nowTrue) class Meta: ordering [-created_at] verbose_name 视频 def __str__(self): return self.title这里几个选择值得说。category 外键用 on_deletemodels.SET_NULL 而不是 CASCADE是因为视频分类被删掉时视频记录不应该跟着消失否则会误删大量内容。upload_to 里的 %Y/%m 表示按年月归档Django 会自动创建目录这样一年后的视频文件不会全部堆在同一个文件夹管理端和服务器备份都好做。duration 字段我建议存整数秒而不是字符串格式的“00:12:34”因为秒数在后端做排序、统计、推荐时都更直接获取时长可以在上传后由前端读取视频元数据回填也可以在服务端用 ffprobe 解析毕业设计阶段前端回填就够用。is_published 这个布尔字段很多人会忽略但它直接决定了“上传中”和“已上架”的边界。视频刚上传还没转码、没填封面时不应该出现在列表里这个字段就是干这个用的。play_count 用 IntegerField 存一个计数器就够了别图省事用 CharField 拼接字符串后面做统计报表会非常难受。如果有心做得更完整还可以加 status 字段表示“上传中/转码中/已就绪”但首次跑通前先用 is_published 顶住即可。2.2 上传接口DRF 的序列化器、权限与文件存储配置视图层我一般直接用 Django REST FrameworkDRF它把序列化、权限、分页都封装好了写起来比纯 Django 视图快很多。上传接口用 ListCreateAPIView 就可以同时覆盖“获取视频列表”和“上传新视频”两个动作。# serializers.py from rest_framework import serializers from .models import Video class VideoSerializer(serializers.ModelSerializer): category_name serializers.CharField(sourcecategory.name, read_onlyTrue) uploader_name serializers.CharField(sourceuploader.username, read_onlyTrue) class Meta: model Video fields [ id, title, category, category_name, video_file, cover_image, duration, play_count, is_published, created_at ] read_only_fields [duration, play_count] # views.py from rest_framework import generics, permissions from .models import Video from .serializers import VideoSerializer class VideoListCreateView(generics.ListCreateAPIView): queryset Video.objects.filter(is_publishedTrue) serializer_class VideoSerializer def get_permissions(self): if self.request.method POST: return [permissions.IsAuthenticated()] return [permissions.AllowAny()] def perform_create(self, serializer): serializer.save(uploaderself.request.user)重点在权限分配。GET 接口任何人可访问POST 接口必须登录这样视频列表可以公开上传动作却不会给匿名用户留口子。需要说明的是DRF 的 FileField 在接收入站文件后默认把文件存到 MEDIA_ROOT 下MEDIA_ROOT 和 MEDIA_URL 必须在 settings.py 里显式配置否则上传接口会报 ImproperlyConfigured# settings.py MEDIA_URL /media/ MEDIA_ROOT BASE_DIR / media文件路径的规则是最终存储路径是 MEDIA_ROOT upload_to 的组合比如 MEDIA_ROOT/opt/vod/backend/mediaupload_tovideos/2025/06/那么文件实际落在 /opt/vod/backend/media/videos/2025/06/ 下。URL 访问路径则是 MEDIA_URL 同样的相对路径即 /media/videos/2025/06/filename.mp4。这两个配置一对不上部署阶段就会出现“接口能上传但视频播放 404”的问题后面避坑章节还会再提。2.3 播放接口动静分离还是后端转流视频播放的接口设计有两条路动静分离和后端转流。动静分离是生产环境最常见的做法。视频文件上传后直接落盘在服务器某个目录Nginx 把这个目录暴露成 /media/ 静态路径前端 video 标签直接拉取 /media/videos/xxx.mp4。Django 完全不出场视频流量不经过 Python 进程性能最好部署也简单。缺点是只要有人拿到完整 URL就能绕过前端直接下载文件适合公开视频或内部系统。后端转流则是让 Django 先做权限校验再流式吐出视频数据前端播放器拿到的地址不是真实文件路径每次播放都走一遍接口校验。缺点是对服务器带宽和 Python 吞吐有要求并发稍大就容易拖垮应用进程。折中做法是 Django 校验后返回临时签名 URL再配合 Nginx secure_link 做时间窗口保护这个放在最后一章细讲。如果要做纯后端转流代码可以这样写import os from django.http import StreamingHttpResponse, HttpResponse from django.shortcuts import get_object_or_404 from .models import Video def file_iterator(file_path, offset, length): with open(file_path, rb) as f: f.seek(offset) remaining length while remaining 0: chunk f.read(min(8192, remaining)) if not chunk: break remaining - len(chunk) yield chunk def stream_video(request, video_id): video get_object_or_404(Video, idvideo_id, is_publishedTrue) file_path video.video_file.path file_size os.path.getsize(file_path) range_header request.META.get(HTTP_RANGE, ) start, end 0, file_size - 1 status_code 200 if range_header: try: range_str range_header.split()[1] start_str, _, end_str range_str.partition(-) start int(start_str) if start_str else 0 end int(end_str) if end_str else file_size - 1 end min(end, file_size - 1) if start file_size: return HttpResponse(status416) status_code 206 except (IndexError, ValueError): return HttpResponse(status400) response StreamingHttpResponse( file_iterator(file_path, start, end - start 1), statusstatus_code, content_typevideo/mp4 ) response[Accept-Ranges] bytes if status_code 206: response[Content-Range] fbytes {start}-{end}/{file_size} return response核心逻辑是处理 Range 请求头。播放器拖动进度条时浏览器会带上 Range: bytesstart-end 去请求视频片段后端必须返回 206 状态码和 Content-Range 头播放器才能正确跳转。如果后端不解析 Range每次都返回完整文件播放器会表现为“能放但拖不动进度条”或者一拖就从头开始。chunk_size 用 8192 字节是出于内存和磁盘 IO 的平衡实际项目里可以调到 64KB 或 128KB但调大后要留意单连接占用的内存。3. 前端实现Vue 播放器集成与点播页面的数据流3.1 页面结构与路由列表页、详情页、管理页的数据流前端用 Vue 3 Vite 起步页面结构一般拆成三块视频列表页、视频详情页、管理上传页。列表页负责分类筛选和视频卡片详情页嵌入播放器和视频信息管理页供登录用户上传新视频。路由写在 /src/router/index.jsimport { createRouter, createWebHistory } from vue-router const routes [ { path: /, name: home, component: () import(../views/HomeView.vue) }, { path: /video/:id, name: video-detail, component: () import(../views/VideoDetailView.vue) }, { path: /upload, name: video-upload, component: () import(../views/UploadView.vue) }, ] const router createRouter({ history: createWebHistory(), routes }) router.beforeEach((to, from, next) { if (to.meta.requiresAuth !localStorage.getItem(token)) { next({ path: /login }) return } next() }) export default router列表页的关键点是数据懒加载和分类筛选。我常用一个 watch 监听当前分类 id 的变化变化时重新请求 /api/videos/?categoryxx分页用 DRF 的 PageNumberPagination 返回的 next 字段判断是否还有下一页// HomeView.vue 分页加载片段 const videos ref([]) const nextPage ref(null) const loading ref(false) async function loadVideos() { if (loading.value) return loading.value true const res await request.get(/api/videos/, { params: { page_size: 12 } }) videos.value.push(...res.results) nextPage.value res.next loading.value false }这样列表接口一次只返回一页数据避免一次性拉全量视频卡死页面。page_size 参数在 DRF 后端通过 PageNumberPagination.page_size_query_param 接收前端传多少都行但要设个最大值比如 50防止有人传 10000 把后端打趴下。详情页要处理的是两个参数路由 id 和视频对象。播放器组件接收 video 对象后从 video.video_file 字段拼出播放地址。注意不要直接用 video.video_file 当播放 src因为 Django 返回的 FileField URL 是相对路径需要在前面拼上 API 的 baseURL或者在后端序列化时直接返回绝对 URL。3.2 播放器组件原生 video 标签的参数细节播放器层面核心是原生 video 标签。点播场景如果不需要直播、加密、倍速记忆这些额外功能原生 video 配合 controls 属性就已经够用不需要额外引播放器库。组件写法如下template div classplayer-wrapper video refvideoRef controls preloadmetadata :srcstreamUrl timeupdateonTimeUpdate endedonEnded /video /div /template script setup import { ref, computed, onBeforeUnmount } from vue const props defineProps({ video: { type: Object, required: true } }) const videoRef ref(null) const currentTime ref(0) const streamUrl computed(() { const base import.meta.env.VITE_API_BASE || http://localhost:8000 return ${base}/api/videos/${props.video.id}/stream/ }) function onTimeUpdate() { currentTime.value videoRef.value.currentTime } function onEnded() { // 播放结束事件可以用来触发“猜你喜欢”推荐 } onBeforeUnmount(() { videoRef.value null }) /scriptpreloadmetadata 这个参数值得专门说。它告诉浏览器只预加载视频的元数据时长、分辨率等不要预下载整个视频文件。点播页面往往首屏有很多卡片如果每个视频都 preloadauto页面会同时发起大量请求带宽直接被打满。metadata 模式既能拿到时长显示在卡片角标上又不会拖累整个页面的加载速度。如果确实需要统一皮肤、倍速菜单、清晰度切换再考虑 video.js 或 DPlayer。我一般把播放器框架的选型留到主流程跑通之后再定不在一开始就引入否则调试时很难区分是播放器的问题还是后端流接口的问题。切换播放器时只要把 video 标签替换成对应组件src 仍然指向同一个流地址后端不用做任何改动。3.3 axios 封装与接口兜底token 头、超时与 401 跳转前端调接口的核心是 axios 封装。统一封装 baseURL、超时时间和鉴权头避免每个页面重复写 token 逻辑// src/api/request.js import axios from axios const request axios.create({ baseURL: import.meta.env.VITE_API_BASE || http://localhost:8000, timeout: 15000 }) request.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers.Authorization Bearer ${token} } return config }) request.interceptors.response.use( response response.data, error { if (error.response error.response.status 401) { localStorage.removeItem(token) window.location.href /login } return Promise.reject(error) } ) export default request封装之后业务页面只要写 request.get(/api/videos/) 就行不必关心 token 怎么挂载、401 怎么跳登录。需要提醒的是超时时间。视频列表接口一般很快但上传接口不一样大文件上传耗时可能超过一分钟因此上传的请求建议单独建一个上传实例把 timeout 设为 0 或很大不要复用默认的 15 秒超时否则传一个 200MB 的文件大概率中途超时。另外response 拦截器里我习惯直接返回 response.data这样业务代码拿到的就是接口体本身不需要每次解一层壳。4. 联调与部署从本地开发服务器到 Nginx 上线的完整链路4.1 本地联调dev server 代理与 Django CORS 配置本地开发时 Vue 跑在 5173 端口Django 跑在 8000 端口浏览器直接跨域。解决方式有两个开 CORS 或在 Vite 里配代理。我一般两边都做CORS 用来支持后续可能接入的移动端代理则让前端代码里能用相对路径请求。Vite 的代理配置在 vite.config.js 里// vite.config.js import { defineConfig } from vite import vue from vitejs/plugin-vue export default defineConfig({ plugins: [vue()], server: { port: 5173, proxy: { /api: { target: http://127.0.0.1:8000, changeOrigin: true }, /media: { target: http://127.0.0.1:8000, changeOrigin: true } } } })配完代理后前端请求 /api/videos/ 会被 Vite 转发到 Django视频地址 /media/videos/xx.mp4 也由代理转发。这样浏览器里没有跨域开发体验最顺。注意 /media 这个代理路径很容易被漏掉列表页正常但点进视频页黑屏多半就是视频请求没被代理到 Django。Django 端的 CORS 配置对应如下# settings.py INSTALLED_APPS [ # ... corsheaders, rest_framework, ] MIDDLEWARE [ corsheaders.middleware.CorsMiddleware, # ... ] CORS_ALLOWED_ORIGINS [ http://localhost:5173, http://127.0.0.1:5173, ]CorsMiddleware 的位置有讲究文档建议放在所有中间件最前面也就是尽可能靠上。如果放在其他中间件后面某些场景下请求会被前面的中间件拦截CORS 响应头还没加上去就已经报错了。改完配置要重启 Django光保存文件是不会自动生效的。4.2 生产部署Nginx 托管前端、接口与视频文件的三个 location本地跑通后部署阶段我习惯用 Nginx 一台服务器全托管前端静态文件、Django 接口、视频文件分别用三个 location 处理。server { listen 80; server_name videodemo.example.com; client_max_body_size 2g; location / { root /opt/vod/frontend/dist; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_read_timeout 60s; } location /media/ { alias /opt/vod/backend/media/; add_header Cache-Control public, max-age86400; } location /admin/ { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; } }前端 location / 的 try_files 是关键它把前端路由的 history 模式兜底到 index.html。如果缺了这一行刷新详情页 /video/3 时 Nginx 会直接 404。视频文件的 location /media/ 用 alias 而不是 root是因为 alias 是把请求路径替换到文件目录root 则会在目录后拼接完整路径配错就会出现 /media/media/videos/ 这种重复路径。client_max_body_size 2g 是给大视频上传准备的默认值只有 1MB不调大上传必然失败。后端进程用 gunicorn 跑起来即可pip install gunicorn cd /opt/vod/backend gunicorn vod_project.wsgi:application --bind 127.0.0.1:8000 --workers 3 --timeout 120workers 数量一般按 CPU 核心数 × 2 1 估算不要盲目调大。视频点播的接口主要是 IO 密集worker 太多反而会因为内存不够被系统 OOM 杀掉。4.3 数据初始化超级用户、分类与演示视频的准备部署完第一件事不是上传视频而是初始化数据。按下面顺序做python manage.py makemigrations python manage.py migrate python manage.py createsuperusermigrate 之前如果已经有旧的数据库文件建议先备份不要上来就 migrate数据库结构对不上会报一堆字段缺失。createsuperuser 之后可以进入 Django admin 后台把几个分类先建好再上传第一批视频。分类数据也可以用 fixture 预先准备建一个 categories.json 放在 fixtures/ 目录下然后执行 python manage.py loaddata categories.json 一次性导入。这样重装环境时不用手动点后台适合后面写部署脚本时用。演示视频我一般会在服务器上放两三段短视频测试覆盖不同分辨率方便验证封面、拖动、倍速播放是否正常。5. 避坑篇视频点播系统最常见的 5 个翻车现场5.1 上传 413Nginx 默认只允许 1MB 请求体现象前端上传一个几十 MB 的视频文件请求发出后没多久就报 413 Request Entity Too Large有的浏览器直接显示“连接被重置”。原因Nginx 的 client_max_body_size 默认值是 1MB超出这个大小的请求体在 Nginx 层就被拦掉了根本到不了 Django。Django 也有自己的限制DATA_UPLOAD_MAX_MEMORY_SIZE 默认 2.5MB超过这个值的请求体会被 Django 拒绝所以就算 Nginx 放行了Django 也有可能拦截。解决Nginx 的 server 块或 location 里加 client_max_body_size 2gDjango 这边在 settings.py 中调大 DATA_UPLOAD_MAX_MEMORY_SIZE 和 FILE_UPLOAD_MAX_MEMORY_SIZE。前者控制小请求体的内存缓冲阈值后者控制上传文件暂存到内存的最大值超过就会落临时文件。改完后记得重启 Nginx 和 DjangoNginx 的配置修改需要 reload 才会生效。5.2 拖动进度条失效Range 请求没被正确响应现象视频能正常播放但鼠标一点播放器进度条画面立刻回到开头或者一直转圈加载。原因前端 video 标签拖动进度条时浏览器会向服务器发一个带 Range: bytes... 的请求。如果后端没有解析这个头而是返回了 200 和整个文件浏览器无法定位到指定字节位置就表现为拖不动。用 curl 验证最直观curl -I -H Range: bytes0-1023 http://127.0.0.1:8000/api/videos/1/stream/正常响应应该是 206 状态码同时带 Content-Range: bytes 0-1023/文件总大小。如果你看到 200说明后端没有处理 Range。解决如果是后端转流方案按 2.3 节的代码实现 Range 解析如果走动静分离把视频目录交给 Nginx alias 托管Nginx 自己会处理 Range 请求不需要写业务代码。排查的时候优先确认到底是 Nginx 还是 Django 在响应视频请求路径不同排查方向完全不同。5.3 跨域报错CORS 中间件没放在正确位置现象本地联调时Vue 页面用 axios 请求 Django 接口浏览器控制台报 “has been blocked by CORS policy” 这类错误。原因最直接的原因是 Django 没有返回 CORS 响应头。实际检查下来多半是 CorsMiddleware 在 MIDDLEWARE 列表中的位置不对或者 CORS_ALLOWED_ORIGINS 里的端口号和前端 dev server 不一致。还有一种是浏览器缓存了旧的 CORS 响应改了配置后强刷才能生效。解决先确认 MIDDLEWARE 数组里 corsheaders.middleware.CorsMiddleware 放在尽可能靠前的位置。再检查 CORS_ALLOWED_ORIGINS 里写的是 http://localhost:5173 而不是带斜杠的写法斜杠结尾不会被正确识别。最后用 curl -H Origin: http://localhost:5173 -I 请求接口看响应头里有没有 access-control-allow-origin 字段没有就说明配置没生效重启 Django 之后再看。5.4 视频文件 404MEDIA_ROOT 和 Nginx alias 没对齐现象列表页面能打开点击视频后播放器黑屏浏览器控制台显示 404URL 是 /media/videos/xxx.mp4。检查服务器上文件确实存在。原因最常见的是 MEDIA_URL 和 Nginx 的 alias 路径不一致。比如 Django 里 MEDIA_URL/media/MEDIA_ROOT/opt/vod/backend/media/那 Nginx alias 就必须指向 /opt/vod/backend/media/。如果写成了 root /opt/vod/backend/media/实际请求路径会变成 /opt/vod/backend/media/media/videos/xxx.mp4文件自然找不到。解决在服务器上用 curl -I 直接请求视频 URL看返回的 404 是来自 Django 还是 Nginx。响应头里有 Server: nginx 的是 Nginx 拦的有 WSGIServer 或 gunicorn 的是后端返回的。Nginx 的问题就改 alias 或 root后端的问题就去查 MEDIA_ROOT 和 urls.py 里的静态文件路由配置。改完配置后执行 nginx -s reload这个命令不会中断现有连接生产环境也比较安全。5.5 部署后 502 Bad Gatewaygunicorn 挂了还是路径配错了现象网页能打开静态资源正常但所有接口请求返回 502 Bad Gateway。原因502 说明 Nginx 连不上后端进程。常见原因有三类gunicorn 没启动gunicorn 绑定地址和 Nginx 的 proxy_pass 不一致或者数据库连接池满了gunicorn 响应超时被 Nginx 判定为失败。解决先用 curl -I http://127.0.0.1:8000/api/videos/ 直接测试后端是否存活。能通就检查 Nginx 的 proxy_pass 是否写成了 http://127.0.0.1:8000/ 这种带斜杠的写法斜杠会导致路径拼接差异。不能通就看 gunicorn 日志最常见的坑是项目路径下忘记激活虚拟环境gunicorn 找不到 wsgi 模块。数据库连接池的问题把 gunicorn 的 --timeout 调大到 120 秒同时检查数据库 max_connections 是否被并发数打满。6. 进阶播放地址防盗链与播放量统计的落地姿势把视频路径直接暴露在静态目录里始终不安全。我常做的进阶方案是签名 URL用户通过接口申请播放地址Django 校验权限后用密钥生成带过期时间的签名播放器拿到签名后的地址再去拉流。过期后立即失效即使 URL 被复制出去别人也只能在有效期内访问有效时长默认设为 5 分钟。import hmac import hashlib import time def generate_stream_url(video_id): timestamp int(time.time()) 300 raw f{video_id}:{timestamp} token hmac.new( settings.VIDEO_TOKEN_KEY.encode(), raw.encode(), hashlib.sha256 ).hexdigest() return f/api/videos/{video_id}/stream/?expires{timestamp}sign{token}流接口在响应前先校验 expires 和 sign 是否匹配且未过期再决定是否继续输出视频流。注意签名用的密钥不要和 SECRET_KEY 混用单独配一个 VIDEO_TOKEN_KEY防止密钥泄露后牵扯其他业务。同时务必在 Nginx 层把 /media/ 目录的对外访问限掉否则签名就形同虚设别人直接访问原始路径还是一样能下载。播放量统计是另一个容易忽略的地方。别在详情接口里每次访问都执行一次数据库累加高并发下行锁竞争会很激烈。我更习惯的做法是播放器真正进入播放状态后由前端向一个独立的播放上报接口发请求后端把计数写进缓存或消息队列再批量合并到数据库。配合 Django 信号按天归档播放事件后续做“热播榜”时就有了数据源不用再回头导出流量日志重新统计。写视频点播系统最怕的就是“先能跑然后被安全和性能问题逼着重写”。我做了几个视频类小项目之后保留下来最值钱的两条习惯就是先签名后放流、计数与查询分离。这两件事放在项目初期做代价很小放到末期补成本翻倍。希望帮到你。本文还有配套的精品资源点击获取