产品场景
WetRTC 是框架无关的 P2P WebRTC 连接库：信令解耦、Perfect Negotiation、媒体 / DataChannel / Stats 一体化。它适合「自建信令 + 浏览器或 Electron 点对点实时连接」，而不是开箱即用的多人会议云或 SFU 媒体服务器。
一句话定位
自己掌控信令与数据路径的 P2P 实时连接引擎——适合 1 到少数端、局域网或可控网络、屏幕 / 摄像头 / 文件传输，且不想被某家 RTC 公有云绑死的产品。
非常适合
屏幕共享 / 投屏 / 副屏
- Electron 或浏览器采集屏幕，
sendonly推流；手机 / Webrecvonly观看 - 局域网扫码连接、会议室投屏、工控屏远程查看、扩展显示器
- monorepo 内 virt-screen 集成示例 即为该场景的参考实现（Parsec VDD 虚拟屏 + Socket.IO 信令 + 低延迟调优）
1 对 1 实时音视频
- 视频客服、在线问诊、1v1 辅导、远程协助
- 使用
sendrecv或sendonly/recvonly组合，信令走自建的 WebSocket / Socket.IO
Electron 桌面端 + Web / 移动端
- 桌面负责采集、驱动或本地能力；Web / 手机负责观看或对讲
- 库不绑定 Vue / React，可在 Electron 渲染进程直接使用
带消息与文件的 P2P 应用
- 内置 DataManager 与文件分片传输
- 远程协助传日志、传截图、工具类点对点传文件、轻量协同
私有化 / 内网 / 自托管
- 信令与业务服务部署在内网或自有服务器，不依赖 Agora、Twilio 等公有 RTC
- 适合企业内网、工厂、政务等对数据出境敏感的场景
单路 IoT / 轻量监控
- 单设备推流、单控制台收看（
sendonly+stats监控 fps、RTT、codec）
可以做，需额外建设
| 产品方向 | WetRTC 提供什么 | 还需补充 |
|---|---|---|
| 2～5 人小群视频 | P2P mesh 可行 | 人数增多后连接数爆炸，需 SFU 或商用云 |
| 带系统声音的投屏 | 音频编码调优 API | Electron 系统声 loopback 捕获需单独实现 |
| 公网弱网 / 跨国 | ICE 服务器配置 | TURN 中继；极端场景考虑 SFU |
| 录制 / 回放 | 媒体 track 可获取 | MediaRecorder 或服务端录制需自建 |
| 多 viewer 同看一路 | 单路 P2P | 需 SFU fan-out 或多路连接策略 |
不太适合
以下场景建议选用 SFU（如 mediasoup、LiveKit）或 商用 RTC 云（声网、TRTC、Twilio 等），而非纯 P2P 连接库：
- 百人在线会议、直播间、连麦 PK
- 超低延迟可交互远程桌面 / 游戏串流（对标 Parsec 级体验）
- 不想接触 WebRTC 细节、只要「集成 SDK 就能通话」
- 纯服务端转码、CDN 大规模分发
能力对照
| 需求 | WetRTC | SFU / 商用云 |
|---|---|---|
| 自建信令、数据自主 | ✅ | 部分 / 否 |
| 1v1 或少量端 P2P | ✅ | 可以但偏重 |
| 多人可扩展 | ⚠️ mesh 有限 | ✅ |
| Electron 桌面捕获 | ✅（应用层） | 视 SDK |
| 低延迟屏幕调优 | ✅ 内置 API | 视方案 |
| 零运维全球网络 | ❌ 需自建 TURN | ✅ |
推荐连接模式速查
| 场景 | direction | 典型 initiator | 说明 |
|---|---|---|---|
| 主机投屏、等 viewer 连入 | sendonly | false（被动） | 见 virt-screen 双端角色 |
| 手机 / Web 只看屏 | recvonly | true（主动 offer） | 与上成对 |
| 1v1 视频通话 | sendrecv | 默认 true | 双方均可发媒体 |
| 仅传文件 / 信令 | sendrecv + DataChannel | — | 可不添加音视频 track |
仓库内参考
| 层级 | 说明 |
|---|---|
| @wetspace/wetrtc（core） | 通用库，上述场景均可基于它构建 |
| virt-screen | 产品实例：Windows 虚拟扩展屏 + 手机浏览器观看 |
| 低延迟屏幕共享 | 编码与 codec 调优指南 |
| 可运行 Demo | 最小端到端音视频体验 |
选型自检
在选用 WetRTC 前，可快速确认：
- 连接规模：是否主要是 1v1 或 1 对少数端？
- 信令：是否愿意自建 WebSocket / Socket.IO / HTTP 信令（或已有服务）？
- 网络：局域网为主，还是必须公网 + TURN？
- 延迟预期：屏幕「投屏看」可接受，还是要远程桌面级操作延迟？
- 合规：是否需要数据完全留在自有基础设施？
若前四项偏 P2P、自建、可控网络，WetRTC 通常是合适起点；若核心是「百人在线 + 零运维」，应优先评估 SFU 或商用 RTC。