简介：面向Windows 64位平台上C++开发者的网络实时通信（WebRTC）M99静态库资源包，主要解决在Visual Studio等集成开发环境中加入实时通信能力时编译步骤繁琐、依赖关系难以配置的痛点，适合需要将音视频与数据通道能力直接集成到客户端程序的团队使用。压缩包共收录2000个文件，均为.h头文件，整体约109.31MB；这些头文件覆盖核心接口声明、音视频处理、H264编码支持、BoringSSL安全层以及线程与任务调度等关键模块，开发者可借此梳理功能边界和调用关系，从而顺利完成静态链接与二次开发。该版本支持H264编码，并选用BoringSSL作为SSL/TLS实现，集成时需避免与OpenSSL同时出现，以防止符号冲突和链接失败；静态库形态会将依赖编译进最终程序，运行时无需额外装载动态库，降低了部署环境不一致的风险。目前已有339人学习下载，适合视频会议、在线教育、远程协作等场景下的本地构建、版本固定和离线调试，也可以作为了解WebRTC模块结构与API设计思路的参考。 如果一个项目要用到 WebRTC，而它最终要落到一个实实在在的 Windows 64 位客户端上，我大概率会直接去源码里编译一份静态库出来。这不是炫技，是踩坑之后的选择。当时我们在做低延迟推流和拉流 SDK，移动端、服务端都有现成构建路线，唯独 Windows 端拿不到放心的二进制包，于是“webrtc M99 版本 windows64 位静态库”这个目标就被钉在了需求表里，前后折腾了一周多。这篇内容就是给那些同样在 Windows 端被 WebRTC 集成折磨、正准备自己动手构建的人看的，我会把从环境、参数、编译到链接的完整链路都摊开讲。

1. 为什么我必须从源码编译，而不是找个现成包

先说结论：你几乎找不到官方的 Windows 预编译 WebRTC 包。Google 官方对 Android 有 Maven 仓库、对 iOS 有 CocoaPods 分发，Windows 这边一直以来都只有源码。虽然可以在网上搜到各种第三方编好的 webrtc.dll，但版本来源不明，H264 能力经常被砍，关键补丁有没有打上也完全不可控。对要发布产品的团队来说，这风险太大了。

1.1 先弄清你要的是哪种形态的库

聊编译前先对齐概念。WebRTC 在 GN 构建系统里有一个总开关叫 is_component_build ，它直接决定最终产物的形态：

参数	产物	适合场景
is_component_build=false	单个完整的静态库 webrtc.lib	产品发布、SDK 对外交付
is_component_build=true	多个 DLL 组成的动态库	本地调试、频繁改代码

严格来说，WebRTC 源码裸编出来默认就是静态库，但因为 Chromium 系工程经常会受到各种 .gn 文件影响，参数可能被覆盖，所以我到后面一定会把 is_component_build=false 显式写死，避免构建系统在某些环节偷偷改掉。

1.2 动态库方案看着省事，实际坑更多

有人会想，既然自己编译麻烦，那找人要一个 webrtc.dll 行不行？我早期评估时专门研究过这条路，结论是不行。首先，全功能的 webrtc.dll 动辄 80MB 以上，而且它不是孤零零一个文件，运行依赖一堆配套 DLL；其次，DLL 里的符号接口在编译时就定死了，想做音频前处理、调整拥塞控制参数、修改弱网策略，完全没有入口；最后是版本和依赖地狱，WebRTC 底层牵扯 abseil、SSL、FFmpeg 一大批第三方库，拷贝过来的 DLL 和系统里其他组件版本一冲突，就是莫名其妙的崩溃。

网上搜“动态库与静态库讲解”，通常告诉你动态库省内存、好更新，但这套逻辑对 WebRTC 这种巨型工程不适用。你要做产品发布，静态库带来的符号可控性远比那点内存收益重要。

1.3 静态库真正的价值在源码可控

静态库方案意味着从这一刻起，整个 WebRTC 源码树都在你手里。M99 里面的弱网优化链路——拥塞控制、NACK 重传、jitter buffer、pacer——全是可读、可改、可加日志的源码，而不是一个黑盒 DLL。这一点对我后来处理弱网卡顿优化至关重要，我们直接在 pacer 模块里加了业务层观测点，动态库方案下根本做不到这种级别的定制。

2. 锁定 M99：版本不是越新越好，而是越可控越好

我一开始也考虑过直接切最新主干，但评估完 API 形态和社区生态之后，还是决定用 M99。M99 对应 Chromium 99，发布时间大约在 2022 年 3 月，是大量音视频工程验证过的一个稳定版本。

2.1 M99 的 API 形态恰好是分水岭

WebRTC 的 C++ 接口在 M99 时代还是大家最熟悉的那一套： CreatePeerConnectionFactory 老式创建方式、 PeerConnectionInterface 稳定接口、围绕 scoped_refptr 构建对象生命周期。到了后续版本，接口逐渐迁移到 PeerConnectionFactoryDependencies 和新线程模型，大量网上示例代码直接失效。而你搜“webrtc 推流和拉流”能搜到的大部分开源工程、技术博客，都是基于 M99 这个年代的 API 写的，这意味着集成时碰到问题，能查到的现成答案最多。

2.2 M99 在 Windows 平台上的工程状态

这个版本对 Windows 构建的适配已经相当完善：对 VS2019、Win10 SDK、clang-cl 工具链的搭配都很成熟。GitHub 上很多 WebRTC 相关仓库会明确标注支持版本范围，M99 基本落在包围圈中心。如果遇到编译或链接问题，大概率能找到别人留下的解决方法。相比之下，切太新的版本反而容易撞上工具链升级带来的未知问题。

2.3 源码拉取与精确切分支

# depot_tools 配好路径后，先拉取源码树
fetch --nohooks webrtc
cd src

# 查看所有 release 分支，找到 M99 对应分支号
git branch -r | grep branch-heads | tail -20
git checkout -b m99 branch-heads/4999

# 同步所有子模块与第三方依赖
gclient sync -D --with_branch_heads

这里要重点说下分支号。M99 对应的 release 分支通常是 branch-heads/4999 ，但 Google 的分支号偶尔会偏移，所以稳妥做法是先执行 git branch -r | grep branch-heads 看一眼再切分支。 gclient sync 一定要带 --with_branch_heads ，否则切完分支后依赖版本对不上，编译会死在第三方模块上，而且这种错误信息往往很隐蔽。

还有一点必须提醒： gclient sync 会从 Google 的代码仓库和依赖下载服务拉取大量内容，开发机必须能稳定访问这些服务。这属于环境前提，访问不通的话整个构建流程没法继续，反复重试只会浪费几个小时。

2.4 M99 的编解码器覆盖

M99 在编解码器方面能覆盖主流场景：VP8、VP9 是原生支持；H264 需要 OpenH264 和 FFmpeg 解码配合，必须打开 proprietary_codecs 相关参数；AV1 在这个年代已经可以编译进 libaom，但默认工程不一定开启，想用的话要确认 rtc_include_av1 的状态。

对做推流和拉流的人来说，H264 是刚需，因为 CDN 转码和播放端兼容性都指望它。这个诉求直接决定了后面 GN 参数怎么配。

3. 编译前环境准备与 GN 参数逐项拆解

3.1 明确的软硬件底限

我第一次尝试是在一台 8 核 16G 内存的机器上，结果 ninja 跑到一半内存占满，进程被系统干掉，白等两小时。后来换到 32G 内存的机器，一次通过。给你的底限建议如下：

项目	要求	备注
内存	16GB 勉强能跑，32GB 推荐	16GB 建议限制并行任务数
磁盘	至少 100GB 空闲空间	源码 + 缓存 + 编译产物
VS2019	16.8 或更高	安装 MSVC v142 工具集
Windows SDK	10.0.19041.0 或更高	VS 安装器里勾选
depot_tools	官方仓库克隆后加入 PATH	提供 gclient、gn、ninja
Python	depot_tools 自带 3.9	不建议额外装 Python 并抢占 PATH

有人以为装了 VS2019 就能跳过 depot_tools，这是误解。WebRTC 的构建链路是 fetch 拉源码、gn 生成工程、ninja 执行编译，这几个工具都由 depot_tools 提供。VS2019 在这里的主要角色是提供 Windows SDK、MSVC 库文件以及一些辅助工具链。

3.2 GN 参数表：一份可复用的 args.gn

我直接把 M99 x64 Release 静态库使用的 args.gn 给你：

is_debug=false
target_os="win"
target_cpu="x64"
is_component_build=false
rtc_include_tests=false
rtc_build_examples=false
rtc_build_tools=false
rtc_use_h264=true
rtc_use_h265=false
proprietary_codecs=true
ffmpeg_branding="Chrome"
rtc_enable_protobuf=false
treat_warnings_as_errors=false

把这份内容保存为 src/out/win64/args.gn ，然后在 src 目录执行 gn gen out/win64 生成 ninja 工程。每个参数为什么这么设，拆开讲：

参数	作用	为什么这样设
is_debug=false	关闭调试符号与优化开关	发布静态库不带 debug 配置
is_component_build=false	决定静态库还是动态库	关键中的关键，显式写死
target_os="win" / target_cpu="x64"	平台与架构	Windows 64 位静态库
rtc_include_tests=false	不编译测试代码	省大量时间和磁盘
rtc_build_examples=false	不编译示例工程	同上
rtc_build_tools=false	不编译辅助工具	同上
rtc_use_h264=true	启用 OpenH264 编码	推流拉流刚需
proprietary_codecs=true	解锁 H264/AAC 等专利编解码	M99 里 H264 依赖此开关
ffmpeg_branding="Chrome"	使用 Chromium 版 FFmpeg 配置	保证 FFmpeg 解码能力完整
rtc_enable_protobuf=false	关闭 Protobuf 信令模块	我们不用内置信令能力
treat_warnings_as_errors=false	警告不阻塞构建	避免工具链小版本差异导致失败

3.3 想再瘦一点，还能砍什么

如果产品场景不做双向音视频通话，只做单向推流或拉流，可以考虑关掉部分音频处理链路，库会明显缩小。比如 rtc_include_ilbc=false 去掉 iLBC 编解码器， rtc_include_opus=false 去掉 Opus（通常不建议，WebRTC 默认音频编解码器就是 Opus，除非你的业务完全不走音频）。还有 rtc_include_builtin_video_codecs=false 可以去掉内置视频编解码器，这时你必须自己注册外部编解码器，这个开关谨慎使用。

我的建议是：先把功能全部跑通，再考虑裁剪体积。否则漏掉某个模块时链接器会报一堆“未解析的外部符号”，排查起来非常痛苦。

4. 编译执行与产出物验证

4.1 生成构建目录并启动 ninja

args.gn 写好后，标准操作：

cd src
gn gen out/win64
ninja -C out/win64

建议不要手动 -j 指定特别大的并行数，depot_tools 自带的 ninja 会根据 CPU 核心数自动分配。16 核 32G 内存的机器，首次冷编译大约 1.5 到 2.5 小时，磁盘占用会一路涨到 60GB 以上。如果你只有 8 核 16G 内存的机器，用 ninja -C out/win64 -j 8 限制一下并行度，否则内存耗尽被系统杀进程是大概率事件。

4.2 编译产物不是你以为的那个文件

编完后，先找到产物：

dir /s src\out\win64\webrtc.lib

WebRTC 的 complete_static_lib 会把散落在各模块目录里的 obj 汇总成一个 webrtc.lib ，它一般位于 out/win64/obj/webrtc.lib 或 out/win64/ 根目录，具体位置看 GN 版本。这个库的全功能 Release 版体积在 400MB 到 700MB 之间浮动，取决于你的参数裁剪。

拿到库之后，第一件事是用 dumpbin 验证架构：

dumpbin /headers webrtc.lib | findstr machine

输出里必须能看到 x64 。曾经有同事把 x86 配置编出来的库拿到 x64 工程里链接，报错毫无头绪，最后就是这一步排查出来的。另外要有个心理准备： webrtc.lib 是合并静态库，里面塞了几千个 obj 的符号表，VS 工程首次链接时会明显变慢，几十秒到几分钟都正常，这不是卡死，别强制中断。

5. 在 VS2019 工程里把静态库接进去

5.1 头文件、宏、库目录三件套

别把整个 out 目录塞进 include path，正确做法是把源码树根目录 src 当作第一个 include 根，代码里用 #include "api/peer_connection_interface.h" 这种路径引用。

Release x64 配置下，附加包含目录参考：

src
src/third_party/abseil-cpp
src/third_party/libyuv/include
src/third_party/opus/src/include
src/third_party/ffmpeg/chromium

最后那个 FFmpeg 目录只有在你直接引用 FFmpeg API 时才需要，普通 PeerConnection 集成可以不加。

预处理器定义：

WEBRTC_WIN
NOMINMAX
WIN32_LEAN_AND_MEAN
UNICODE
_UNICODE
NDEBUG
_WIN32_WINNT=0x0A00

WEBRTC_WIN 是必须的，没有它代码会走到 Linux 分支，编译错乱。 NOMINMAX 防止 Windows 头文件里的 min/max 宏污染 STL； _WIN32_WINNT=0x0A00 表示以 Windows 10 为目标平台。

库目录填 webrtc.lib 所在目录，然后把下面这些系统库加进附加依赖项：

webrtc.lib
ws2_32.lib
winmm.lib
secur32.lib
crypt32.lib
iphlpapi.lib
d3d11.lib
dxgi.lib
mf.lib
mfplat.lib
mfuuid.lib
strmiids.lib

这套列表不是凭空写的，WebRTC 底层会用到网络、安全、媒体基础、Direct3D 等系统能力，缺任何一个都会在链接器阶段报符号缺失。

5.2 用最小 demo 确认链接成功

写一个最小 main 来验证：

#include "rtc_base/ssl_adapter.h"
#include "rtc_base/logging.h"

int main() {
  rtc::InitializeSSL();
  RTC_LOG(LS_INFO) << "webrtc static lib link OK";
  rtc::CleanupSSL();
  return 0;
}

编译通过后运行，输出 webrtc static lib link OK ，说明你的 M99 Windows x64 静态库已经真正可用了。到这一步也别急着欢呼，大概率还会被下一节的链接问题折磨一轮。

6. 从环境到链接，我踩过的坑

6.1 LNK2038 运行时库不匹配

最经典的一个错误： LNK2038 mismatch detected for RuntimeLibrary: value "MT_StaticRelease" doesn't match value "MD_DynamicRelease" 。原因是 WebRTC 库默认按 /MD 动态 CRT 编译，而你的 VS 工程默认可能是 /MT 。去工程属性里把“运行库”改成“多线程 DLL (/MD)”，问题就消失了。如果你的整个产品构建策略强制要求 /MT ，那在这个项目上会很难受，尽量统一到 /MD 。

6.2 unresolved external symbol 连环坑

链接时报一长串未解析的外部符号，大概率不是你代码的问题，而是系统依赖库没给全。我的排查方法是临时在链接器命令行加 /VERBOSE:LIBS ，重新链接后看每个符号来自哪个模块，再对照补充。上面列的那套系统库就是为了覆盖这种情况准备的。另一个隐蔽来源是 Protobuf 相关符号：如果 GN 里关了 rtc_enable_protobuf=false ，但工程里某些代码依赖了 protobuf 的符号，链接就会失败。解决办法是确认自己的代码路径没有触碰这些模块，而不是把 protobuf 库手动硬塞进来。

6.3 路径、磁盘与编译时长控制

WebRTC 源码目录深度非常夸张。如果放在 C:\Users\你的名字\Desktop\新建文件夹\webrtc 这种长路径下，编译到一半大概率会遇到“系统找不到指定的路径”。我实际项目里统一使用 D:\webrtc-build\w 这种短路径，并且开启 Windows 长路径支持，避免文件路径超过 260 字符限制。磁盘空间方面，CIPD 缓存会额外占 20-30GB，只留 50GB 就开工的人基本都会在中途停下删文件。

6.4 一个让后续开发舒服的小建议

编完第一次成功后，强烈建议把 src/out/win64/args.gn 单独备份到项目文档里，再写一个 build.bat 固定构建流程：检查环境变量、重新 gn gen 、执行 ninja -C out/win64 webrtc 。因为之后你大概率会在源码里改弱网参数、加日志、做各种定制，二次编译通常只需要几分钟到十几分钟，有脚本能省很多重复劳动。注意不要轻易 rm -rf out ，那个目录里的 gen 缓存一旦删掉，全量重编的代价会大到让你怀疑人生。

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