live share 不支持音频共享，其设计仅转发编辑操作、调试状态等数据，不处理音频流；所有“audio”扩展均无效或已废弃，应改用teamspeak 3或mumble等专用局域网语音工具配合。
Live Share 不支持音频共享，所谓 “Live Share Audio” 是误导性概念，不存在官方功能或可靠扩展能实现该效果。
为什么找不到 Live Share Audio 功能
VS Code 官方 Live Share 插件（ms-vsliveshare.vsliveshare）从设计上就**不处理任何音频流**。它的通信协议基于 WebRTC 数据通道，仅转发编辑操作、调试状态、终端 I/O 和协作光标。音频需要独立的实时音轨编码、抖动缓冲、回声消除等能力，这不在 Live Share 的职责范围内。
- 官方文档明确将音视频列为
not supported，且截至 2026 年 4 月仍无加入计划 - VS Code 市场中所有名称含 “Audio” 的 Live Share 扩展，要么是 2020 年后未更新的废弃项目，要么只是把麦克风输入转成文字发到聊天栏——不是音频流
- 安装这类插件反而可能触发
Extension host terminated unexpectedly错误，尤其与新版 Live Share 冲突时
点击“Join Audio”按钮却没声音？检查是否误装了第三方扩展
某些非官方扩展（如旧版 vscode-liveshare-audio 或社区魔改包）会在状态栏添加假的 Join Audio 按钮。点击后看似连接成功，实则：
- 没有建立 UDP 音频流，只是静默返回
- 可能劫持麦克风权限但不传输数据，导致系统录音设备异常
- 在 macOS 上常与 Core Audio 冲突，引发 VS Code 终端卡死
正确做法是：卸载所有名字带 Audio、Voice、RTC 的 Live Share 相关扩展，只保留官方 ms-vsliveshare.vsliveshare。
局域网内真正低延迟语音协作怎么做
必须绕过 Live Share，用专用语音工具配合，关键在「直连不绕云」：
- 先确认两台电脑能直通：在终端跑
ping 192.168.x.x或nc -zv 192.168.x.x 6667（TeamSpeak 默认端口） - 语音工具选
TeamSpeak 3或Mumble：支持自建局域网服务器、UDP 传输、无云端路由，延迟可压到 40ms 以内 - 禁用
Discord、Zoom、Teams：即使在同一 Wi-Fi，它们默认走公网中继，语音包可能绕行上海→新加坡→北京，导致口型和代码修改不同步 - VS Code 中关闭
liveshare.showWelcomeOnStart和所有通知弹窗，避免语音时被遮挡
Live Share 连接成功但语音卡顿？大概率是网络策略冲突
Live Share 和语音工具共存时，常见干扰源：
- Docker Desktop 或 WSL2 启用后，会劫持
127.0.0.1解析，导致 TeamSpeak 客户端尝试连本地回环而非对方 IP - Windows 防火墙默认阻止
UDP 6667-6670（TS3）和UDP 64738（Mumble），需手动放行 - 部分路由器开启 “AP 隔离” 或 “客户端隔离”，禁止同一 Wi-Fi 下设备直连，必须关闭
复杂点不在功能拼凑，而在于确认实际网络拓扑——先用 arp -a 或 ip neigh 看双方是否在同一个二层广播域，再决定用 mDNS 发现还是手输 IP 连接服务器。
