简介：针对Python课程期末大作业的基于WebRTC的视频会议系统项目资料包，适合计算机相关专业学生完成毕业设计或课程大作业时参考，也适合对WebRTC实时通信感兴趣的开发者借鉴整体架构。资源采用前后端分离设计，后端基于Rust语言编写，包含主程序、房间管理、错误处理等模块；前端使用Vue 3与TypeScript开发，覆盖路由、组件、视图、工具函数等核心代码。压缩包共61个文件，以Rust源文件、Vue组件、TypeScript类型定义、Markdown说明文档为主，另有Git仓库元数据、版本配置与少量图片资源，整体仅162KB，结构紧凑、便于快速阅读和二次开发。资源附带完整的项目说明与思路梳理，可帮助理解WebRTC信令交互、多房间管理与前端渲染流程；其中思路文档从整体设计到关键实现均有阐述，适合备考答辩或快速上手。目前已有212人学习下载，是低成本获得高质量期末项目方案的不错选择。

1. WebRTC视频会议系统：期末大作业里被低估的技术深度

“基于WebRTC的视频会议系统”这类python期末大作业标题，每年毕业季都能见上几十次。它看起来不像金融风控或图像分类那么唬人，可只要真正动过手的人都知道，这套东西的难度不在前端页面，而在信令服务器、NAT穿透和媒体协商三件事必须同时转起来才算跑通。python在这里扮演的角色是“把信令复杂度压缩到最薄”：用aiohttp搭建WebSocket服务，用字典维护房间，一个文件就是后端；浏览器端再配合原生WebRTC API，几百行代码就能实现双人通话。这套路线适合三类读者：想交作业但想搞懂原理的学生、想用python栈碰实时音视频的研发，以及面试前想快速恢复WebRTC记忆的社招工程师。下面按原理、实现、排错、交付四个环节逐层拆开讲。

2. WebRTC视频会议系统的原理与选型：先从“为什么用python”开始聊

2.1 视频会议系统真正传输的不是“视频”，是媒体流与协商信息

视频会议系统表面上在互传音频和图像，实际上浏览器之间建立的是端到端媒体传输。编码后的音视频由RTCPeerConnection直接发给对端，服务器只在流程早期参与交换SDP和ICE candidate。SDP是一段携带音视频编解码、传输方向和网络端口信息的文本，也就是WebRTC技术详解里常说的“协商体”；ICE candidate则是每个端点在当前网络环境中可用的候选地址，包括host、srflx、relay三类。

一次典型的媒体协商流程是：发起方本地生成offer并发送给信令服务器，服务器转发到同一个room里的接收方；接收方收到后调用setRemoteDescription，再创建answer；两端把本地收集到的candidate互相交给对方。协商完成后媒体直接走P2P，服务器退出数据通路。这个不对称非常关键：视频会议系统的服务器可以做得很薄，信令服务器只负责转发文本，不粘合媒体流。

下面这张消息参数表对应一个双人房间的最小协议，期末项目通常就是按这个协议实现后端：

消息type	字段	方向	作用
offer	sdp	呼叫方→应答方	携带本地SDP
answer	sdp	应答方→呼叫方	回应本地SDP
candidate	candidate	双方互发	持续交换ICE候选
join	room	客户端→服务端	加入房间

这个表落到python代码里，核心就是一个json.loads加type判断。为了少做字典键名解析，我在设计消息结构时把type作为顶层键，类型对不上就把整包消息打印出来排查。后面第3章的代码也按这个约定推进。

2.2 为什么信令服务器适合用python：异步、可读性与生态

信令服务器本质上是一个“收文本、转文本”的小服务，不适合用重量级框架。python在这一位置的优势主要在三处：一是asyncio的WebSocket支持让并发连接管理不需要线程池，aiohttp里一个 async for msg in ws 就完成了事件循环分发；二是代码足够短，一个.py文件能同时装下路由和消息分发，期末答辩也好讲；三是生态能覆盖后续扩展，比如aiortc可以在python侧接收媒体流做混流和录制，不需要引入第二种服务端语言。

我一般不会推荐本地开发时引入生产级信令框架，那些框架自带的序列化、鉴权、连接管理功能往往超出项目规模。反过来，aiohttp或websockets库就能覆盖整个期末项目，包括后面的局域网演示。配上Visual Studio Code里的Python扩展，环境配置难度也被压得很低，这就是很多人搜索“python安装教程”“vscode python环境配置”时最终选择这条路的原因。

如果你想让python端不只做信令转发，还要参与会议录制或转码，需要进一步了解aiortc的MediaStreamTrack抽象。但这属于扩展场景，最小实现里数据面完全由浏览器完成，python不必引用额外媒体库。

2.3 从两人会议室到多房间，python字典就是最小房间管理

“基于WebRTC的视频会议系统”并不是一对一的点对点demo，它要求能容纳多人甚至多个房间。多人时主流做法是Full Mesh，即每个参与者和其它每个终端各自建一条PeerConnection；服务端依然只管信令，不负责媒体汇合。

python端管理房间最常见的做法是用 dict[str, set[WebSocketResponse]] 保存“房间号→在线socket集合”。这个结构顺手就把createRoom和joinRoom统一成setdefault操作，dict天然就是对整个房间模型的抽象。等代码进入下一章，你会发现往多房间扩展只需要多传一个room_id，不需要任何架构级改动。

真正容易踩坑的是python类型转换：前端把对象转JSON字符串后通过WebSocket发送，后端收到的是str，必须json.loads还原；回传时用json.dumps。这个转换一旦封装得不统一，消息里夹了多余引号，或者类型变成bytes，就会在WebSocket.send时立刻报错。先在信令服务器统一好编解码函数，后面调试会省掉一半时间。

3. 用python在本地跑通WebRTC视频会议系统：信令服务器与浏览器端

3.1 先搭python运行环境：版本、venv与一个核心依赖

建议把python版本固定在3.10或更高。旧版本对asyncio API和新式类型标注支持不够好，没必要在期末阶段跟版本纠缠。需要安装的依赖只有一个：aiohttp，它自带WebSocket服务端支持。

mkdir webrtc_room && cd webrtc_room
python3 -m venv .venv
source .venv/bin/activate
pip install aiohttp==3.9.5

第一行创建项目目录，第二行建立虚拟环境，第三行激活它，第四行安装指定版本的aiohttp。固定aiohttp版本是为了保证后面代码里的API签名一致，避免升级带来的破坏性变更。在VSCode里操作时，按 Ctrl+Shift+P 打开命令面板，选择“Python: Select Interpreter”，指向 .venv 路径，这样编辑器提示和终端运行环境才会统一。

本地开发阶段直接用 http://localhost:8000 访问页面，浏览器会把localhost视为安全上下文，摄像头权限可以正常申请。如果换成局域网IP访问，页面会报NotAllowedError，这一点在第四章排错里再展开。

3.2 用aiohttp写一个信令服务器：一份可跑的server.py与参数说明

下面的server.py是完整最小实现，支持多房间，也支持每个房间内多人互相转发信令消息。

import json
from typing import Dict, Set
from aiohttp import web, WSMsgType

rooms: Dict[str, Set[web.WebSocketResponse]] = {}

async def handler(request: web.Request) -> web.WebSocketResponse:
    room_id = request.match_info["room_id"]
    ws = web.WebSocketResponse(heartbeat=30)
    await ws.prepare(request)

    rooms.setdefault(room_id, set()).add(ws)

    try:
        async for msg in ws:
            if msg.type != WSMsgType.TEXT:
                continue
            data = json.loads(msg.data)  # str -> dict，统一接收格式
            for client in list(rooms[room_id]):
                if client is ws:
                    continue
                await client.send_json(data)  # 原样转发给房间内其它人
    finally:
        rooms[room_id].discard(ws)
        if not rooms[room_id]:
            del rooms[room_id]

    return ws

app = web.Application()
app.router.add_get("/room/{room_id}", handler)
web.run_app(app, port=8000)

逻辑上的关键点有三个。 rooms.setdefault(room_id, set()).add(ws) 同时完成“创建房间”和“加入房间”两个动作，set结构保证同一个socket不会被重复添加。 async for msg in ws 是aiohttp的WebSocket消息循环，每次循环拿到一条完整消息。 client.send_json(data) 会自动执行json.dumps，把dict序列化成字符串再发给对端，这正好呼应了前面说的python类型转换问题。

可选参数方面， heartbeat=30 让服务器每30秒发一次心跳帧，对端掉线时能及时发现。 port=8000 可换，但要注意后面的前端WebSocket地址要同步修改。启动方式是在项目目录里执行 python server.py ，看到“Running on http://0.0.0.0:8000”就说明信令服务器已经就绪。

3.3 浏览器端WebRTC客户端：getUserMedia与RTCPeerConnection核心逻辑

浏览器端是视频会议系统的真正重头，所有媒体采集和传输都发生在这一侧。先看最关键的两段JavaScript。

第一段是创建PeerConnection和本地媒体流：

const rtcConfig = {
  iceServers: [
    { urls: "stun:stun.l.google.com:19302" }
  ]
};

let pc = new RTCPeerConnection(rtcConfig);
const localStream = await navigator.mediaDevices.getUserMedia({
  video: { width: { ideal: 1280 }, height: { ideal: 720 } },
  audio: true
});
localStream.getTracks().forEach(track => pc.addTrack(track, localStream));
localVideo.srcObject = localStream;

iceServers 里的STUN地址负责帮浏览器发现公网地址。 getUserMedia 返回的流通过 addTrack 逐个塞进PeerConnection，这样对端才能通过 ontrack 事件拿到媒体流。分辨率参数写成 ideal: 1280 表示理想值，浏览器会根据带宽自动降级，比写死 1920x1080 更稳妥。

第二段是信令消息的收发，也就是offer、answer和candidate的完整闭环：

pc.ontrack = e => { remoteVideo.srcObject = e.streams[0]; };

pc.onicecandidate = e => {
  if (e.candidate) {
    ws.send(JSON.stringify({ type: "candidate", candidate: e.candidate }));
  }
};

ws.onmessage = async e => {
  const msg = JSON.parse(e.data);
  if (msg.type === "offer") {
    await pc.setRemoteDescription(msg.sdp);
    const answer = await pc.createAnswer();
    await pc.setLocalDescription(answer);
    ws.send(JSON.stringify({ type: "answer", sdp: pc.localDescription }));
  } else if (msg.type === "answer") {
    await pc.setRemoteDescription(msg.sdp);
  } else if (msg.type === "candidate") {
    try {
      await pc.addIceCandidate(msg.candidate);
    } catch (err) {
      console.warn("candidate到达但尚未setRemote", err);
    }
  }
};

async function startCall(role) {
  if (role === "caller") {
    const offer = await pc.createOffer();
    await pc.setLocalDescription(offer);
    ws.send(JSON.stringify({ type: "offer", sdp: pc.localDescription }));
  }
}

注意 setRemoteDescription 和 createAnswer 的顺序不能颠倒，浏览器必须先知道对方的SDP才能生成匹配的answer。调用 addIceCandidate 时，如果candidate到达时remote description还没设置，浏览器会抛错，所以catch里的提示信息很有用。最后用 role 区分发起方和应答方：发起方主动createOffer，应答方收到offer后被动createAnswer。

4. WebRTC视频会议系统排查手册：三次握手失败先查哪一项

4.1 getUserMedia没有画面：域名的锅比代码多

运行前先确认页面地址栏必须是 http://localhost 或HTTPS。浏览器把localhost视为安全上下文，允许调摄像头；换成局域网IP或 file:// 直接打开HTML，getUserMedia会直接返回NotAllowedError，代码逻辑再正确也没有画面。

临时处理办法是给信令服务器加上HTTPS支持，让同一套服务同时提供页面和WebSocket：

openssl req -x509 -newkey rsa:2048 -nodes -days 365 \
  -keyout key.pem -out cert.pem -subj "/CN=localhost"

然后把server.py的启动部分改为：

import ssl
ssl_ctx = ssl.create_default_context(ssl.Purpose.CLIENT_AUTH)
ssl_ctx.load_cert_chain("cert.pem", "key.pem")
web.run_app(app, port=8000, ssl_context=ssl_ctx)

此时前端页面要用 https://localhost:8000 访问，WebSocket地址也要改成 wss:// 。第一次访问时浏览器会提示证书不受信任，点“继续前往”即可，自签证书仅用于本地开发，不推荐在正式环境使用。

4.2 房间能进，但对面画面一直黑屏

黑屏是WebRTC调试里最高频的问题，按以下顺序排查往往比瞎猜更快。第一步打开 chrome://webrtc-internals ，这是Chrome内置的WebRTC监控工具，能直接看到每条PeerConnection的状态。第二步看 RTCIceCandidatePair 区域，找到 nominated 为true的候选对，如果不存在就说明两端还没有成功打通网络路径。第三步确认 ontrack 回调是否执行，多数黑屏其实是 remoteVideo.srcObject 赋值时机太晚，或者track数据压根没到达。

常见误用是把 remoteVideo.srcObject 写在某个按钮的事件回调里，但服务端转发媒体流的时机不受按钮控制。正确的做法是在 pc.ontrack 里拿到 event.streams[0] 后立即赋值，同时检查 remoteVideo.play() 是否被调用，自动播放策略可能把已加载的流挂起在暂停状态。

4.3 ICE candidates收集失败与STUN/TURN配置

信令服务器正常但candidate始终收集不到，先查iceServers配置。下面几个公共STUN地址可以直接替换到代码里测试：

服务商	地址	适合场景
Google	stun:stun.l.google.com:19302	通用测试，国内外均可尝试
腾讯云	stun:stun.cloud.tencent.com:3478	国内网络环境较稳定
阿里云	stun:stun.aliyun.com:3478	国内网络环境备用

STUN只能解决公网地址发现，无法处理对称NAT。如果视频会议系统要在不同Wi-Fi或校园网环境里演示，需要同时配置TURN服务器做中继。自建TURN最常用的方案是coturn，Docker方式一条命令即可启动：

docker run -d --name coturn \
  -p 3478:3478/udp -p 3478:3478 \
  -e TURN_USERNAME=room -e TURN_PASSWORD=room_pass \
  coturn/coturn

然后把前端rtcConfig改成：

const rtcConfig = {
  iceServers: [
    { urls: "stun:stun.l.google.com:19302" },
    {
      urls: "turn:你的服务器IP:3478",
      username: "room",
      credential: "room_pass"
    }
  ]
};

加了TURN以后，媒体数据会经过服务器中转，延迟稍高但连通率大幅提升。期末演示环境建议提前用手机热点和校园网各测一次，确认relay类型candidate能被正常收集。

5. 让视频会议系统更像产品：多房间、录制与部署

5.1 多房间与角色分离的补全思路

前面server.py已经天然支持多房间，但前端还需要补一个“是否已在房间中”的判断，来决定自己是offer方还是answer方。更接近真实会议的方案是加入房间角色：第一个进入房间的人成为主持人，后续加入者全部作为answer方。这个逻辑用一个 isInitiator 布尔值就能驱动，不需要改动信令服务器。

5.2 用MediaRecorder做本地录制，留底不转码

浏览器录制WebRTC媒体流最简单的方式是MediaRecorder，核心参数如下：

const remoteStream = remoteVideo.srcObject;
const rec = new MediaRecorder(remoteStream, {
  mimeType: "video/webm;codecs=vp8,opus",
  videoBitsPerSecond: 1_000_000
});
const chunks = [];
rec.ondataavailable = e => chunks.push(e.data);
rec.onstop = () => {
  const blob = new Blob(chunks, { type: "video/webm" });
  const url = URL.createObjectURL(blob);
  const a = document.createElement("a");
  a.href = url;
  a.download = "meeting.webm";
  a.click();
};
rec.start(1000);

start(1000) 里的1000表示每隔1秒触发一次 ondataavailable ，防止录制时间太长导致内存积压。 videoBitsPerSecond 控制码率，1Mbps在720p会议场景下清晰度足够。

5.3 部署前检查：HTTPS与防火墙

期末答辩通常在教室局域网进行，需要把服务部署到一台机器上让其它人访问。此时必须处理两件事：一是用自签HTTPS替代HTTP，让所有访问者的getUserMedia能正常工作；二是在Nginx里为WebSocket配置 Upgrade 头，否则Nginx会把WebSocket请求当成普通HTTP请求直接断开。把下面这段放进Nginx的server块， /room/ 路径就会走WebSocket代理：

location /room/ {
    proxy_pass http://127.0.0.1:8000;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_read_timeout 3600s;
}

如果同时部署了coturn，记得在防火墙里放行UDP 3478端口，不然TURN中继流量会被系统默认策略丢弃。把Nginx配置和防火墙规则都改完后，在教室环境下用三台电脑分别进入同一个房间，确认每对终端都能看到两路视频，这套期末大作业就可以从localhost挪到演示环境里继续跑了。

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