0 代表成功，非 0 都是错误。
错误码分两类：4~5 位的是服务端返回的业务错误码，6 位的是客户端 SDK 自己产生的错误码。6 位码的结构是 端前缀 + 3 位低位码，低 3 位按本页的统一码表分配，同一个低位码在各端含义相同。
怎么读一个错误码
所以看到
102231 和 106231，读作：同一个错误（无摄像头权限），分别来自 Android 端和 Web 端。
端侧类型
Swift SDK 同时支持 iOS 和 macOS，按运行平台使用
103 或 105 前缀。按码判断，不要按文案
- 判断错误类型只看错误码。SDK 自身的报错文案一律是英文，只给开发者和日志看，会随版本调整；不要拿它做分支判断，也不要直接展示给终端用户
- 需要给终端用户看的提示，请按错误码自行映射。各平台错误码页的「建议给用户的提示」列给出了参考文案
- 跨端对比同一类错误时，可以只比低 3 位（各端 SDK 提供
baseCode之类的字段，具体见各平台错误码页）
language 参数
各端 SDK 提供language 设置（名称以各端接口文档为准，如 Web 的初始化参数 language、C SDK 的 rtc_set_language）：
- 取值为语言标签，如
zh-CN、en。不设置时跟随系统语言，取不到时为中文 - SDK 请求服务端时带上
Accept-Language，服务端业务错误（1000–99999）的文案随之返回中文或英文 - SDK 自身的报错（6 位码）固定为英文，不受
language影响 - iOS（Objective-C）自 RTCEngineKit 3.2.1 起提供
RTCEngineKit.language（3.2.0 中 RTC 层请求不带Accept-Language）
统一码表（低 3 位）
号段：000–099 通用语义；200–299 频道 / 设备细分；300–349 流媒体。
一种语义只有一个码，各端遇到同一场景用同一个码。不是每个端都会用到全部的码，某端实际会产生哪些码见该端的错误码页。
几个容易混淆的码，按「最具体的原因优先」：
- 媒体连接创建失败、或进入 failed / closed → 015，不管发生在发布、订阅还是加入频道阶段
- 正在重连、稍后可重试 → 014；引擎已被关闭或销毁 → 023
- 流媒体引擎未连接（且不在重连中）时发布 / 订阅，或被拒绝、协商失败且没有更具体的码 → 300 / 301
- 当前环境不支持 → 032，不用 018（采集失败）
各端按新码发版的进度
本表是 2026-09-30 定稿的第 2 版，各端以自己按新码发版的版本为准。尚未发版的端，仍以该端错误码页列出的码为准。旧码 → 新码对照
旧版通用码 100001–100012
旧版部分端（iOS Objective-C、Windows 等）对外的 100xxx 通用码取消，改为「本端前缀 + 低 3 位」。例如旧的 100008（令牌失效）变为「本端前缀 + 004」。该端按新码发版后生效。
已按新码发版的端
其它端（Android、Windows）的旧码对照，随该端按新码发版时在其更新日志中给出。
排查时怎么用
各平台完整错误码表：
Web · Android · Windows · Swift · iOS · 鸿蒙 · C · Python
C SDK 分两层看。 它的接口返回值是
0 / -1 / -2 / -3 / -4 这样的简单状态值，只表达调用层面的结果、不含原因；具体原因用 rtc_get_last_error 取，也会打在日志里，那里既有 SDK 自身的 180xxx，也有服务端透传的 1xxx。见 C SDK 错误码。与 SMeeting 的区别
同一套规则，只是业务层号不同：SRTC 用10，SMeeting 用 20，两层的低 3 位码是两套独立的表。
如果你用的是 SMeeting，会同时看到两类错误码：20Nxxx 来自会议层，10Nxxx 来自底层 SRTC（会议层原样透传，便于定位）。见 SMeeting 错误码规则与总表。