Vue 与 WebRTC 音视频直播：从信令到调优实战

音视频直播这块，我从早年的 Flash 加 RTMP 一路做到现在的 WebRTC，说句实在话，真正让前端开发者觉得"门槛降下来了"的，是 Vue 和 WebRTC 这两样东西凑一起的时候。以前做直播，前端基本只负责放个播放器，推流、转码、分发全在后端和一堆媒体服务器里绕，前端能碰的东西很少。而 WebRTC 把采集、编码、传输、渲染这一整条链路都塞进了浏览器，Vue 又刚好把组件化、响应式、生命周期这套东西做得足够顺手，两者结合，一个前端工程师就能独立搭出一套可用的实时音视频直播 Demo，甚至小规模生产应用。

这篇内容我打算聊的是：用 Vue 做界面与状态管理、用 WebRTC 做点对点或小规模多人音视频直播的完整实现思路。核心关键词就是 Vue、WebRTC、音视频直播，适合已经会一点 Vue 基础、想往实时音视频方向摸一摸的开发者，也适合做了几年业务、想补上 WebRTC 这块短板的老手。整篇会从方案选型、环境搭建、核心链路、参数调优一路讲到排错实录，尽量把每一步"为什么要这么干"讲清楚，而不是丢一堆 API 让你自己猜。

1. 选型之前：Vue 和 WebRTC 各自在直播链路里干什么

很多人一上来就写代码，结果写到一半发现架构错了，得推倒重来。所以先把"谁负责什么"这件事理清楚，后面少走一大半弯路。

1.1 WebRTC 到底解决了哪些问题

WebRTC 的全称是 Web Real-Time Communication，翻译过来就是网页实时通信。它最核心的价值是：浏览器原生支持音视频采集、编解码、网络传输，不需要装插件、不需要额外客户端。在直播场景里，它主要承担四件事。

第一件是媒体采集。通过navigator.mediaDevices.getUserMedia()拿到摄像头和麦克风的音视频流，这是所有直播的起点。第二件是编解码。视频用 VP8、VP9、H.264、AV1，音频用 Opus，浏览器内部完成，你不用自己实现编码器。第三件是网络传输。这里用的是 SRTP 加密传输，配合 ICE 框架做网络地址协商，能在复杂的网络环境里找到一条能通的路。第四件是渲染。把远端来的流塞进<video>标签，浏览器自己解码播放，一行srcObject就搞定。

这四件事里，真正难的是第三件。采集和渲染是 API 调用，编解码是浏览器内功，只有网络传输会因为用户处在不同的网络环境（公司内网、家用宽带、移动蜂窝）而千变万化。后面第 5 章讲排查，大部分坑其实都出在这一块。

注意：WebRTC 默认要求 HTTPS 或 localhost 环境，HTTP 域名下getUserMedia会直接报错，开发阶段用localhost可以绕过，上线必须配证书。

1.2 Vue 在直播项目里承担的角色

有人会问，用原生 JS 不也能写 WebRTC 吗？当然能，但一旦直播涉及多人、涉及房间、涉及设备切换，状态管理就会爆炸。Vue 在这里的价值主要体现在三个层面。

组件化拆解。一个完整的直播页面通常包含：本地预览区、远端画面区、房间控制栏、设备选择器、消息面板。用 Vue 拆成独立组件后，每个组件只关心自己的渲染逻辑，PeerConnection这种有状态的对象可以单独抽成 composable 或 service 层，不跟 UI 混在一起。

响应式状态同步。连接状态（connecting/connected/failed）、成员列表、静音状态、摄像头开关，这些都是典型的"数据变了 UI 要跟着变"。用 Vue 的ref、reactive管理，比手动操作 DOM 省心太多。比如远端成员加入或离开，只要改动成员数组，画面区域自动增删，不需要写一堆appendChild。

生命周期绑定。WebRTC 连接是有生命周期的：创建、协商、连接、断开、销毁。Vue 组件的onMounted、onUnmounted刚好能对应上，组件卸载时自动关闭连接、释放摄像头，避免资源泄漏。这一点在单页应用里尤其重要，切换路由不清理，摄像头指示灯会一直亮着。

1.3 三种直播链路，先确定你要哪一种

在动手之前，先想清楚你的直播属于哪一类，因为这直接决定架构。

直播类型	典型场景	延迟	推荐方案
一对一通话	客服、远程协助	100ms 以内	纯 P2P WebRTC
小房间多人	在线会议、连麦	200ms 以内	WebRTC + SFU
大并发直播	秀场、教育大班课	1-3s	WebRTC 推流 + CDN 分发

一对一最简单，直接 P2P，两个浏览器协商好就通了，服务端只需要一个信令服务器牵线。小房间多人（一般 6 人以内）也能用 P2P 组网，但每个客户端要维持N-1条连接，上行带宽压力大，超过 6 人基本就得引入 SFU（Selective Forwarding Unit，选择性转发单元），每个客户端只上传一路流到服务器，服务器负责分发。大并发直播则是 WebRTC 负责低延迟推流到边缘节点，再由 CDN 做大规模分发，这时候前端其实就是个"推流端 + 拉流端"的组合。

我下面讲的实现，以一对一 P2P + 小房间可扩展为主线，这套骨架理解透了，往上叠 SFU 也好，接 CDN 也好，都不会太吃力。

2. 项目骨架搭建：Vue 工程与信令服务

环境这块我不打算罗列一堆版本号就完事，而是想说清楚每一个依赖为什么装、每一个目录为什么这么分。

2.1 Vue 工程初始化与依赖取舍

推荐用 Vite 初始化 Vue 3 项目，命令是npm create vue@latest，或者直接用npm create vite@latest my-live -- --template vue。为什么选 Vite 不选 Webpack？因为 WebRTC 项目在开发阶段会频繁改代码、频繁热更新，Vite 的冷启动和 HMR 速度在这种"边调边测"的场景里体感差别很明显，尤其你要反复在真实摄像头下测试的时候。

依赖方面其实很轻量。Vue 3 本身、一个 UI 库（Element Plus 或 Naive UI，看你习惯）、一个信令用的 WebSocket 客户端（原生WebSocket就够，不用引 socket.io，除非你需要自动重连和房间广播这些高级特性）。不需要装任何 WebRTC 的 npm 包，因为浏览器原生支持，装了反而是多余的封装。这一点和 Vue 2 时代的一些老教程不一样，那时候有人会用webrtc-adapter做兼容，现在现代浏览器基本不需要，只有在要兼容老旧环境时才考虑。

npm create vite@latest vue-webrtc-live -- --template vue cd vue-webrtc-live npm install npm install element-plus npm run dev

2.2 为什么信令服务必须单独搭

这是新手最容易困惑的点：WebRTC 不是点对点吗，为什么还要服务器？

要理解这件事，可以把 WebRTC 建立连接想象成两个人打电话。你光知道对方的名字没用，你得知道他的电话号码，而且双方得同时在线、同时拿起话筒。WebRTC 的两个浏览器之间就是这种关系：它们需要先交换"我是谁、我在哪、我支持什么编码格式"这些信息，这个交换过程就叫信令。而信令本身，WebRTC 标准里根本没有规定用什么协议，你可以用 WebSocket、可以用 HTTP 轮询、甚至可以用邮件（虽然不现实），所以这部分必须自己实现。

信令要传的东西主要有三类：

• SDP（Session Description Protocol）：描述这次会话的媒体信息，包括编解码器、分辨率、加密方式。发起方生成 offer，接收方回应 answer。
• ICE Candidate：候选的网络地址，每发现一个可能的连接路径就发一个，双方互相试探哪条能通。
• 业务信令：房间加入、成员列表、挂断通知这些自定义消息。

信令服务器只负责转发，不碰音视频数据，所以负载很轻。我用 Node.js 起一个 WebSocket 服务，几十行代码就能用。

// server/signaling.js import { WebSocketServer } from 'ws'; const wss = new WebSocketServer({ port: 8080 }); const rooms = new Map(); wss.on('connection', (ws) => { ws.on('message', (raw) => { const msg = JSON.parse(raw); if (msg.type === 'join') { const { roomId, userId } = msg; if (!rooms.has(roomId)) rooms.set(roomId, new Map()); const room = rooms.get(roomId); // 把已有成员告诉新来的 ws.send(JSON.stringify({ type: 'members', list: [...room.keys()] })); room.set(userId, ws); broadcast(room, { type: 'peer-joined', userId }, userId); } if (msg.type === 'offer' || msg.type === 'answer' || msg.type === 'candidate') { const room = rooms.get(msg.roomId); const target = room?.get(msg.targetId); if (target && target.readyState === 1) { target.send(JSON.stringify({ ...msg, fromId: msg.fromId })); } } }); ws.on('close', () => { rooms.forEach((room, roomId) => { room.forEach((conn, userId) => { if (conn === ws) { room.delete(userId); broadcast(room, { type: 'peer-left', userId }); if (room.size === 0) rooms.delete(roomId); } }); }); }); }); function broadcast(room, data, excludeId) { const text = JSON.stringify(data); room.forEach((conn, userId) => { if (userId !== excludeId && conn.readyState === 1) conn.send(text); }); } console.log('信令服务运行在 8080');

这段代码很朴素，但逻辑完整：加入房间、同步成员、转发协商消息、处理断开。生产环境你还得加上心跳保活、重连、鉴权，但骨架就是这个。

2.3 目录结构怎么划分才不乱

我见过太多 WebRTC 项目把所有逻辑堆在一个.vue文件里，写到后面 800 行，改一处崩三处。合理的分层应该是这样：

src/ ├── components/ │ ├── LocalVideo.vue # 本地预览 │ ├── RemoteVideo.vue # 远端画面 │ └── ControlBar.vue # 开关控制 ├── composables/ │ ├── useMediaDevices.js # 设备枚举与切换 │ └── usePeerConnection.js# 连接管理核心 ├── services/ │ └── signaling.js # 信令客户端封装 ├── stores/ │ └── liveStore.js # Pinia 状态 └── views/ └── LiveRoom.vue # 页面组装

核心思想是：UI 归 UI，状态归状态，连接逻辑独立成 composable。这样测试的时候，连接逻辑可以脱离界面单独跑，排查问题也能快速定位是渲染层还是连接层的问题。

3. 核心链路实现：从打开摄像头到看见对方

这一章是重头戏，我把从采集到播放的完整流程拆成几段，每段都说明白为什么这么写。

3.1 媒体采集：约束参数怎么定

采集的第一原则是：能不加约束就不加，需要精确控制再逐个加。因为约束越复杂，不同设备的行为差异越大，反而容易出问题。

// composables/useMediaDevices.js import { ref } from 'vue'; export function useMediaDevices() { const localStream = ref(null); const devices = ref([]); async function startCapture(options = {}) { const constraints = { audio: { echoCancellation: true, // 回声消除，通话必开 noiseSuppression: true, // 噪声抑制 autoGainControl: true, // 自动增益 sampleRate: 48000, }, video: { width: { ideal: 1280 }, height: { ideal: 720 }, frameRate: { ideal: 30, max: 30 }, facingMode: 'user', // 前置摄像头，移动端常用 }, }; const stream = await navigator.mediaDevices.getUserMedia(constraints); localStream.value = stream; return stream; } async function listDevices() { const all = await navigator.mediaDevices.enumerateDevices(); devices.value = all.filter(d => d.kind === 'videoinput' || d.kind === 'audioinput'); return devices.value; } function stopCapture() { localStream.value?.getTracks().forEach(track => track.stop()); localStream.value = null; } return { localStream, devices, startCapture, listDevices, stopCapture }; }

这里有几个点值得展开。为什么用ideal而不是exact？exact是硬性要求，达不到会直接抛错；ideal是期望值，设备不支持会自动降级到最接近的分辨率。直播场景里用户的摄像头千奇百怪，用ideal容错率高得多。为什么音频要开 echoCancellation？因为直播里最常见的灾难就是回声，对方的声音从你的扬声器出来又被你的麦克风收进去，来回震荡，体验极差，浏览器原生的回声消除效果已经很不错，一定要开。

还有一个坑：enumerateDevices在未授权前拿到的deviceId是空的。必须先调一次getUserMedia拿到权限，再枚举，才能拿到真实的设备 ID。这个顺序错了，设备列表就是一片空白。

提示：移动端浏览器切到后台会暂停摄像头采集，回来时需要重新获取流，记得监听visibilitychange事件做恢复。

3.2 创建连接：RTCPeerConnection 的完整流程

RTCPeerConnection是整个 WebRTC 的心脏。它的使用流程可以总结成一条固定套路，记住了基本不会错。

// composables/usePeerConnection.js import { ref } from 'vue'; export function usePeerConnection(iceServers) { const pc = ref(null); const remoteStream = ref(new MediaStream()); const connectionState = ref('new'); function create() { pc.value = new RTCPeerConnection({ iceServers, // 例如 [{ urls: 'stun:stun.l.google.com:19302' }] iceCandidatePoolSize: 10, }); // 收到远端流，交给 UI 渲染 pc.value.ontrack = (event) => { event.streams[0].getTracks().forEach(track => { remoteStream.value.addTrack(track); }); }; pc.value.oniceconnectionstatechange = () => { connectionState.value = pc.value.iceConnectionState; }; return pc.value; } function addLocalTracks(stream) { stream.getTracks().forEach(track => { pc.value.addTrack(track, stream); }); } async function createOffer() { const offer = await pc.value.createOffer(); await pc.value.setLocalDescription(offer); return offer; } async function acceptOffer(offer) { await pc.value.setRemoteDescription(new RTCSessionDescription(offer)); const answer = await pc.value.createAnswer(); await pc.value.setLocalDescription(answer); return answer; } async function acceptAnswer(answer) { await pc.value.setRemoteDescription(new RTCSessionDescription(answer)); } async function addCandidate(candidate) { if (candidate) await pc.value.addIceCandidate(new RTCIceCandidate(candidate)); } function close() { pc.value?.close(); pc.value = null; remoteStream.value = new MediaStream(); } return { pc, remoteStream, connectionState, create, addLocalTracks, createOffer, acceptOffer, acceptAnswer, addCandidate, close, }; }

这套流程的"为什么"是这样的：addTrack必须在createOffer之前调用，否则 offer 里根本不含媒体信息，对方什么也收不到。setLocalDescription必须在createOffer之后立刻调用，因为 ICE 候选的收集是在拿到本地描述之后才开始的，顺序错了候选就收集不全。

iceServers的配置也很关键。STUN 服务器负责让双方发现自己的公网地址，提示一下：公共的 STUN 服务虽然方便测试，但在有些网络环境下会返回不准确的地址，自己搭一个或者用云服务商提供的会更靠谱。如果双方都在严格的对称型 NAT 后面，光靠 STUN 打不通，就需要上 TURN 中继服务器做流量转发，这部分要用带宽换连通性，成本得提前算进预算。

3.3 信令交互：把 SDP 和 Candidate 串起来

连接建立是双方协同的过程，顺序不能乱。发起方（offer 方）和接收方（answer 方）的流程我列成表，照着走就行。

步骤	发起方	接收方
1	创建 pc、添加本地轨道	创建 pc、添加本地轨道
2	createOffer + setLocalDescription	等待
3	发送 offer	收到 offer，setRemoteDescription
4	等待	createAnswer + setLocalDescription
5	收到 answer，setRemoteDescription	发送 answer
6	收集到 candidate 就发送	收集到 candidate 就发送
7	收到对方 candidate 就 addIceCandidate	同左

在 Vue 里，我把这套逻辑和信令客户端绑定：

// services/signaling.js export class SignalingClient { constructor(url) { this.ws = new WebSocket(url); this.handlers = new Map(); } on(type, fn) { this.handlers.set(type, fn); } send(data) { if (this.ws.readyState === WebSocket.OPEN) { this.ws.send(JSON.stringify(data)); } } connect(onOpen) { this.ws.onopen = () => onOpen?.(); this.ws.onmessage = (e) => { const msg = JSON.parse(e.data); this.handlers.get(msg.type)?.(msg); }; this.ws.onclose = () => console.warn('信令连接已关闭'); } }

然后在业务层把信令事件和 pc 操作对应起来：收到offer就acceptOffer并回发 answer，收到candidate就addCandidate。这里有个容易被忽略的点——offer 和 candidate 可能乱序到达。如果 candidate 先到而远端描述还没设置，addIceCandidate会报错。稳妥的做法是用一个队列，把早到的候选缓存起来，等setRemoteDescription完成后再统一添加。

3.4 在 Vue 组件里管理连接生命周期

组件卸载时必须清理，否则连接残留、摄像头不关。这是我最想强调的一处工程习惯。

// views/LiveRoom.vue 中的 script setup 部分 import { onMounted, onUnmounted, ref } from 'vue'; import { useMediaDevices } from '@/composables/useMediaDevices'; import { usePeerConnection } from '@/composables/usePeerConnection'; import { SignalingClient } from '@/services/signaling'; const { localStream, startCapture, stopCapture } = useMediaDevices(); const { remoteStream, create, addLocalTracks, createOffer, acceptOffer, acceptAnswer, addCandidate, close } = usePeerConnection([ { urls: 'stun:stun.l.google.com:19302' }, ]); let signaling = null; const pendingCandidates = []; onMounted(async () => { const stream = await startCapture(); signaling = new SignalingClient('ws://localhost:8080'); signaling.connect(() => { signaling.send({ type: 'join', roomId: 'demo', userId: 'me' }); }); signaling.on('peer-joined', async () => { create(); addLocalTracks(stream); const offer = await createOffer(); signaling.send({ type: 'offer', offer, targetId: 'peer', fromId: 'me' }); }); signaling.on('offer', async (msg) => { create(); addLocalTracks(stream); const answer = await acceptOffer(msg.offer); signaling.send({ type: 'answer', answer, targetId: msg.fromId, fromId: 'me' }); }); signaling.on('answer', async (msg) => { await acceptAnswer(msg.answer); // 冲刷早到的候选 while (pendingCandidates.length) { await addCandidate(pendingCandidates.shift()); } }); signaling.on('candidate', async (msg) => { if (!pc.value?.remoteDescription) { pendingCandidates.push(msg.candidate); } else { await addCandidate(msg.candidate); } }); }); onUnmounted(() => { stopCapture(); close(); signaling?.ws?.close(); });

这段代码里，onUnmounted做三件事：停采集、关连接、断信令。顺序别搞反，先停采集再关连接，避免在关闭过程中还有轨道数据往里写。这个习惯在多页面应用里能省掉大量"切了页面摄像头还亮着"的诡异问题。

4. 画质、带宽与延迟：参数调优的取舍逻辑

能跑通只是一半，真正决定体验的是参数调优。这一章我讲几个关键参数背后的原理。

4.1 视频编码参数的设定逻辑

WebRTC 默认会自动调整码率，但你可以通过RTCRtpSender.setParameters干预：

async function tuneBitrate(pc, maxBitrate) { const sender = pc.getSenders().find(s => s.track?.kind === 'video'); if (!sender) return; const params = sender.getParameters(); if (!params.encodings || params.encodings.length === 0) { params.encodings = [{}]; } params.encodings[0].maxBitrate = maxBitrate; // 单位 bps params.encodings[0].maxFramerate = 30; // 优先保帧率还是保清晰度，用降级偏好控制 params.degradationPreference = 'balanced'; await sender.setParameters(params); }

这里的计算过程值得说明。假设你要传 720p@30fps，经验码率大约是分辨率像素数乘以每像素比特数和帧率再除以压缩比，简化估算下来 720p（1280×720 ≈ 92 万像素）常用码率区间在 1500kbps 到 2500kbps 之间；如果升到 1080p（约 207 万像素），码率大致翻倍到 3000kbps 到 4500kbps。这不是精确公式，而是工程经验值，实际还要看画面复杂度——静止的人像和快速运动的场景，同样的分辨率码率需求能差一倍以上。

degradationPreference这个参数特别重要，它决定带宽不足时牺牲谁。设成maintain-framerate会优先保帧率、降分辨率，画面流畅但会糊；设成maintain-resolution则保清晰度、降帧率，画面清楚但会卡顿。直播连麦一般选前者，因为人对卡顿更敏感；展示文档、屏幕共享选后者更合适。

4.2 带宽估计与动态降码率

WebRTC 内部有一套拥塞控制机制，会根据丢包和延迟动态调整发送码率，它用的算法会计算链路的可用容量，估算结果是动态浮动的。前端能做的辅助优化有两点：一是监听getStats()拿到实时数据，二是在界面给出画质档位让用户手动兜底。

async function monitorStats(pc) { const stats = await pc.getStats(); stats.forEach(report => { if (report.type === 'inbound-rtp' && report.kind === 'video') { console.log('接收码率参考', report.bytesReceived); console.log('丢包数', report.packetsLost); console.log('抖动', report.jitter); } }); }

我一般会定时（比如每 3 秒）拉一次统计，如果丢包率持续超过 5%，就主动调低maxBitrate，或者引导用户切换到音频优先模式。实测下来，与其等浏览器自己慢慢降，不如在丢包刚起来的时候主动介入，用户体验会好很多。

4.3 音频处理的取舍

音频这块，我建议默认全开三项：回声消除、噪声抑制、自动增益。但有两个例外场景要注意。

一是音乐直播。如果主播是在唱歌、弹奏乐器，噪声抑制和自动增益会破坏音质，把音乐的动态范围压扁，这时候应该关掉这两个，只留回声消除。用applyConstraints动态切换：

async function switchToMusicMode(stream) { const audioTrack = stream.getAudioTracks()[0]; await audioTrack.applyConstraints({ echoCancellation: true, noiseSuppression: false, autoGainControl: false, }); }

二是音频码率。默认 Opus 是自适应码率，通话场景够用，但如果要传高保真音乐，需要手动指定更高的码率，通过 SDP 修改或setParameters调整maxBitrate，一般音乐场景建议给到 96kbps 以上，通话场景 32kbps 左右就够了。

5. 常见问题与排查实录

这一章全是踩坑经验，也是我认为最值钱的部分。WebRTC 的问题往往没有明确报错，只能靠一套系统的方法逐步缩小范围。

5.1 画面黑屏、只有声音、完全连不上

这三类现象覆盖了绝大多数初次调试的问题，我按概率从高到低列出来。

黑屏但有声音，通常是视频轨道没加上，或者加上了但没渲染。先确认pc.getSenders()里有没有 video 类型的 sender，再看<video>标签的srcObject有没有赋值，还要检查autoplay和playsinline属性——移动端 Safari 不写playsinline会强制全屏，看起来就像没渲染。

只有画面没声音，多半是自动播放策略导致的。浏览器要求媒体播放必须有用户交互，要么加muted属性先静音播放，要么等用户点一下再播。这在直播里很常见，一个"点击进入房间"的按钮其实就是在解决这个问题。

完全连不上，先看pc.iceConnectionState，如果是failed，八成是网络地址没打通。这时候要分情况：同一个局域网内应该能直连，跨公网连不上大概率需要 TURN 中继。排查方法是用getStats()看candidate-pair的状态，找到nominated为 true 的那对，看它的state是不是succeeded。

5.2 网络环境相关的疑难杂症

不同网络环境的表现差异极大，我整理了一张速查表，对照着排。

现象	可能原因	排查方向
内网正常，公网失败	缺少 TURN 中继	检查网络地址协商日志
连接时好时坏	候选地址不稳定	增加 ICE 服务器数量
连上后几秒断开	心跳超时或候选过期	检查保活机制
画面卡顿但音频正常	视频码率过高	调低 maxBitrate
双方都在移动网络下失败	对称型网络限制	必须上 TURN 中继

这里想强调一句：别迷信"公网 STUN 免费用"。公共 STUN 服务在高峰期响应慢甚至丢包，会拖长连接建立时间。如果项目要上线，自己部署一套 STUN 和 TURN 是值得的投入，成本不高，但连接成功率提升明显。

5.3 Vue 层面的专属坑

WebRTC 本身的问题排完，还有一批坑是 Vue 特有的。

响应式包裹了 pc 对象。RTCPeerConnection是一个复杂的原生对象，如果你用reactive()去包裹它，Vue 的 Proxy 会代理它的内部属性和方法，导致调用addIceCandidate时this指向错误，报各种奇怪的错。正确做法是用shallowRef或者直接存在普通变量里，不要用reactive包 WebRTC 原生对象。

<video>的 ref 拿到太晚。如果你在onMounted里立刻给videoEl.srcObject赋值，但此时 DOM 可能还没完全挂载，会赋不上。稳妥做法是nextTick之后再操作，或者用watch监听流的变化再赋值。

热更新导致连接残留。Vite 的 HMR 在改动代码时会重新执行模块，但不会触发onUnmounted，于是摄像头和连接就一直挂着。解决方法是开发阶段把清理逻辑也写进import.meta.hot.dispose里，或者手动刷新页面。这个坑我踩了好几次，桌面上一堆摄像头被占用的提示。

Vue 相关问题	表现	解决
pc 被 reactive 包裹	方法调用报错	改用 shallowRef
videoEl 赋值时机错	画面不显示	nextTick 后赋值
HMR 未清理	摄像头一直占用	手动刷新或加 dispose
组件切换未卸载	连接泄漏	onUnmounted 强制清理

6. 上线前的收尾与个人补充

功能跑通之后到真正能用，中间还有一段距离。我自己在项目里会重点检查三件事：一是权限降级处理，用户拒绝摄像头权限时要有明确的引导文案，而不是白屏；二是弱网兜底，检测到持续高丢包时主动降档或提示切换；三是资源回收，反复进出房间多次后，用chrome://webrtc-internals这个诊断页面看有没有连接残留，正常情况下关闭后应该全部释放。

关于扩展方向，如果人数超过 6 个，就得上 SFU，推荐的开源方案可以搜一下 mediasoup、Janus、LiveKit 这几个，它们的思路都是"客户端只推一路流给服务器，服务器选择性转发"，前端改动其实不大，主要是把RTCPeerConnection对端的角色从"另一个浏览器"换成"媒体服务器"。如果要做超大规模直播，则是 WebRTC 负责低延迟上行，接一层转码和 CDN 分发，前端变成推流端加普通播放器的组合，这部分和纯 P2P 的思路就完全分开了。

最后分享一个我调试时的小习惯：浏览器地址栏输入chrome://webrtc-internals，打开这个页面之后再开始你的直播流程，它会详细记录每一次连接的所有事件、SDP 内容、候选地址、统计曲线。绝大多数"怎么连不上""为什么卡"的问题，答案都在这里面，比在代码里打console.log高效得多。养成这个习惯之后，我在处理连接类问题时基本能做到心里有数，而不是靠猜。