Live Share 的 Share Server 功能是将主机已运行的服务（如 React、Python 服务器）通过加密隧道暴露给协作者，使其能通过 http://localhost:PORT 访问相同内容；需主机先启动服务再手动添加端口映射，不支持热重载，且与 Live Server 机制冲突，不可混用。
Live Share 共享的端口不能直接用于 Live Server 的网页预览，两者机制冲突，必须选其一：要协作调试就用 Live Share 的 Share Server，要本地快速预览就关掉 Live Share 端口共享、单独开 Live Server。
Live Share 的 Share Server 怎么用才对
它不是启动一个新服务器，而是把主机上「已运行」的服务（比如 npm start 启动的 React 开发服务器、python -m http.server 8000、甚至数据库）暴露给协作者。协作者访问 http://localhost:PORT 时，流量会经加密隧道转发到主机对应端口。
- 主机必须先手动运行服务，再在 Live Share 面板点击
Share Server→ 输入端口号（如3000），名称可选 - 协作者打开链接后，会在自己的浏览器里直接访问
http://localhost:3000，看到和主机完全一致的页面或 API 响应 - 如果协作者本机
3000已被占用，Live Share 会自动 fallback 到其他空闲端口（如3001），但 URL 不会变——这是隧道机制决定的，不是重定向 - 不支持热重载：修改 HTML/CSS/JS 后保存，页面不会自动刷新，除非你额外在主机上配了 Webpack/HMR 或用 Live Server 单独跑
Live Server 和 Live Share 能不能一起开
能，但会互相干扰。Live Server 默认监听 5500，如果你又用 Live Share 共享了 5500，协作者访问 localhost:5500 时，实际连的是主机的 Live Server 进程；但如果主机没开 Live Server，只开了 Live Share 共享，那这个端口就是空转的。
- 常见错误：主机开了 Live Server，又共享了同一端口，协作者刷新页面时发现样式丢失——因为 Live Server 的静态资源路径是相对项目根目录的，而 Live Share 隧道不处理路径重写
- 更稳妥的做法：关闭 Live Server（右键菜单里选
Stop Live Server），改用 Live Share 共享主机上真正运行的开发服务器（如 Vite、Next.js dev server） - 若只是想让协作者看个纯 HTML 页面，不如直接右键用 Live Server 打开，然后把
http://localhost:5500这个地址发过去——这比拉起 Live Share 会话更快
为什么协作者打不开 localhost:PORT 页面
不是网络问题，大概率是权限或状态没对上。
- 主机没真正在该端口运行服务：Live Share 不会帮你启动服务，只做隧道转发。检查主机终端是否显示
Listening on http://localhost:PORT - 协作者用了非 Chromium 内核浏览器（如 Safari）：某些旧版 Live Share 对 WebKit 支持不稳定，优先用 Chrome / Edge
- 主机共享的是 HTTPS 服务但没配证书：Live Share 隧道默认走 HTTP，如果主机服务强制 HTTPS，协作者访问
http://localhost:PORT会被跳转失败 - 企业网络拦截了 WebSocket 连接：Live Share 依赖 WebSocket 建立隧道，防火墙或代理可能阻断，此时会话能进、终端能连，但
Share Server显示“未连接”
端口共享本质是隧道，不是代理；Live Server 是本地服务，不是协作工具。混用前先想清楚：你要的是「一起改代码+看效果」，还是「我改完你立刻看到」——前者靠 Live Share + 真实 dev server，后者用 Live Server 就够了。
