基于Python Flask的视频点播系统：核心原理与完整实践

简介：视频点播系统是Web开发中的经典实战项目，其背后涉及HTTP协议、流式传输、前后端交互等多个基础技术。理解视频播放的核心原理，关键在于服务器如何处理Range请求，从而实现按需分段传输数据，避免一次性加载大文件造成的性能瓶颈。无论你是学习Web开发还是准备毕业设计，掌握这种基于HTTP协议的文件传输机制都具有实际意义。在实际工程中，常见的技术选型包括用Python生态的轻量级框架Flask搭建后端，配合SQLite存储元数据，前端通过HTML5 video播放视频。本文以构建一个完整的视频点播系统为例，详细展示了从数据库设计、用户认证、视频上传到后台管理的全过程，并针对视频拖拽播放、文件安全存储等典型问题给出可复用的解决方案。 去年做毕设的时候，宿舍群里天天有人问“有没有现成的视频网站源码”，我一开始也想着直接下个模板改改就交上去，但后来发现查重、答辩、演示这一连串流程走下来，光靠拼凑根本撑不住。于是干脆自己从零撸了一个基于Python的视频点播系统，前后花了大概一个月，答辩的时候效果意外地好。今天就把这个项目的完整思路、代码实现、踩坑过程都写下来，给正在做类似选题的朋友一个参考。

这个项目本质上是一个带用户体系、视频上传、分类浏览、在线播放、后台管理的完整Web应用。技术栈选的是Python生态里最适合作业原型的一套：Flask作为Web框架、SQLite做数据库、Bootstrap搭前端，视频播放直接用HTML5的video标签配合服务端的Range分段加载。整套东西不复杂，但麻雀虽小五脏俱全，非常适合用来展示一个毕业生对Web开发、数据库设计、文件I/O处理和网络安全基础的综合掌握程度。如果你正在纠结毕设选题，或者刚拿到“视频点播网站”这个题目不知道该从哪里下手，这篇文章可以直接当操作手册来用。

1. 项目立项与技术选型：为什么用Python做视频点播

1.1 毕设选题的取舍：先问自己三个问题

选“视频点播网站”这个题目的同学，估计都经历过一轮心理斗争。表面上看这个选题很常规，甚至有点烂大街，但换个角度想，正因为常规，你能找到的参考资料最多，踩坑经验也最丰富，反而容易做出完整度高的作品。我当初定这个题目之前，先问了自己三个问题：第一，这个系统能不能清楚展示出“前端展示 + 后端逻辑 + 数据库管理”的完整链路；第二，我用Python技术栈能不能在短时间内把核心功能做出来；第三，有没有办法在答辩现场稳定演示，不会因为网络或环境问题翻车。

这三个问题答案都是肯定的，所以我就定了这个方向。这里给学弟学妹一个建议：毕设不是越炫越好，而是越“稳”越好。视频点播系统的核心功能就那么几块——用户登录注册、视频列表与分类、视频上传、视频播放、后台管理，每一块都能对应到一门课程里学过的知识点，答辩时评委问起来你能讲清楚“为什么这么设计”，远比堆一个花里胡哨但你自己都说不明白的系统要强。

1.2 技术栈敲定：Flask + Bootstrap + SQLite + HTML5 video

技术选型这件事，很多同学容易走极端，要么用大而全的Django，要么直接上前后端分离的Vue + Spring Boot，结果做了两个星期还在搭环境。我个人的建议是，除非你对Django已经非常熟悉，否则毕设这种场景用Flask反而是最优解。Flask足够轻量，一个主文件加几个蓝图就能组织起整个后端，学习曲线平缓，遇到问题自己读源码也能定位。数据库我选了SQLite，因为毕设系统根本不会有高并发，没必要专门装MySQL，SQLite单文件零配置，拷贝到任何机器都能跑，答辩演示前换电脑也不用重新配。

前端这块，我没有写复杂的JavaScript框架，而是用了Bootstrap 5配合少量原生JS。理由很简单：视频点播网站的主要交互是“点视频、弹播放器”，Bootstrap的网格系统和卡片组件可以快速搭出像样的页面，而HTML5的video标签天然支持MP4格式播放，配合服务端的Range请求支持，就可以实现进度拖拽。如果你非要用Vue全家桶，那增加的Node.js构建、跨域请求处理等工作量，会让整个项目复杂一个量级，而且很容易在答辩时暴露短板。

1.3 视频点播的核心：其实就是一个Range请求

很多第一次做视频项目的同学，会以为“点播”这个功能很玄学。实际上，浏览器里的video标签在播放视频时，会向后端发一个带着Range头的HTTP请求，这表示“我只想拿这个文件从某个字节开始的这一段”。后端只要正确解析这个Range头，返回对应字节区间的内容，视频就能实现进度条拖拽、快进快退。如果你不做这一步，直接把整个视频文件一次性下发，那么第一，加载慢得离谱，第二，进度条根本拖不动。

理解了这一点，整个项目的技术难度就降下来了。你不需要什么流媒体服务器，不需要Nginx切片，只需要让Flask在处理视频文件请求的时候，正确地支持HTTP 206 Partial Content状态码就行。后面我在第三节会给出完整的代码实现。

1.4 目录结构设计：提前想好文件怎么放

我见过不少同学，写了两个星期的代码，所有文件还堆在同一个文件夹里，最后系统能跑起来都算幸运，更别说答辩时要给评委讲清模块划分。我这次一开始就规划好了目录，用Flask的蓝图模块化来组织代码，最终结构是下面这样：

video_system/ ├── app.py # 程序入口 ├── config.py # 配置文件 ├── requirements.txt # 依赖清单 ├── models.py # 数据库模型 ├── extensions.py # db、login_manager等扩展实例 ├── blueprints/ │ ├── __init__.py │ ├── auth.py # 注册/登录/登出 │ ├── video.py # 视频列表/详情/上传/播放 │ ├── comment.py # 评论相关 │ └── admin.py # 后台管理 ├── utils/ │ ├── __init__.py │ ├── file_utils.py # 文件处理工具 │ ├── video_utils.py # 视频时长、封面处理 │ └── decorators.py # 登录装饰器、管理员装饰器 ├── templates/ │ ├── base.html │ ├── index.html │ ├── login.html │ ├── register.html │ ├── upload.html │ ├── video_detail.html │ └── admin/ │ ├── dashboard.html │ ├── video_list.html │ └── user_list.html ├── static/ │ ├── css/ │ ├── js/ │ └── uploads/ # 上传的视频文件和封面图片 └── uploads/ # 上传目录（与static分开更安全）

把上传目录放在static之外，是一个安全考虑。因为如果视频文件直接放在静态目录下，别人可以直接通过URL访问，绕过权限控制；放在static外面，必须经过我们的路由才能读取，方便后面做权限判断。

2. 数据库设计与核心数据流：前端界面背后的逻辑

2.1 需求拆解：从用户视角倒推功能清单

拿到题目之后，第一步不是编码，而是先把系统要服务的用户角色列出来。视频点播网站的用户分为两类：普通用户和管理员。普通用户想要的是注册登录、浏览视频列表、按分类筛选、播放视频、给视频写评论、收藏喜欢的视频；管理员想要的则是查看系统数据统计、审核和删除视频、管理用户状态、处理不当评论。

把这两类需求一列，功能模块就自动浮出水面了。我建了一个Excel表格，把每个角色能做什么、对应到哪个页面、需要哪些数据字段全部写清楚，然后才开始设计数据库。这一步千万别省，它能为你省下后面至少一周的改表时间。很多同学一条路写到黑，最后发现支付模块做不了，就是因为一开始没想清楚需求边界。

2.2 数据表设计：五张表搞定大部分功能

视频点播系统的数据模型其实非常经典，就是教科书级别的范式设计。我总共设计了五张核心表，外加一张管理员表。用户表存账号密码和基本信息，视频表存文件路径、标题、描述、分类、上传时间，分类表存视频类别，评论表关联用户和视频，收藏表做用户和视频的多对多关系。我用Flask-SQLAlchemy来定义模型，代码长这样：

# models.py from datetime import datetime from werkzeug.security import generate_password_hash, check_password_hash from .extensions import db class User(db.Model): __tablename__ = 'users' id = db.Column(db.Integer, primary_key=True) username = db.Column(db.String(64), unique=True, nullable=False, index=True) email = db.Column(db.String(120), unique=True, nullable=False) password_hash = db.Column(db.String(128)) avatar = db.Column(db.String(256), default='default.jpg') is_admin = db.Column(db.Boolean, default=False) created_at = db.Column(db.DateTime, default=datetime.now) def set_password(self, password): self.password_hash = generate_password_hash(password) def check_password(self, password): return check_password_hash(self.password_hash, password) class Category(db.Model): __tablename__ = 'categories' id = db.Column(db.Integer, primary_key=True) name = db.Column(db.String(64), unique=True, nullable=False) slug = db.Column(db.String(64), unique=True, nullable=False) videos = db.relationship('Video', backref='category') class Video(db.Model): __tablename__ = 'videos' id = db.Column(db.Integer, primary_key=True) title = db.Column(db.String(200), nullable=False) description = db.Column(db.Text) file_path = db.Column(db.String(256), nullable=False) cover_path = db.Column(db.String(256)) duration = db.Column(db.Integer, default=0) # 秒 play_count = db.Column(db.Integer, default=0) status = db.Column(db.Integer, default=1) # 1=正常 0=下架 category_id = db.Column(db.Integer, db.ForeignKey('categories.id')) user_id = db.Column(db.Integer, db.ForeignKey('users.id')) created_at = db.Column(db.DateTime, default=datetime.now) uploader = db.relationship('User', backref='videos') comments = db.relationship('Comment', backref='video', cascade='all, delete-orphan') class Comment(db.Model): __tablename__ = 'comments' id = db.Column(db.Integer, primary_key=True) content = db.Column(db.Text, nullable=False) user_id = db.Column(db.Integer, db.ForeignKey('users.id')) video_id = db.Column(db.Integer, db.ForeignKey('videos.id')) created_at = db.Column(db.DateTime, default=datetime.now) class Favorite(db.Model): __tablename__ = 'favorites' id = db.Column(db.Integer, primary_key=True) user_id = db.Column(db.Integer, db.ForeignKey('users.id')) video_id = db.Column(db.Integer, db.ForeignKey('videos.id')) created_at = db.Column(db.DateTime, default=datetime.now)

设计时我特别注意了评论和视频的关联，这里的级联删除很关键。当管理员删除某个视频的时候，它下面的所有评论必须一并删除，否则数据库里会出现大量的孤儿数据。这个在短视频网站上天天发生，用户骂平台删评论，其实很多时候就是后台在清垃圾数据。

2.3 从登录到播放：一次完整请求的流程

为了把数据流讲清楚，我用一个“播放视频”的例子来说明。用户在首页看到某个视频封面，点击之后浏览器会发起两个请求：第一个请求是GET /video/3，服务端根据URL里的ID从数据库取出视频记录、关联的评论列表和收藏状态，然后渲染出一个视频详情页HTML返回给浏览器；第二个请求是浏览器在解析HTML时发现video标签的src指向/api/video/3/stream，于是又发起一个带Range头的请求，服务端从文件系统读取对应字节区间并返回二进制视频流。

这两部分逻辑是完全分离的，一个叫“页面渲染”，一个叫“文件流式传输”。很多同学会把这两个混在一起，在视图函数里用send_file直接返回整个文件，结果播放体验非常差。正确做法是，页面渲染走普通的模板渲染，文件流式传输走专门的处理函数，两者互不干扰。这也是我为什么在目录里把路由分成video.py（页面）和stream.py（流媒体）的原因。

3. 核心功能模块的实现：代码怎么落下来

3.1 用户认证：密码安全与Session管理

用户模块虽然不复杂，但它是整个系统最基础的部分，也是答辩时评委最可能深挖的点。我用的是Flask-Login扩展来做Session管理，密码加密用Werkzeug自带的哈希函数，这是业界公认的安全实践。注意千万不要用MD5对密码做单向加密，那种方案在现在已经是安全底线以下的东西了。

注册流程很简单，就是表单校验、查重、创建用户、保存。需要额外注意的是登录状态的判断和“记住我”功能。Flask-Login提供了一个login_required装饰器，只要在需要登录才能访问的视图上加上它，未登录的用户就会被重定向到登录页。我在视频上传、评论、收藏这些接口上都加了登录保护，管理员接口再加一个自定义的admin_required装饰器。代码示例：

# utils/decorators.py from functools import wraps from flask import abort from flask_login import current_user def admin_required(f): @wraps(f) def decorated_function(*args, **kwargs): if not current_user.is_authenticated: abort(401) if not current_user.is_admin: abort(403) return f(*args, **kwargs) return decorated_function

这里有个容易被忽略的细节：abort(401)和abort(403)是有区别的，前者是“你没登录”，后者是“你登录了但没权限”。如果你统一返回404，虽然能隐藏后台地址，但答辩时评委点了一下你的后台链接发现什么反应都没有，会怀疑系统有Bug。不如直接返回403，清晰明了。

3.2 视频上传：大小控制、重命名与封面处理

视频上传是整个系统里对用户体验影响最大的一环，也是最容易翻车的环节。Flask的request.files接口拿上传文件很简单，但有几个坑必须提前规避。一是文件大小限制，我建议在配置里加上MAX_CONTENT_LENGTH，比如限制为200MB，超过直接拒绝，防止有人上传超大文件把磁盘撑爆。二是文件名处理，用户上传的文件名可能是中文、带空格、甚至有路径穿越的恶意字符，所以一律用uuid.uuid4().hex生成新文件名，扩展名用白名单校验。

封面这一块，我一开始想用OpenCV读取视频首帧，还需要额外处理依赖，后来放弃了。更省事的方案是让用户上传封面图，或者用视频文件名匹配一个默认封面。这个可以根据自己的时间灵活处理，就算没有封面生成也不影响主体功能。上传视图的核心逻辑大概是这样：

# blueprints/video.py import os import uuid from flask import render_template, request, redirect, url_for, flash, current_app from flask_login import login_required, current_user from werkzeug.utils import secure_filename from ..models import Video, Category from ..extensions import db from . import bp ALLOWED_VIDEO_EXTENSIONS = {'mp4', 'webm', 'ogg'} ALLOWED_IMAGE_EXTENSIONS = {'jpg', 'jpeg', 'png', 'gif'} @bp.route('/upload', methods=['GET', 'POST']) @login_required def upload(): if request.method == 'POST': title = request.form.get('title', '').strip() description = request.form.get('description', '').strip() category_id = request.form.get('category_id', type=int) video_file = request.files.get('video_file') cover_file = request.files.get('cover_file') if not title or not video_file: flash('标题和视频文件是必填项') return redirect(request.url) if video_file.filename.rsplit('.', 1)[-1].lower() not in ALLOWED_VIDEO_EXTENSIONS: flash('不支持的视频格式') return redirect(request.url) # 生成唯一文件名 video_ext = video_file.filename.rsplit('.', 1)[-1].lower() video_filename = uuid.uuid4().hex + '.' + video_ext video_path = os.path.join(current_app.config['UPLOAD_FOLDER'], video_filename) video_file.save(video_path) cover_filename = 'default.jpg' if cover_file and cover_file.filename: cover_ext = cover_file.filename.rsplit('.', 1)[-1].lower() if cover_ext in ALLOWED_IMAGE_EXTENSIONS: cover_filename = uuid.uuid4().hex + '.' + cover_ext cover_path = os.path.join(current_app.config['COVER_FOLDER'], cover_filename) cover_file.save(cover_path) video = Video( title=title, description=description, file_path=video_filename, cover_path=cover_filename, category_id=category_id, user_id=current_user.id ) db.session.add(video) db.session.commit() flash('上传成功') return redirect(url_for('video.detail', video_id=video.id)) categories = Category.query.all() return render_template('upload.html', categories=categories)

注意这里有个细节，我存进数据库的不是完整路径，而是只有文件名。这样数据库里存储的是相对路径，部署时不管项目放在哪个目录，都能通过拼接配置项找到真实文件，避免硬编码路径导致的迁移问题。

3.3 视频播放页：Range分段加载的关键代码

这是整个项目最核心的一段代码，值得反复琢磨。视频流式传输的原理我刚才讲过了，就是解析HTTP的Range头，返回部分内容。在Flask里实现有两种方式：一种是直接用send_file函数，并传入conditional=True，Flask会自动处理Range逻辑；另一种是自己手动解析Range头，控制更精细。我用的是手动解析的方式，因为这样可以更好地控制异常处理和日志记录：

# blueprints/stream.py import os import re from flask import Blueprint, request, Response, abort, current_app from ..models import Video bp = Blueprint('stream', __name__) def parse_range_header(range_header, file_size): """解析Range头，返回(start, end)或None""" if not range_header: return None, None match = re.match(r'bytes=(\d*)-(\d*)', range_header) if not match: return None, None start_str, end_str = match.groups() start = int(start_str) if start_str else 0 end = int(end_str) if end_str else file_size - 1 if start >= file_size: return file_size - 1, file_size - 2 # 无效范围 if end >= file_size: end = file_size - 1 return start, end @bp.route('/api/video/<int:video_id>/stream') def stream_video(video_id): video = Video.query.get_or_404(video_id) file_path = os.path.join(current_app.config['UPLOAD_FOLDER'], video.file_path) if not os.path.exists(file_path): abort(404) file_size = os.path.getsize(file_path) range_header = request.headers.get('Range', None) if range_header: start, end = parse_range_header(range_header, file_size) if start is None: return Response(status=416) # 范围无效 chunk_size = end - start + 1 def generate(): with open(file_path, 'rb') as f: f.seek(start) remaining = chunk_size while remaining > 0: chunk = f.read(min(8192, remaining)) if not chunk: break remaining -= len(chunk) yield chunk response = Response(generate(), status=206, content_type='video/mp4') response.headers['Content-Range'] = f'bytes {start}-{end}/{file_size}' response.headers['Accept-Ranges'] = 'bytes' response.headers['Content-Length'] = str(chunk_size) return response else: # 不带Range的请求，直接全量返回（兼容某些播放器） def generate(): with open(file_path, 'rb') as f: while True: chunk = f.read(8192) if not chunk: break yield chunk response = Response(generate(), status=200, content_type='video/mp4') response.headers['Content-Length'] = str(file_size) response.headers['Accept-Ranges'] = 'bytes' return response

这段代码最关键的地方在于生成器generate的使用。视频文件可能很大，如果用file.read()一次性读完再返回，内存会直接爆掉。用生成器可以做到按8KB的块从磁盘读取边读边响应，内存占用恒定。这在Python里就是生产级别流式下载的标准写法。

顺便说一下，我存储的文件如果本身是H.264编码的MP4，浏览器都能直接解码播放。如果你上传的是其他编码格式，比如MOV、MKV，浏览器很可能只出声音不出画面，或者干脆黑屏。这个问题在答辩现场出现会非常尴尬，所以最好在项目说明里明确标注“支持MP4/H.264格式”，或者用FFmpeg在后台做转码。转码这块比较复杂，我建议时间不够的同学直接做格式限制，而不是花两星期搭FFmpeg服务。

3.4 后台管理：最被低估的一环

很多同学做毕设，把80%的精力都花在了前台界面上，后台管理随便弄个列表就应付过去。但我个人建议，后台管理一定要认真做，因为这是答辩时评委看得最仔细的部分，而且它直接体现“系统化管理”的能力。我的后台包括四个部分：仪表盘（显示用户数、视频数、总播放量）、视频管理（列表、上下架、删除）、用户管理（禁用/启用账号）、评论管理（删除不当言论）。

视频管理的核心操作是上下架和删除。上架就是把status字段设为1，下架设为0；删除则是彻底从数据库和磁盘上移除。这里涉及一个事务问题：删除时先删数据库记录，还是先删文件？如果先删文件、再删数据库，而数据库删除失败，就会造成“有记录没文件”的错误。我建议先删数据库记录，再删文件，因为即使文件删除失败，也只是磁盘残留一点垃圾，不影响系统功能。这个顺序在很多系统设计中都有讲究。

# blueprints/admin.py @bp.route('/video/<int:video_id>/delete', methods=['POST']) @admin_required def delete_video(video_id): video = Video.query.get_or_404(video_id) db.session.delete(video) # 级联删除评论 db.session.commit() try: # 删除视频文件（如果存在） file_path = os.path.join(current_app.config['UPLOAD_FOLDER'], video.file_path) if os.path.exists(file_path): os.remove(file_path) # 删除封面文件（如果不是默认的） if video.cover_path != 'default.jpg': cover_path = os.path.join(current_app.config['COVER_FOLDER'], video.cover_path) if os.path.exists(cover_path): os.remove(cover_path) except Exception as e: current_app.logger.warning(f'删除文件失败: {e}') flash('视频已删除') return redirect(url_for('admin.video_list'))

这里我用了try/except包住文件删除操作，即便删除失败也不会中断整个请求。日志里记录一下警告就行，系统本身不会出错。这也是我反复跟大家说的——在Web应用里，数据库操作和文件系统操作尽量不要放在同一个事务里，因为文件系统的错误返回模式和数据库完全不一样。

4. 踩坑实录与常见问题排查：开发一个月的血泪总结

4.1 环境配置的坑：Python安装与虚拟环境

我一开始在Windows上做开发，第一周就浪费了两天配环境。后来总结下来，用Python做Web项目，环境这块三条铁律：第一，不要直接装Python到系统目录，用Anaconda或者pyenv管理版本更好；第二，项目一定要用虚拟环境，用python -m venv venv创建，不要用全局环境装依赖；第三，依赖列表要固定版本，pip freeze > requirements.txt生成，这样换机器时一键恢复环境。

说到Python安装，很多新手最容易栽在环境变量上。Windows下如果安装的时候没有勾选“Add Python to PATH”，命令行里敲python就会提示不是内部或外部命令。正确做法是去系统设置里手动把Python的安装目录和Scripts目录加到PATH。装完依赖再跑一遍flask run，看到类似Running on http://127.0.0.1:5000的输出，就说明环境OK了。VSCode里配置Python环境也类似，选中解释器时一定要指向虚拟环境里的python.exe，而不是全局那个。

4.2 视频流播放的坑：浏览器拖不动进度条

我调试的时候遇到一个很典型的问题：视频可以播放，但进度条一拖就跳回开头。排查了一圈才发现，是Range响应头没有正确设置Content-Length。视频播放器会在用户拖动进度条时发Range请求，如果后端返回的响应头里没有Content-Length，播放器不知道这一片段的边界，就会放弃拖拽。所以上面stream函数里，我特意手动设置了Content-Length为chunk_size，而不是整个文件大小。

还有一个坑是缓存问题。浏览器对视频流的缓存策略比较特殊，如果你没有设置Cache-Control: no-cache，有时候改了视频文件，浏览器还在播旧的缓存。我在stream响应里加了Cache-Control: no-store，确保每次播放都拿最新文件。

4.3 中文编码的坑：文件下载名和搜索

中文文件名在上传时被我一律用uuid重命名了，所以文件系统层面不会碰到编码问题。但如果你在项目的某个地方写了导出功能，要用send_file返回一个带中文名的文件，就要注意Content-Disposition头的编码。Flask的send_file提供了一个download_name参数，它会自动处理好RFC 2231编码，这是我后面查资料才发现的。

列表页按标题搜索时，也容易遇到SQLite匹配中文的问题。SQLite的LIKE子句本身支持中文，但如果你用的是ESCAPE字符处理不当，含下划线的标题会匹配到别的东西。这个属于比较偏的问题，我的做法是把用户输入传给SQLAlchemy的like方法，并且用%(keyword)%包裹，同时用contains方法替代LIKE，SQLAlchemy会自动处理通配符转义。

4.4 部署上线的坑：从开发服务器到生产环境

毕设演示一般是在自己的笔记本上跑，直接flask run就够用了。但我见过有同学在答辩前想部署到云服务器上演示，那就必须把Flask自带的开发服务器换成Waitress或Gunicorn这类WSGI服务器。Windows上推荐Waitress，因为Gunicorn在Windows上有兼容性问题。

这里踩过的最大坑是：部署到服务器后，上传的视频文件必须要有写入权限，否则上传接口会静默失败或者提示PermissionError。在Linux服务器上，要给uploads目录设置chmod 755，并确保运行用户对目录有写权限。另外，SQLite数据库文件也要保证可写，不然会出现数据库“database is locked”的错误。

还有一点就是静态文件路径。本地开发时app.static_folder指向的是static/目录，如果代码里到处用了绝对路径，换个环境就要改一堆地方。建议所有文件和目录路径都从配置文件里读取，这样换环境只改一个config.py就能搞定。

4.5 常见问题速查表

为了让大家快速定位问题，我把开发过程中遇到的高频问题整理成一个表：

5. 优化方向与个人心得

5.1 还能怎么扩展：几个加分项

如果你想把项目做得更出彩，有几个低成本的扩展方向可以尝试。第一个是给视频增加播放次数统计，这个只要在播放接口里对play_count字段做加一操作就行，注意要用原子性更新Video.play_count += 1配合db.session.commit()，避免并发出错。第二个是做一个热门视频排行榜，按播放次数倒序排列，放首页作为“热门推荐”板块，视觉冲击力很强。第三个是支持用户收藏功能，收藏按钮的状态切换可以做成前端Ajax请求，不刷新页面，这种交互细节在答辩时是明显的加分项。

如果你对前端感兴趣，还可以用Bootstrap的modal组件做一个视频预览弹窗，鼠标悬停视频卡片时弹出预览画面。不过这个功能需要额外的缩略图生成支持，如果没有FFmpeg环境就别强行做了，因为这个很容易暴露短板。

5.2 我做完这个项目的几点体会

整个项目做下来，最大的感触是“视频点播”这个题目本身不难，难的是把细节处理到位。比如Range请求实现得好不好，直接决定了播放体验；文件命名规范不规范，决定了后续维护成本；权限控制严不严谨，决定了系统安不安全。这些细节看起来不起眼，但每一个都是Web开发的基本功，评委问起来你能答得头头是道，项目的基本盘就稳了。

我个人在实际操作中体会到，做毕设最忌讳的是“想一步做一步”。一开始就先把数据库设计好、接口定义好、目录结构规划好，后面的开发才会顺畅。另外，代码里的注释一定要写清楚，不是为了装样子，而是你写完两周后再回头看自己写的东西，如果没有注释，可能自己都看不懂当时为什么这么写。我这次就在每个文件的开头写清楚了这个模块的职责，在每个函数的docstring里写清了参数和返回值，答辩时直接把代码展示出来，不需要额外准备说明文档。

最后再分享一个小技巧：答辩前一定要准备一个“干净环境”的演示流程，用一台没有装过任何Python依赖的电脑，完整走一遍环境安装、依赖恢复、初始化数据库、启动系统、上传视频、播放视频、后台删除的完整流程。我自己的机器因为装过太多包，跑起来很顺畅，但换到评审老师的电脑上有时候就各种报错。提前演练一遍，把这些坑都排掉，比多写一百行代码都管用。

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