<p>必须用 extern "C" 封装纯 C 接口、静态链接 libwebrtc.a、显式指定 LDFLAGS 并禁用组件构建；Go 初始化前需 runtime.LockOSThread()，所有 WebRTC 操作限于该 OS 线程；C 回调须通过 void* 传上下文，配合原子标志防野指针。</p>
Go 调用 WebRTC C++ 库必须用 cgo，但不能只写 import "C"
直接在 Go 文件里写 import "C" 并调用 C 函数，对简单 demo 可行，但调用 WebRTC 这类大型 C++ 库时会立刻失败——cgo 默认不支持 C++ 名字修饰（name mangling），也不会自动链接 C++ 标准库。你看到的典型错误是：undefined reference to `webrtc::PeerConnectionInterface::Create(...)，本质是链接器找不到 C++ 符号。
正确做法是封装一层纯 C 接口：
- 用
extern "C"包裹所有暴露给 Go 的函数声明，禁用 C++ 名字修饰 - 把
std::shared_ptr、std::string、类成员方法等 C++ 特性全部转成 C 风格指针 + 回调函数 + 手动生命周期管理 - 在
/* #cgo ... */注释块中显式指定 WebRTC 静态库路径、头文件路径和链接选项，例如：#cgo LDFLAGS: -L/path/to/webrtc/lib -lwebrtc -lpthread -latomic -ldl - 确保 WebRTC 是用与 Go 编译器匹配的 ABI 编译的（比如 GCC 12 编译的 WebRTC，不要混用 Clang 15）
WebRTC C++ 库必须静态编译，动态链接 libwebrtc.so 在 Go 中几乎不可行
Go 程序默认使用自己的调度器和内存管理模型，而 WebRTC 的线程模型（rtc::Thread）、任务队列（TaskQueueBase）严重依赖其内部运行时。若以动态库形式加载，极易出现符号冲突、TLS（线程局部存储）错乱、析构顺序异常等问题，典型表现是程序在 PeerConnection::Create 后立即 panic 或静默崩溃。
所以必须静态链接：
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 从官方源码编译 WebRTC 时，加
--is_component_build=false和--enable_nacl=false（NaCl 已废弃，但残留代码会干扰链接） - 确认生成的是
libwebrtc.a，而非libwebrtc.so；检查其是否包含完整依赖（nm -C libwebrtc.a | grep CreatePeerConnection应有输出） -
#cgo LDFLAGS中禁止出现-lwebrtc以外的 C++ 运行时库（如-lstdc++）——Go 1.20+ 默认用libc++，混用会触发__cxa_throw符号缺失
Go 主线程不能直接调用 WebRTC 初始化，必须用 runtime.LockOSThread()
WebRTC 内部大量使用线程亲和性（thread affinity），比如网络 IO 必须在专用 NetworkThread 上执行，音频采集需绑定到特定 OS 线程。而 Go 的 goroutine 是 M:N 调度，随时可能被迁移到不同 OS 线程，导致 WebRTC 内部状态错乱、回调丢失或死锁。
安全做法是：在首次调用 WebRTC 前，显式锁定当前 goroutine 到一个 OS 线程，并在此线程上完成全部 WebRTC 生命周期操作：
- 在 Go 初始化函数中调用
runtime.LockOSThread() - 所有 WebRTC 对象创建、配置、信号处理、销毁都必须在这个已锁定的 goroutine 中完成
- 不要跨 goroutine 传递 WebRTC 对象指针（如
*C.PeerConnection），它们不是线程安全的 - 若需异步响应（如 ICE 连接状态变更），通过 channel 将事件发回主线程，而非直接在 WebRTC 回调里调 Go 函数
C++ 回调函数传入 Go 闭包会导致崩溃，必须用全局函数指针 + 上下文 void*
常见错误写法：C.set_on_ice_connection_state_changed(func() { fmt.Println("ok") }) —— Go 闭包无法直接转为 C 函数指针，且闭包捕获的变量在 C 层无生命周期保证，运行时大概率 segfault。
正确模式是：
- 定义一个全局 C 函数（如
on_ice_state_changed），接受void* user_data参数 - 在 Go 层 malloc 一块内存存 Go 函数指针或结构体地址，传给 C 层作为
user_data - C 回调触发时，用
cgo的handle或uintptr转回 Go 对象，再调用对应方法 - 务必在 WebRTC 对象销毁前 free 该内存，否则造成 Go 堆内存泄漏
最易被忽略的是上下文生命周期绑定——WebRTC 的回调可能在对象销毁后仍被延迟触发（尤其在 ICE 失败重试场景），必须在 C 层加原子标志位判断对象是否 still alive，否则解引用野指针。
