做一套属于自己的短视频点播系统，这事我想了很久。Python做后端，微信小程序做前端，一套能上传视频、能刷Feed流、能加评论点赞的小程序，听起来是个标准毕业设计题，但真要做扎实，里面的坑比想象中多得多。从数据库表结构怎么设计，到视频转码怎么不把服务器CPU打满，再到小程序里那个让人头疼的顶部导航栏适配，每一步都有值得记录的细节。

这篇文章就是把我从零搭建这套系统的完整过程整理出来。不是纯理论分析，而是我实际写代码、跑流程、上线部署后沉淀下来的一套可以直接参考的路径。适合正在做相关课题的学生，也适合工作后想快速验证一个产品想法的开发者。

1. 先想清楚：这套系统到底解决什么问题

很多人在动手前容易陷入一个误区，上来就分前端后端，先把登录注册写了，再去搞视频上传，结果做到一半发现页面跳来跳去，接口互相不匹配，整个项目变成一团乱麻。做这类系统最忌讳的就是没想清楚就开写。

1.1 用户真正需要的是什么

短视频系统的用户行为链路非常清晰，打开小程序，看到视频列表，点进去播放，然后点赞、评论、关注。还有一个核心行为就是发布自己的视频。

但这里面有个容易被忽视的点：用户上传视频和观看视频是不同的场景。上传发生在创作者端，观看发生在消费端，两者对系统的要求截然不同。上传要考虑稳定性、大文件处理、转码能力；观看要考虑加载速度、播放流畅度、流量成本。

我的做法是先把这两条链路分开设计。观看链路走公开的Feed流接口加CDN加速，上传链路走独立的上传接口加分片机制。这样后端逻辑清晰，出了问题也容易定位。

1.2 为什么选择Python和微信小程序这个组合

选Python做后端，最重要原因是生态成熟。视频处理有MoviePy和FFmpeg的Python绑定，Web框架有Flask和Django两个主流选择，数据库操作有SQLAlchemy，缓存有Redis客户端，几乎每个环节都有现成的库可以用。

微信小程序则是目前触达用户成本最低的载体。不需要下载App，扫码就能用，而且微信生态内的分享传播机制天然适合短视频这种内容形态。小程序端的API对视频播放有专门的 VideoContext 控制，对上传有 wx.uploadFile 和 wx.chooseMedia ，这些都让开发省了很多事。

当然也要说清楚，Python在后端高并发场景下不占优势。但对一个中小规模的视频点播系统来说，Python完全够用，只要架构设计得当，支撑上万日活没有压力。等真的需要撑起百万级流量的时候，再考虑用Go或Java重写核心服务也不迟，前期没必要为了不存在的性能瓶颈过度设计。

2. Python后端骨架：从技术选型到数据库设计

后端是整个系统的大本营，视频数据、用户数据、评论数据都要在这里汇聚和分发。这一节我把自己最终采用的方案和理由详细拆解一下，涉及具体的选择逻辑，而不是简单给个清单。

2.1 技术栈选型与项目结构

我最终选择Flask框架。Django固然自带了Admin后台和ORM，功能完整，但对视频系统来说显得笨重，而且Django的ORM在处理复杂查询时并不比SQLAlchemy灵活。Flask轻量、灵活，配合蓝图（Blueprint）做模块化，非常契合这个项目的规模。

项目结构我采用了类似下面这种划分：

videoproject/
├── app.py                 # 应用入口
├── config.py              # 配置管理
├── models/                # 数据模型
│   ├── user.py
│   ├── video.py
│   ├── comment.py
│   └── like.py
├── api/                   # 蓝图路由
│   ├── auth.py             # 登录鉴权
│   ├── video.py            # 视频接口
│   ├── comment.py          # 评论接口
│   └── upload.py           # 上传接口
├── services/              # 业务逻辑
│   ├── oss_service.py      # 对象存储
│   ├── transcode_service.py # 转码服务
│   └── feed_service.py     # Feed流
├── utils/                 # 工具函数
│   ├── response.py         # 统一响应格式
│   └── token.py            # JWT工具
└── requirements.txt

这种按业务模块划分的方式，比单纯按函数堆砌要好维护得多。每个蓝图负责一组相关的API，每个服务类负责一项独立的能力，逻辑边界清晰。后期加功能时，只需要新增蓝图文件，不需要动已有的代码。

数据库我采用MySQL 8.0，存储引擎InnoDB，字符集utf8mb4。Redis则用来做会话缓存和Feed流的热数据缓存。

2.2 数据库表结构的设计思路

表结构设计决定了后续接口怎么写得顺手。这里花的时间值得，后面能少走很多弯路。

用户表是最基础的，我用微信小程序的 openid 作为唯一标识。注意这里有个关键点：不要直接用 openid 做主键，而是用一个自增的 id 做业务主键， openid 加唯一索引。原因在于后续可能需要支持多种登录方式，而且 openid 在跨平台时可能会变（比如从小程序迁移到公众号），用独立主键更灵活。

视频表是核心表，我这样设计：

CREATE TABLE video (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  user_id BIGINT NOT NULL,
  title VARCHAR(100) NOT NULL,
  description TEXT,
  video_url VARCHAR(500) NOT NULL,
  cover_url VARCHAR(500),
  duration INT DEFAULT 0,
  width INT DEFAULT 0,
  height INT DEFAULT 0,
  status TINYINT DEFAULT 0,
  like_count INT DEFAULT 0,
  comment_count INT DEFAULT 0,
  play_count INT DEFAULT 0,
  create_time DATETIME DEFAULT CURRENT_TIMESTAMP,
  INDEX idx_user_id (user_id),
  INDEX idx_status_create (status, create_time)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这里的 status 字段很关键，我用了几个值来标记视频的状态。0表示转码中，1表示转码完成可播放，2表示审核不通过。为什么要保留这个字段而不直接把视频URL存上去就完事？因为用户上传的视频源文件往往体积大、编码格式不统一，直接播放会非常卡。一定要先转码成适合网络播放的H.264格式，这个过程中视频还不能对外展示，所以需要状态位来控制可见性。

评论表和点赞表的设计相对简单，但要注意点赞表需要加唯一约束防止重复点赞。评论表则要支持分页查询，所以索引设计要合理：按视频ID和时间排序，建立联合索引。

CREATE TABLE comment (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  video_id BIGINT NOT NULL,
  user_id BIGINT NOT NULL,
  content VARCHAR(500) NOT NULL,
  create_time DATETIME DEFAULT CURRENT_TIMESTAMP,
  INDEX idx_video_time (video_id, create_time)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

2.3 统一响应格式与全局异常处理

小程序端的网络请求解析能力有限，如果每个接口返回的数据格式不一样，前端要写一堆兼容逻辑。我定义了统一的响应格式，这是写正式项目时容易被忽略但极其有用的习惯：

def success(data=None, message="ok"):
    return {
        "code": 0,
        "message": message,
        "data": data
    }

def error(code, message):
    return {
        "code": code,
        "message": message,
        "data": None
    }

配合Flask的 @app.errorhandler 做全局异常捕获，任何未预期的异常都会返回格式化的错误响应，而不是一堆HTML错误页。前端只需判断 code 是否为0，省去大量兼容代码。

3. 微信小程序前端：页面搭建与核心交互

小程序端我选择了原生开发，而不是uni-app。这个决定基于一个考量：视频类小程序对性能要求较高，原生小程序的性能和调试体验更好；而且我只需要支持微信一个平台，不需要跨端的红利。如果未来要上支付宝小程序，再迁移也不迟，小程序基本语法是相通的，迁移成本可控。

3.1 首页Feed流设计

首页是整个产品的门面。短视频产品的Feed流通常采用上下滑动切换视频的方式，这在小程序里可以用 swiper 组件来实现。

<swiper class="video-swiper" vertical="true"
        bindchange="onSwiperChange"
        current="{{currentIndex}}">
  <swiper-item wx:for="{{videoList}}" wx:key="id">
    <video 
      id="video-{{item.id}}"
      src="{{item.videoUrl}}"
      poster="{{item.coverUrl}}"
      autoplay="{{index === currentIndex}}"
      object-fit="contain"
      bindplay="onVideoPlay"
      bindpause="onVideoPause"
    ></video>
  </swiper-item>
</swiper>

这里面有个非常关键的性能细节：不要给每个 swiper-item 里的 video 都设置 autoplay ，否则页面初始化时会同时加载多个视频，导致缓冲和卡顿。正确做法是只让当前项自动播放，其余全部不自动播放。我通过 index === currentIndex 这个判断来控制。

swiper 的 bindchange 事件会在滑动后触发，这时要维护一个当前索引的变量，并且对上一个不再可见的视频调用 pause() 暂停播放，对当前新的视频调用 play() 。逻辑不复杂，但直接影响用户体验。

3.2 如何解决顶层导航栏高度适配问题

热搜词里我看到“微信小程序顶部导航栏高度”这个话题，这说明很多人踩过这个坑。自定义导航栏是实现沉浸式体验的常用手段，但不同机型的胶囊按钮位置和导航栏高度完全不同，写死高度就是灾难。

解决方案是动态获取：

const systemInfo = wx.getSystemInfoSync();
const menuButtonInfo = wx.getMenuButtonBoundingClientRect();

// 胶囊按钮到屏幕顶部的距离（包含状态栏）
const capsuleTop = menuButtonInfo.top;
// 胶囊按钮到屏幕右边的距离
const capsuleRight = menuButtonInfo.right;
// 导航栏高度 = 胶囊顶部位置 - 状态栏高度 + 胶囊高度 + 胶囊底部间隔
const navBarHeight = (capsuleTop - systemInfo.statusBarHeight) * 2 + menuButtonInfo.height;

这里的关键推导是：胶囊按钮是垂直居中对齐的，所以导航栏总高度等于胶囊上方间距乘以2加胶囊高度。有了这两个值，就能在 wx.setNavigationBarColor 失效时自己绘制定位的导航栏。封装成一个工具函数后，全项目所有自定义导航栏页面都可以复用。

提示： wx.getMenuButtonBoundingClientRect() 在基础库2.1.0以上可用，如果兼容老版本，可以在App.onLaunch时获取并存入globalData，避免每个页面重复调用。

3.3 播放页面的横竖屏切换与锁屏

播放页是用户停留时间最长的页面，交互体验一定要做细。我实现了全屏播放，并且在进入全屏后自动横屏，退出全屏后恢复竖屏。

// 进入全屏
const videoContext = wx.createVideoContext('myVideo');
videoContext.requestFullScreen({
  direction: 90
});

// 监听全屏切换
this.videoContext.onFullScreenChange((res) => {
  if (res.direction === 90 || res.direction === -90) {
    wx.setPageOrientation('landscape');
  } else {
    wx.setPageOrientation('portrait');
  }
});

还有一个细节很多开发者会忽略：视频播放页在页面栈里不能压太多层，否则小程序内存占用会持续升高。我的方案是做一个专门的播放页，从Feed流跳转时只跳转到这个页面，并传入视频ID，播放页内通过ID请求详情数据。这样即使刷了几十个视频，页面栈里始终只有两层。

4. 核心链路：视频上传、转码与分发

这一部分是整套系统技术含量最高的地方，也是最容易出现问题的环节。用户在小程序端选择视频，上传到服务器，服务器做转码处理，再发布到Feed流。任何一步出问题，用户看到的就是“上传失败”或者“视频打不开”。

4.1 小程序端视频选材与本地压缩

真实用户手机上录制的视频，动辄几十上百MB，4K分辨率也不少。直接上传不现实，既慢又消耗流量。所以小程序端要先做压缩处理。

wx.chooseMedia 提供了 compressed 参数，设置为 true 时会对视频进行一定程度的压缩。实测下来，一个1080P的1分钟视频，压缩后大概在5-10MB左右，画质还能接受。但要注意，这个参数不是万能的，在某些低端机型上压缩效果不理想，还需要在服务端做二次转码兜底。

选择逻辑也很关键。我设置了时长限制和大小限制。超过5分钟的视频直接提示用户裁剪后上传，超过100MB的视频警告用户将消耗较多流量。

4.2 服务端分片上传处理

大文件上传不能使用 wx.uploadFile 一把梭，原因在于小程序端上传时如果网络波动，整个请求就断了，就要从头再来。分片上传是最好的解决方式。

小程序端将本地视频文件切成小块，通过 wx.uploadFile 依次上传每个分片，每个分片带有文件标识和分片序号，服务端收到后暂存在临时目录，全部上传完成后触发合并请求，将临时文件拼接成完整文件。

@app.route('/api/upload/merge', methods=['POST'])
def merge_video():
    file_id = request.json.get('fileId')
    total_parts = request.json.get('totalParts')

    with open(final_path, 'wb') as output:
        for i in range(total_parts):
            part_path = os.path.join(tmp_dir, f"{file_id}_{i}.part")
            with open(part_path, 'rb') as part_file:
                output.write(part_file.read())
            os.remove(part_path)

    # 触发转码任务
    transcode_service.submit(file_id, final_path)

    return success({"fileId": file_id})

这里有个小经验：分片大小不要设太大也不要太小。我实测的最佳范围是1-2MB，既不会因为请求过多导致网络延迟累积，也不会因为单片过大导致失败重传成本高。分片数建议限制在100个以内，超过的话就让用户重新选择较小的视频。

4.3 转码服务与FFmpeg调用

视频上传后不能立即发布。手机录制的视频编码五花八门，有的是H.265，有的是VP9，甚至有的是MPEG-4。这些编码在小程序端不一定能播，或者播放起来不流畅。需要统一转码成H.264 + AAC的MP4格式。

我用的是FFmpeg命令行调用，配合Python的 subprocess 模块：

def transcode_video(input_path, output_path):
    command = [
        'ffmpeg', '-i', input_path,
        '-c:v', 'libx264', '-preset', 'fast',
        '-crf', '23',
        '-c:a', 'aac', '-b:a', '128k',
        '-movflags', '+faststart',
        '-vf', 'scale=1280:-2',
        output_path
    ]
    subprocess.run(command, check=True)

几个参数值得解释一下。 -crf 23 是画质和体积的平衡点，数值越小画质越好但文件越大；实测23对大多数视频来说视觉上无损，文件大小也合理。 -preset fast 压缩速度快，虽然体积比 slow 稍大一点，但能显著提升转码效率。 -movflags +faststart 非常关键，这个参数把MP4的索引信息移到文件开头，用户播放时不需要下载完成就能开始播放，对视频点播的体验提升巨大。

-vf scale=1280:-2 把视频等比例缩放到宽度1280。为什么要缩放？因为大多数手机录制的视频分辨率在1920以上，但手机上播放时肉眼很难分辨1080P和720P的差别。缩放到720P级别可以减少近一半的带宽消耗，加载速度更快，播放更流畅。

转码是CPU密集型任务，不能放在请求线程里同步执行，否则用户会等很久。我的方案是用Redis列表作为任务队列，后台有一个Python脚本常驻监听队列，取出任务后交FFmpeg处理。这样上传接口秒回，转码异步完成，通过视频状态字段同步给前端。

4.4 视频封面截取与存储策略

封面图的重要性容易被低估。没有封面的视频在Feed流里是黑色方块，点击率会断崖式下降。封面在转码时用FFmpeg截取中间帧生成：

ffmpeg -i input.mp4 -ss 00:00:02 -vframes 1 -vf "scale=640:-2" cover.jpg

-ss 00:00:02 表示在第2秒位置截取。截图后，封面图和视频本体需要存储到对象存储或本地磁盘的媒体目录。如果购买阿里云或腾讯云服务器，可以搭配对象存储OSS服务，视频文件和图片放云端，服务器只承担计算任务。带宽压力小很多，也方便后续扩容。

5. 商业化环节：支付对接和其他避坑实录

影视点播类小程序天然有商业化需求，会员付费、单视频购买、打赏都是常见的变现手段。微信支付v3的对接是整个项目中另一个容易出问题的环节，热搜词里“微信支付v3对接 由于小程序违规，支付功能暂时无法使用”的搜索量很高，说明这是个普遍痛点。

5.1 微信支付v3对接的核心流程

微信支付v3和v2相比，API签名方式从MD5签名变成了RSA非对称签名，对安全性要求更高，但对接链路反而更清晰。核心步骤是：

1. 构建请求参数，包含商户号、AppID、描述、金额、回调地址等
2. 用商户私钥对参数签名
3. 请求微信支付统一下单接口，获取 prepay_id
4. 小程序端用 prepay_id 调起支付

Python对接时，推荐使用 wechatpayv3 这个库。它封装了大部分细节，但签名私钥和处理证书的逻辑仍然需要理解，否则出了问题无从排查。

小程序端调起支付的代码非常简洁：

wx.requestPayment({
  timeStamp: res.data.timeStamp,
  nonceStr: res.data.nonceStr,
  package: res.data.package,
  signType: 'RSA',
  paySign: res.data.paySign,
  success: (res) => { /* 支付成功 */ },
  fail: (err) => { /* 支付失败 */ }
});

5.2 “小程序违规，支付功能暂时无法使用”的成因与解决路径

搜索量极高的这个关键词，实际指向的问题往往不是代码层面的，而是账号类目和资质审核。小程序开通微信支付需要经过平台审核，且需要在小程序管理后台关联同主体的商户号。如果小程序选择的服务类目与支付场景不符，或者没有提供对应资质文件（比如营业执照经营范围不符），就会导致支付功能被限制。

还有一种常见情况是虚拟支付违规。虚拟内容（比如视频观看券、VIP会员）在小程序端是不能直接用微信支付收款的，平台明确要求虚拟支付必须走Android/iOS的虚拟支付通道，或使用小程序自身的虚拟支付组件。我之前就见过一个影视类小程序，因为直接在小程序里售卖“观看券”被判定为虚拟支付违规，支付功能被冻结了很久。

解决办法是调整经营策略。影视点播类小程序通常的做法是：小程序内只提供免费内容和观看广告解锁，会员付费迁移到公众号H5页面或App端完成。当然这在用户体验上会有割裂感，是很多内容类小程序的常态化妥协。

5.3 小程序跳转链接失败的排查经验

热搜词里还有“微信小程序跳转链接 weixin://dl/business 从生成到触发的全流程避坑”，这个 weixin://dl/business 链接用于跳转到指定的微信业务页面，比如跳转到某个小程序、某个卡包页面等。但它触发条件比较苛刻，失败时通常没有明显报错，排查起来很费劲。

我踩过的一个坑是：开发版和体验版能正常跳转，但线上正式版跳转失败。原因是没有在小程序管理后台配置业务域名。微信对跳转链接有严格的安全校验， weixin://dl/business 链接需要在后台添加绑定，否则线上环境直接拦截。另外，这类链接还分URL Scheme和URL Link两种，小程序内跳转需要用URL Link，外部短信或邮件跳转需要用URL Scheme，两者参数不同，不要混用。

还有一个细节： weixin://dl/business 携带的path参数必须是编码后的字符串，不能带中文和特殊字符，否则解析失败。排查时可以先在开发者工具中打开“不校验合法域名”开关，试通之后再把坑逐个填上。

6. 系统上线部署与性能优化

开发完成只是第一步，真正上线后才会遇到各种环境问题。这一节我把上线部署中的关键步骤和调优经验记录下来。

6.1 Linux服务器环境搭建

我用的是一台4核8G的云服务器。系统装的是Ubuntu 22.04 LTS，这个版本对Python 3.10支持良好，各种系统库也很全。

安装Python、MySQL、Redis和Nginx这套常规操作就不展开了，这里重点说几个容易忽略的系统依赖。FFmpeg不能只用 apt install ffmpeg 装基础版，一定要装全插件版本，否则转码时会遇到各种编码不支持的错误。我使用的是 ffmpeg 官方静态编译版，解压到 /usr/local/bin 即可，功能完整而且不用担心库冲突。

Nginx的配置比较关键。小程序的 video 组件播放视频时，如果服务器没有正确配置 Content-Type ，视频会无法播放或无法拖动进度条。需要在Nginx配置中加上：

location ~* \.(mp4|flv|m3u8)$ {
    add_header Content-Type video/mp4;
    add_header Accept-Ranges bytes;
}

Accept-Ranges bytes 这个响应头尤其重要，没有它，小程序端视频组件就无法拖动进度条，因为原生播放器不支持流式播放带范围请求的视频。

6.2 HTTPS证书的配置

小程序正式版要求所有请求域名必须是HTTPS，且证书必须是有效的，不能用自签证书。服务器上我用Certbot申请Let's Encrypt免费证书，配置Nginx启用SSL。需要注意的一点是，证书有效期只有90天，一定要设置定时续期任务，否则证书过期后小程序所有请求都会失败，用户看到的就是一片空白。

6.3 小程序后台的合法域名配置

不要忘记，在小程序管理后台要把服务器的域名配置成request、uploadFile、downloadFile的合法域名。这个配置大概是开发者最常见的“能编译但请求不了数据”的原因。域名配置后不是立即生效，需要等几分钟到十几分钟，并且后续版本更新时会提示确认这些域名是否继续使用，需要手动勾选确认。

6.4 被忽略的数据库连接池配置

上线后第一个星期，我就遇到了MySQL连接数被打满的问题。原因是Python的 PyMySQL 每次请求都新建连接，高并发下直接耗尽数据库连接。

解决办法是使用 DBUtils 连接池：

from dbutils.pooled_db import PooledDB

pool = PooledDB(
    creator=pymysql,
    maxconnections=20,
    mincached=5,
    maxcached=10,
    maxusage=None,
    blocking=True,
    host="localhost",
    user="root",
    password="xxx",
    database="video_db",
    charset="utf8mb4"
)

配置这个连接池后，数据库连接复用率提升明显，再也没出现过连接被占满的情况。另外，所有查询尽量走索引，避免全表扫描。我遇到过一个很典型的问题：视频列表页加载耗时从500ms飙升到2秒，排查后发现是 order by create_time desc 没有走索引，加了一个联合索引后回归到了200ms以内。

6.5 视频CDN加速的实际效果

视频分发是带宽消耗的大头。如果视频文件全部走服务器出口带宽，传统的按固定带宽计费模式费用感人。我测试过几种方案，最终选择把视频文件上传到对象存储（如阿里云OSS或腾讯云COS），然后开启CDN加速域名。服务器只负责API请求和动态数据处理，视频播放流量全走CDN。这样一来：

• 视频加载速度从原来的平均2-3秒提升到500ms以内
• 服务器带宽压力大幅缓解，4核8G的配置支撑几千日活毫无压力
• 流量费用反而比单纯买高带宽更便宜

这里提醒一句：CDN域名和API域名要分开，不要共用一个域名。因为CDN主要为GET请求设计，而API有POST、PUT等复杂请求，两者在Nginx配置和CDN缓存策略上的要求不一样，混用会导致配置文件既繁琐又容易出现逻辑错误。

7. 复盘总结：这些经验值得记住

整套系统从需求分析到完成开发上线，我前后用了一个多月的时间。过程中踩过的坑、走过的弯路不少。如果时间倒流，我会把下面的经验告诉当时的自己：

关于架构设计 ：第一版就要规划好表结构，尤其是状态字段和索引。前期花一小时设计，后期能省一天的返工。

关于视频处理 ：转码是必然要做的事情，不要跳过。以为手机拍了MP4就能直接播是个常见误区，编码格式不统一带来的兼容问题会让你夜不能寐。提前准备好FFmpeg流水线，后面的一切都顺畅。

关于小程序适配 ：顶部导航栏高度和底部安全区适配是小程序开发的高频坑，一定不要写死样式代码。封装成工具函数统一处理，不仅当前项目复用，后续新项目也能直接借鉴。

关于后端性能 ：数据库连接池一定要配，异步任务队列一定要上，统一的异常处理一定要有。这三个看起来不起眼的细节，决定了系统上线后的稳定性和定位问题的效率。

关于微信生态 ：微信支付、跳转链接这些能力，代码本身不复杂，复杂的永远是人家的规则。开发前后一定要确认好类目资质，提前阅读最新政策，避免上线后被封功能来回折腾。

这套系统后续的方向我也在规划。基于用户观看历史和点赞记录做推荐算法，把Feed流变得更智能；接入IM做评论互动升级，让用户能实时交流感受；给创作者开发内容管理后台，支持数据分析和收益查看。这条产品演进的路还有很长。

如果你正在做类似的系统，或者正准备用这套技术栈做个视频类的个人项目，希望这些实战记录能帮你少踩一些坑。有问题欢迎评论区交流，我看到都会回复。