Live Share 协作不只靠安装插件，核心卡点是连接稳定性、权限同步和状态可见性；需检查 liveShare.host 域名连通性、设置 allowGuestToEdit、动态配置 launch.json 调试地址，并对齐渲染参数。
VS Code 实时协作不是靠装一个插件就自动好用的，核心卡点在连接稳定性、权限同步和状态可见性这三块。Live Share 能跑起来不等于协作顺畅，多数卡顿和权限错乱都源于远程端环境配置或本地网络策略没对齐。
Live Share 连接失败：检查 liveShare.host 和防火墙规则
常见错误现象是点击“Start Collaboration Session”后进度条卡住，或者对方收到邀请但无法加入，终端报错 Failed to connect to Live Share service。这不是插件没装好，而是 VS Code 默认尝试连接微软托管服务（liveShare.host 值为 prod），但在企业内网或某些云开发环境里，这个域名可能被 DNS 拦截或出口防火墙阻断。
- 临时验证方式：在命令面板运行
Live Share: Change Host，切换为dev或自建 host（如公司内部部署的 Live Share Server） - 确认本地终端能通
curl -v https://prod.liveshare.vsengsaas.visualstudio.com；如果超时，说明网络层已阻断 - Windows 用户注意：Windows Defender 防火墙默认会阻止
Code.exe的出站连接，需手动放行或关闭实时保护（仅限可信内网）
协作中文件无法编辑：liveShare.allowGuestToEdit 与语言服务器权限冲突
即使开启了共享，对方仍看到文件只读图标，或保存时报 Permission denied，往往不是权限开关没开，而是语言服务器（如 TypeScript Server、Python Pylance）拒绝非主控端发起的编辑请求。VS Code 的语言服务默认只响应当前窗口拥有者（host）的语义操作。
- 必须显式设置
"liveShare.allowGuestToEdit": true，且该配置要写在settings.json的用户级或工作区级，不能只靠 UI 开关 - 若使用 Remote-SSH 或 WSL 远程会话，还需确保远程端的
remote.SSH.remoteEnv中包含正确的PATH，否则 guest 端触发的格式化任务（如 Prettier）找不到可执行文件，会被静默降级为只读 - Python 项目特别容易踩坑：Pylance 默认禁用 guest 的类型跳转，需额外加配置
"python.languageServer": "Default"并重启 server
调试会话不同步：launch.json 中的 port 和 address 必须动态绑定
协作调试最常遇到的问题是 host 启动了 debugger，guest 却连不上 localhost:5000 —— 因为 guest 的 localhost 指向的是自己机器，不是 host 的。VS Code 不会自动转发调试端口，所有 launch.json 配置必须适配跨机器上下文。
- 避免硬编码
"address": "localhost"，改用"address": "0.0.0.0"并确认 host 机器防火墙开放对应端口 - Node.js 调试建议用
attach模式而非launch：host 先运行node --inspect-brk app.js，guest 再通过launch.json中的"port": 9229连接，绕过地址绑定问题 - 对于 Python Flask/Django，启动命令里必须加
--host=0.0.0.0 --port=5000，否则 Werkzeug 默认只监听 127.0.0.1
真正难处理的不是连接不上，而是连接上了但状态不可见：比如 guest 修改了某行代码，host 端光标没实时高亮、没有变更气泡提示。这种问题通常藏在 editor.renderWhitespace 或 editor.minimap.enabled 这类渲染参数的差异化配置里，需要双方手动对齐，而不是靠 Live Share 自动同步。
