knowledge-work-plugins Zoom 插件Video SDK Triage Intake 实践把“Video SDK 不工作”变成结构化诊断清单【免费下载链接】knowledge-work-pluginsOpen source repository of plugins primarily intended for knowledge workers to use in Claude Cowork项目地址: https://gitcode.com/GitHub_Trending/kn/knowledge-work-plugins当开发者报告“Video SDK isnt working”却给不出任何上下文时该问什么、先问什么、如何把模糊描述快速收敛到可排查的假设就是 Triage Intake分诊收集要解决的问题。本篇以 triage-intake.md 的五个问题域为骨架——平台与 UI 选型、会话基础信息、鉴权Signature/JWT、症状分桶、日志与最小复现——完整继承原文档的检查项并结合本仓库 zoom-plugin 中的鉴权参考、生命周期参考、5 分钟预检 Runbook、Token 契约测试规范与 SDK 日志指南逐项展开每一项“该问什么”背后的技术依据、典型错误模式与验证手段读完即可把一份 30 秒的模糊求助转成一张可直接开工的诊断表。为什么 Video SDK 分诊需要先确认“走对路”在 SKILL.md 中Video SDK 技能被定位为“完全自定义视频会话产品”的参考技能其开头就设了一条硬性路由护栏Hard Routing Guardrail用户要自定义实时视频行为topic/session 加入、自定义渲染、attach/detach时路由到 Video SDK不要为 Video SDK 的加入流程改用 REST 会议接口Video SDK不使用 Meeting ID、join_url也不使用 Meeting SDK 的meetingNumber、passWord等字段。triage-intake.md 的使用场景正是“有人报告 Video SDK 不工作但上下文不足”而 RUNBOOK.md 第 9 节 “Wrong-Path Detector” 给出了一个极快的判据如果对方实现里出现了meetingNumber或join_url或者通过/v2/meetings创建资源来加入说明根本不在 Video SDK 流程里。因此实际分诊时五个问题域之前还隐含第零步确认对方确实在 Video SDK 路径上Video SDK 会话是即时创建的topic 就是会话标识不需要预先创建会议避免用 Meeting SDK 的排查思路去套 Video SDK 的问题。第一步平台与 UI 选型Platform UI Choice原文档要求确认两件事平台web|react-native|flutter|ios|android|windows|linuxUI 方案UI Toolkitzoom/videosdk-zoom-ui-toolkit预制组件Custom UI直接使用 SDK API 自建界面为什么这两项必须最先问因为仓库里的多个高频故障都直接取决于这两个答案UI Toolkit 的平台可用性并不对称。根据 ui-toolkit.md 的平台表Webzoom/videosdk-zoom-ui-toolkit、iOS、Android 都有 UI Toolkit而React Native 与 Flutter 没有只能用 SDK 自建 UI。问清平台UI 方案才能立刻排除“你用的平台根本没有该组件”这类无效排查。UI Toolkit 会代管大部分生命周期与渲染。session-lifecycle.md 明确提示使用 UI Toolkit 时让 Toolkit 管理生命周期/渲染若需要“自定义”能力如截图、屏幕共享检测要先确认 Toolkit 是否暴露该能力还是必须落到底层 SDK API。同一个“视频不显示”症状在 Toolkit 方案下查组件配置与featuresOptions在 Custom UI 方案下则查事件监听与 attach/detach 逻辑——排查路径完全不同。Web 平台还要追问分发方式。RUNBOOK.md 第 5 节指出 npm 与 CDN 的全局对象不同ZoomVideovsWebVideoSDK.defaultCDN/ES Module 场景下还有 SDK 未加载完成的竞态问题SKILL.md 给出了对应的waitForSDK()守卫示例。此外 CDN 模式下source.zoom.us会被广告拦截器拦截官方建议自托管 SDK 文件。分诊时的落点拿到平台与 UI 方案后就能选择对应平台目录下的排查文档如 web/troubleshooting/common-issues.md、android/troubleshooting/common-issues.md 等各平台troubleshooting/common-issues.md。第二步会话基础信息Session Basics可直接复制粘贴原文档要求收集并强调“Copy/Paste”级别的精确性topic/sessionName所有加入者必须完全一致userNamepassword/sessionPasscode如使用SDK 版本 UI Toolkit 版本如适用这组字段不是泛泛的“环境信息”而是 Video SDK 会话模型的直接映射会话即时创建topic 即会话 ID。SKILL.md 的 “Session Creation Model” 说明Video SDK 会话不需要预创建第一个参与者带着某个topic加入时会话才被创建所有用同一topic字符串加入的人进入同一会话没有类似 Zoom Meetings 的数字会议号。由此推出第一个高频故障topic 拼写不一致 → “Session not found” / 加到不同会话这正是 troubleshooting.md 中 Join 失败表格的第一条。这组字段与后端 Token 契约一一对应。token-contract-test-spec.md 定义了跨平台Android、iOS、macOS、Unity共用的后端 token 契约输入为sessionName必填、userName必填、roleType可选、expirationSeconds可选输出为token短时效 JWT、expiresAt、回显的sessionName。分诊时要求对方“复制粘贴”这些值本质就是核对客户端实际 join 参数与 token 声明claim是否一致。UI Toolkit 场景下字段名略有差异。ui-toolkit.md 的joinSession配置使用videoSDKJWT、sessionName、userName、sessionPasscode并要求配套提供 SDK/Toolkit 版本号原文档中“SDK version UI Toolkit version”的由来。收集版本号的价值在于不同版本的行为差异如 CDN 全局对象名、事件名是跨版本排查的第一变量。第三步鉴权Signature/JWT原文档的两个确认点确认签名/JWT 是服务端生成的如 join 失败确认过期时间与服务器时钟偏移。仓库文档把这两点展开成了一套完整的 JWT 规范见 authorization.mdJWT 声明结构Claim说明app_key你的 SDK KeytpcTopic会话名任意字符串相同tpc加入同一会话role_type0 参与者1 主持人user_identity可选唯一用户标识iat签发时间戳exp过期时间戳两个关键点值得在分诊时追问主持/副主持身份完全由 JWT 的role_type决定而不是运行期 API第一个以role_type: 1加入者是 Host之后以 1 加入的是 Co-host只有 Host/Co-host 的client.leave(true)能结束整个会话。这解释了为什么“我无法结束会议”这类问题要先看 token 里签的是什么角色而不是查客户端代码。短时效 token 的标准做法exp设为当前时间 10 秒安全窗口极短iat设为当前时间 −7200 秒2 小时前以满足 Zoom 对exp - iat 2 小时的要求同时保证 token 只在“生成后立刻 join”的语义下有效。官方 Node.js 示例HS256const jwt require(jsonwebtoken); function generateSignature(sdkKey, sdkSecret, topic, role, userIdentity) { const iat Math.floor(Date.now() / 1000) - 7200; // 2 hours ago const exp Math.floor(Date.now() / 1000) 10; // 10 seconds from now const payload { app_key: sdkKey, tpc: topic, role_type: role, user_identity: userIdentity || , iat: iat, exp: exp }; return jwt.sign(payload, sdkSecret, { algorithm: HS256 }); }安全红线原文“Confirm signature/JWT is generated server-side”的依据SDK Secret 绝不可出现在客户端代码token 短时效生成前校验用户身份。分诊时对应“过期/时钟偏移”的两种典型症状token-contract-test-spec.md 的 Failure diagnostics 给出了精确对照token expired立刻出现→ 优先怀疑服务端时钟漂移clock skew或 TTL 配置错误而非客户端问题仅某一个平台join failed/auth→ 对比该平台对 claim payload 的处理方式与 SDK 版本差异原生平台正常、Unity 失败→ 核对 wrapper 对 join/token 的预期是否与当前版本一致。此外 sdk-logs-troubleshooting.md 提醒一个反直觉细节错误码 0 在很多 SDK 枚举里表示“成功”而非错误——“join 失败”报告里附带error 0时往往根本不是 join 失败。第四步症状分桶Symptom Bucket原文档把模糊抱怨归入五个桶join 失败 / 视频不渲染或自视黑屏常为浏览器/设备权限或生命周期顺序问题/ 音频不启动或音频路由变化 / 屏幕共享问题 / 性能、延迟、卡顿浏览器差异很重要。仓库文档为每个桶提供了可执行的排查依据桶 1Join 失败troubleshooting.md 的对照表错误可能原因解决Invalid signatureJWT 格式错误或已过期服务端重新生成签名Session not foundTopic 不匹配校验 topic 完全一致Auth failedSDK 凭据无效检查 SDK Key/Secret配合第二步的 topic 精确一致性与第三步的 claim 核对这个桶基本可以被“会话基础信息 鉴权”两步完全覆盖。桶 2视频不渲染 / 自视黑屏这是 session-lifecycle.md 重点攻击的“API 调用顺序”问题。标准顺序为创建 clientcreateClient()init()join()join 之后再getMediaStream()基于事件启动音视频并渲染离开会话并清理最常见的静默失败是在join()之前调用getMediaStream()返回 undefined无报错。SKILL.md 中给出了正误对照代码以及事件驱动渲染的强制要求// 远端视频开启/关闭时 attach/detach client.on(peer-video-state-change, async (payload) { const { action, userId } payload; if (action Start) { const el await stream.attachVideo(userId, VideoQuality.Video_360P); container.appendChild(el); } else { await stream.detachVideo(userId); } }); client.on(user-added, (payload) { /* 检查 bVideoOn */ }); client.on(user-removed, (payload) { stream.detachVideo(payload.userId); });注意原文档强调“使用attachVideo()而不是renderVideo()”旧 API 心智模型是常见迁移错误。RUNBOOK.md 的快速决策树给出了两个高命中判据“没有媒体流”→ 查生命周期顺序getMediaStream必须在join之后“只有本地视频正常”→ 缺少事件驱动的远端 attach 流程。自视黑屏则优先查相机权限与“相机被其他应用占用”见 troubleshooting 的 No Video 表。桶 3音频不启动 / 音频路由变化troubleshooting.md 的 No Audio 表听不到别人 → 确认调用过startAudio()别人听不到自己 → 麦克风权限应在 join 前申请回声 → 扬声器反馈改用耳机。Web 侧可用navigator.permissions.query检查 mic/camera 权限状态、用enumerateDevices()核对设备枚举见 sdk-logs-troubleshooting.md 的调试片段。桶 4 与桶 5屏幕共享 / 性能与延迟Web 特有的高频项在 troubleshooting 的 Web-Specific 表中SharedArrayBuffer 报错 → 服务端缺少 COOP/COEP 头性能问题 → 视频流过多降低参与方数量或分辨率。原文档特意标注“浏览器差异很重要”与此对应——分诊时必须问清浏览器 OS 控制台报错以及是否配置了 SAB/crossOriginIsolated见下一步。屏幕共享在 Custom UI 下属于独立能力路径SKILL.md 的 UI Toolkit 章节也提示需要确认 Toolkit 是否暴露屏幕共享检测还是得用底层 SDK API。第五步日志 最小复现Logs Minimal Repro原文档要求最小复现步骤、SDK 日志见仓库的 SDK 日志指南、Web 平台需补充浏览器 OS 控制台报错 是否配置了 SAB/crossOriginIsolated。仓库中 sdk-logs-troubleshooting.md 提供了各平台可复制的日志开启方式与收集规范各平台开启日志// Webverbose 日志 ZoomMtg.setLogLevel(verbose); // 或 Video SDK client.init(en-US, CDN, { debug: true });// iOS let initParams MobileRTCSDKInitParams() initParams.enableLog true initParams.logFilePrefix zoom_sdk// Android val initParams ZoomSDKInitParams().apply { enableLog true logSize 5 // MB }// Windows / macOS / Linux 桌面 initParam.enableLogByDefault true; initParam.logFilePrefix Lzoom_sdk;默认日志位置iOS 在 App 的 Documents 目录、Android 在 App 的 files 目录、Windows 在%APPDATA%\ZoomSDK\、macOS 在~/Library/Logs/ZoomSDK\、Linux 在工作目录。Web 平台的 Web Tracking IDVideo SDK Web 侧排查的关键凭据是 Web Tracking ID打开 DevTools → Network找到以lsdk?topic...开头的请求查看响应头中的x-zm-trackingid形如v2.0;clidus04;ridWEB_abc123xyz...。提单/求助时附上该 ID 与日志可显著缩短支持侧定位时间。最小复现与快速探针“最小复现步骤”不是客套要求RUNBOOK.md 的 Quick Probes 把它拆成了四个可打钩的探针签名端点返回合法 JWT payload、同一topic下两个用户 join 成功、startAudio()/startVideo()调用返回成功、浏览器日志无 mixed-content/CORS 拦截。仓库还给了可直接复制的验证命令# 1) 验证签名/token 端点有响应 curl -sS -i $VIDEO_SDK_BASE_URL/api/signature # 2) 验证应用页面可达 curl -sS -i $VIDEO_SDK_BASE_URL预期结果是 token 端点返回 JSON、应用路由返回 HTML——任何一步失败都能把“视频不工作”收敛到网络/后端层而不是陷入 SDK 内部。提交支持材料清单按 sdk-logs 指南与 troubleshooting.md 的 “Getting Support” 节一份合格的最小复现包应包含SDK 版本与平台、日志文件、复现步骤、错误码先确认 0 是否代表成功。sdk-logs-troubleshooting.md 还附了跨平台错误码参考0 成功、1 通用错误、2 参数无效、3 token 无效、4 超时以及 Windows 特有的 8 / 100000400 等分诊时可据此先做一轮“错误码翻译”避免把成功误报为失败。分诊速查表问题 → 核对项 → 仓库依据分诊步骤原文档骨架要问清什么典型故障与判据仓库依据平台 UI 选型7 平台之一Toolkit 还是 Custom UIRN/Flutter 无 UI ToolkitCDN vs npm 全局对象不同ui-toolkit.md、RUNBOOK.md会话基础信息topic 精确一致、userName、passcode、SDK/Toolkit 版本topic 不一致 → Session not foundSKILL.md、token-contract-test-spec.md鉴权是否服务端生成 JWT过期时间/时钟偏移立即 expired → 时钟漂移error 0 成功authorization.md症状分桶join / 渲染 / 音频 / 共享 / 性能getMediaStream必须在join后缺 peer-video-state-change 监听 → 只有本地视频session-lifecycle.md、troubleshooting.md日志 最小复现复现步骤、各平台日志、浏览器 OS SAB/crossOriginIsolated、Web Tracking IDSAB 报错 → 缺 COOP/COEP 头sdk-logs-troubleshooting.md这套清单的价值在于它把“Video SDK isnt working”从一句抱怨变成了五个可独立回答的问题每一步的回答都能直接裁剪掉一半假设错误路径、UI 方案误判、topic 不一致、JWT 时钟、生命周期顺序、浏览器能力位并在收集完五步信息后让排查者带着版本、claim 内容、日志与复现步骤进入 zoom-plugin 各平台目录下的深度文档继续诊断。【免费下载链接】knowledge-work-pluginsOpen source repository of plugins primarily intended for knowledge workers to use in Claude Cowork项目地址: https://gitcode.com/GitHub_Trending/kn/knowledge-work-plugins创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
knowledge-work-plugins Zoom 插件Video SDK Triage Intake 实践把“Video SDK 不工作”变成结构化诊断清单【免费下载链接】knowledge-work-pluginsOpen source repository of plugins primarily intended for knowledge workers to use in Claude Cowork项目地址: https://gitcode.com/GitHub_Trending/kn/knowledge-work-plugins当开发者报告“Video SDK isnt working”却给不出任何上下文时该问什么、先问什么、如何把模糊描述快速收敛到可排查的假设就是 Triage Intake分诊收集要解决的问题。本篇以 triage-intake.md 的五个问题域为骨架——平台与 UI 选型、会话基础信息、鉴权Signature/JWT、症状分桶、日志与最小复现——完整继承原文档的检查项并结合本仓库 zoom-plugin 中的鉴权参考、生命周期参考、5 分钟预检 Runbook、Token 契约测试规范与 SDK 日志指南逐项展开每一项“该问什么”背后的技术依据、典型错误模式与验证手段读完即可把一份 30 秒的模糊求助转成一张可直接开工的诊断表。为什么 Video SDK 分诊需要先确认“走对路”在 SKILL.md 中Video SDK 技能被定位为“完全自定义视频会话产品”的参考技能其开头就设了一条硬性路由护栏Hard Routing Guardrail用户要自定义实时视频行为topic/session 加入、自定义渲染、attach/detach时路由到 Video SDK不要为 Video SDK 的加入流程改用 REST 会议接口Video SDK不使用 Meeting ID、join_url也不使用 Meeting SDK 的meetingNumber、passWord等字段。triage-intake.md 的使用场景正是“有人报告 Video SDK 不工作但上下文不足”而 RUNBOOK.md 第 9 节 “Wrong-Path Detector” 给出了一个极快的判据如果对方实现里出现了meetingNumber或join_url或者通过/v2/meetings创建资源来加入说明根本不在 Video SDK 流程里。因此实际分诊时五个问题域之前还隐含第零步确认对方确实在 Video SDK 路径上Video SDK 会话是即时创建的topic 就是会话标识不需要预先创建会议避免用 Meeting SDK 的排查思路去套 Video SDK 的问题。第一步平台与 UI 选型Platform UI Choice原文档要求确认两件事平台web|react-native|flutter|ios|android|windows|linuxUI 方案UI Toolkitzoom/videosdk-zoom-ui-toolkit预制组件Custom UI直接使用 SDK API 自建界面为什么这两项必须最先问因为仓库里的多个高频故障都直接取决于这两个答案UI Toolkit 的平台可用性并不对称。根据 ui-toolkit.md 的平台表Webzoom/videosdk-zoom-ui-toolkit、iOS、Android 都有 UI Toolkit而React Native 与 Flutter 没有只能用 SDK 自建 UI。问清平台UI 方案才能立刻排除“你用的平台根本没有该组件”这类无效排查。UI Toolkit 会代管大部分生命周期与渲染。session-lifecycle.md 明确提示使用 UI Toolkit 时让 Toolkit 管理生命周期/渲染若需要“自定义”能力如截图、屏幕共享检测要先确认 Toolkit 是否暴露该能力还是必须落到底层 SDK API。同一个“视频不显示”症状在 Toolkit 方案下查组件配置与featuresOptions在 Custom UI 方案下则查事件监听与 attach/detach 逻辑——排查路径完全不同。Web 平台还要追问分发方式。RUNBOOK.md 第 5 节指出 npm 与 CDN 的全局对象不同ZoomVideovsWebVideoSDK.defaultCDN/ES Module 场景下还有 SDK 未加载完成的竞态问题SKILL.md 给出了对应的waitForSDK()守卫示例。此外 CDN 模式下source.zoom.us会被广告拦截器拦截官方建议自托管 SDK 文件。分诊时的落点拿到平台与 UI 方案后就能选择对应平台目录下的排查文档如 web/troubleshooting/common-issues.md、android/troubleshooting/common-issues.md 等各平台troubleshooting/common-issues.md。第二步会话基础信息Session Basics可直接复制粘贴原文档要求收集并强调“Copy/Paste”级别的精确性topic/sessionName所有加入者必须完全一致userNamepassword/sessionPasscode如使用SDK 版本 UI Toolkit 版本如适用这组字段不是泛泛的“环境信息”而是 Video SDK 会话模型的直接映射会话即时创建topic 即会话 ID。SKILL.md 的 “Session Creation Model” 说明Video SDK 会话不需要预创建第一个参与者带着某个topic加入时会话才被创建所有用同一topic字符串加入的人进入同一会话没有类似 Zoom Meetings 的数字会议号。由此推出第一个高频故障topic 拼写不一致 → “Session not found” / 加到不同会话这正是 troubleshooting.md 中 Join 失败表格的第一条。这组字段与后端 Token 契约一一对应。token-contract-test-spec.md 定义了跨平台Android、iOS、macOS、Unity共用的后端 token 契约输入为sessionName必填、userName必填、roleType可选、expirationSeconds可选输出为token短时效 JWT、expiresAt、回显的sessionName。分诊时要求对方“复制粘贴”这些值本质就是核对客户端实际 join 参数与 token 声明claim是否一致。UI Toolkit 场景下字段名略有差异。ui-toolkit.md 的joinSession配置使用videoSDKJWT、sessionName、userName、sessionPasscode并要求配套提供 SDK/Toolkit 版本号原文档中“SDK version UI Toolkit version”的由来。收集版本号的价值在于不同版本的行为差异如 CDN 全局对象名、事件名是跨版本排查的第一变量。第三步鉴权Signature/JWT原文档的两个确认点确认签名/JWT 是服务端生成的如 join 失败确认过期时间与服务器时钟偏移。仓库文档把这两点展开成了一套完整的 JWT 规范见 authorization.mdJWT 声明结构Claim说明app_key你的 SDK KeytpcTopic会话名任意字符串相同tpc加入同一会话role_type0 参与者1 主持人user_identity可选唯一用户标识iat签发时间戳exp过期时间戳两个关键点值得在分诊时追问主持/副主持身份完全由 JWT 的role_type决定而不是运行期 API第一个以role_type: 1加入者是 Host之后以 1 加入的是 Co-host只有 Host/Co-host 的client.leave(true)能结束整个会话。这解释了为什么“我无法结束会议”这类问题要先看 token 里签的是什么角色而不是查客户端代码。短时效 token 的标准做法exp设为当前时间 10 秒安全窗口极短iat设为当前时间 −7200 秒2 小时前以满足 Zoom 对exp - iat 2 小时的要求同时保证 token 只在“生成后立刻 join”的语义下有效。官方 Node.js 示例HS256const jwt require(jsonwebtoken); function generateSignature(sdkKey, sdkSecret, topic, role, userIdentity) { const iat Math.floor(Date.now() / 1000) - 7200; // 2 hours ago const exp Math.floor(Date.now() / 1000) 10; // 10 seconds from now const payload { app_key: sdkKey, tpc: topic, role_type: role, user_identity: userIdentity || , iat: iat, exp: exp }; return jwt.sign(payload, sdkSecret, { algorithm: HS256 }); }安全红线原文“Confirm signature/JWT is generated server-side”的依据SDK Secret 绝不可出现在客户端代码token 短时效生成前校验用户身份。分诊时对应“过期/时钟偏移”的两种典型症状token-contract-test-spec.md 的 Failure diagnostics 给出了精确对照token expired立刻出现→ 优先怀疑服务端时钟漂移clock skew或 TTL 配置错误而非客户端问题仅某一个平台join failed/auth→ 对比该平台对 claim payload 的处理方式与 SDK 版本差异原生平台正常、Unity 失败→ 核对 wrapper 对 join/token 的预期是否与当前版本一致。此外 sdk-logs-troubleshooting.md 提醒一个反直觉细节错误码 0 在很多 SDK 枚举里表示“成功”而非错误——“join 失败”报告里附带error 0时往往根本不是 join 失败。第四步症状分桶Symptom Bucket原文档把模糊抱怨归入五个桶join 失败 / 视频不渲染或自视黑屏常为浏览器/设备权限或生命周期顺序问题/ 音频不启动或音频路由变化 / 屏幕共享问题 / 性能、延迟、卡顿浏览器差异很重要。仓库文档为每个桶提供了可执行的排查依据桶 1Join 失败troubleshooting.md 的对照表错误可能原因解决Invalid signatureJWT 格式错误或已过期服务端重新生成签名Session not foundTopic 不匹配校验 topic 完全一致Auth failedSDK 凭据无效检查 SDK Key/Secret配合第二步的 topic 精确一致性与第三步的 claim 核对这个桶基本可以被“会话基础信息 鉴权”两步完全覆盖。桶 2视频不渲染 / 自视黑屏这是 session-lifecycle.md 重点攻击的“API 调用顺序”问题。标准顺序为创建 clientcreateClient()init()join()join 之后再getMediaStream()基于事件启动音视频并渲染离开会话并清理最常见的静默失败是在join()之前调用getMediaStream()返回 undefined无报错。SKILL.md 中给出了正误对照代码以及事件驱动渲染的强制要求// 远端视频开启/关闭时 attach/detach client.on(peer-video-state-change, async (payload) { const { action, userId } payload; if (action Start) { const el await stream.attachVideo(userId, VideoQuality.Video_360P); container.appendChild(el); } else { await stream.detachVideo(userId); } }); client.on(user-added, (payload) { /* 检查 bVideoOn */ }); client.on(user-removed, (payload) { stream.detachVideo(payload.userId); });注意原文档强调“使用attachVideo()而不是renderVideo()”旧 API 心智模型是常见迁移错误。RUNBOOK.md 的快速决策树给出了两个高命中判据“没有媒体流”→ 查生命周期顺序getMediaStream必须在join之后“只有本地视频正常”→ 缺少事件驱动的远端 attach 流程。自视黑屏则优先查相机权限与“相机被其他应用占用”见 troubleshooting 的 No Video 表。桶 3音频不启动 / 音频路由变化troubleshooting.md 的 No Audio 表听不到别人 → 确认调用过startAudio()别人听不到自己 → 麦克风权限应在 join 前申请回声 → 扬声器反馈改用耳机。Web 侧可用navigator.permissions.query检查 mic/camera 权限状态、用enumerateDevices()核对设备枚举见 sdk-logs-troubleshooting.md 的调试片段。桶 4 与桶 5屏幕共享 / 性能与延迟Web 特有的高频项在 troubleshooting 的 Web-Specific 表中SharedArrayBuffer 报错 → 服务端缺少 COOP/COEP 头性能问题 → 视频流过多降低参与方数量或分辨率。原文档特意标注“浏览器差异很重要”与此对应——分诊时必须问清浏览器 OS 控制台报错以及是否配置了 SAB/crossOriginIsolated见下一步。屏幕共享在 Custom UI 下属于独立能力路径SKILL.md 的 UI Toolkit 章节也提示需要确认 Toolkit 是否暴露屏幕共享检测还是得用底层 SDK API。第五步日志 最小复现Logs Minimal Repro原文档要求最小复现步骤、SDK 日志见仓库的 SDK 日志指南、Web 平台需补充浏览器 OS 控制台报错 是否配置了 SAB/crossOriginIsolated。仓库中 sdk-logs-troubleshooting.md 提供了各平台可复制的日志开启方式与收集规范各平台开启日志// Webverbose 日志 ZoomMtg.setLogLevel(verbose); // 或 Video SDK client.init(en-US, CDN, { debug: true });// iOS let initParams MobileRTCSDKInitParams() initParams.enableLog true initParams.logFilePrefix zoom_sdk// Android val initParams ZoomSDKInitParams().apply { enableLog true logSize 5 // MB }// Windows / macOS / Linux 桌面 initParam.enableLogByDefault true; initParam.logFilePrefix Lzoom_sdk;默认日志位置iOS 在 App 的 Documents 目录、Android 在 App 的 files 目录、Windows 在%APPDATA%\ZoomSDK\、macOS 在~/Library/Logs/ZoomSDK\、Linux 在工作目录。Web 平台的 Web Tracking IDVideo SDK Web 侧排查的关键凭据是 Web Tracking ID打开 DevTools → Network找到以lsdk?topic...开头的请求查看响应头中的x-zm-trackingid形如v2.0;clidus04;ridWEB_abc123xyz...。提单/求助时附上该 ID 与日志可显著缩短支持侧定位时间。最小复现与快速探针“最小复现步骤”不是客套要求RUNBOOK.md 的 Quick Probes 把它拆成了四个可打钩的探针签名端点返回合法 JWT payload、同一topic下两个用户 join 成功、startAudio()/startVideo()调用返回成功、浏览器日志无 mixed-content/CORS 拦截。仓库还给了可直接复制的验证命令# 1) 验证签名/token 端点有响应 curl -sS -i $VIDEO_SDK_BASE_URL/api/signature # 2) 验证应用页面可达 curl -sS -i $VIDEO_SDK_BASE_URL预期结果是 token 端点返回 JSON、应用路由返回 HTML——任何一步失败都能把“视频不工作”收敛到网络/后端层而不是陷入 SDK 内部。提交支持材料清单按 sdk-logs 指南与 troubleshooting.md 的 “Getting Support” 节一份合格的最小复现包应包含SDK 版本与平台、日志文件、复现步骤、错误码先确认 0 是否代表成功。sdk-logs-troubleshooting.md 还附了跨平台错误码参考0 成功、1 通用错误、2 参数无效、3 token 无效、4 超时以及 Windows 特有的 8 / 100000400 等分诊时可据此先做一轮“错误码翻译”避免把成功误报为失败。分诊速查表问题 → 核对项 → 仓库依据分诊步骤原文档骨架要问清什么典型故障与判据仓库依据平台 UI 选型7 平台之一Toolkit 还是 Custom UIRN/Flutter 无 UI ToolkitCDN vs npm 全局对象不同ui-toolkit.md、RUNBOOK.md会话基础信息topic 精确一致、userName、passcode、SDK/Toolkit 版本topic 不一致 → Session not foundSKILL.md、token-contract-test-spec.md鉴权是否服务端生成 JWT过期时间/时钟偏移立即 expired → 时钟漂移error 0 成功authorization.md症状分桶join / 渲染 / 音频 / 共享 / 性能getMediaStream必须在join后缺 peer-video-state-change 监听 → 只有本地视频session-lifecycle.md、troubleshooting.md日志 最小复现复现步骤、各平台日志、浏览器 OS SAB/crossOriginIsolated、Web Tracking IDSAB 报错 → 缺 COOP/COEP 头sdk-logs-troubleshooting.md这套清单的价值在于它把“Video SDK isnt working”从一句抱怨变成了五个可独立回答的问题每一步的回答都能直接裁剪掉一半假设错误路径、UI 方案误判、topic 不一致、JWT 时钟、生命周期顺序、浏览器能力位并在收集完五步信息后让排查者带着版本、claim 内容、日志与复现步骤进入 zoom-plugin 各平台目录下的深度文档继续诊断。【免费下载链接】knowledge-work-pluginsOpen source repository of plugins primarily intended for knowledge workers to use in Claude Cowork项目地址: https://gitcode.com/GitHub_Trending/kn/knowledge-work-plugins创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
