Live Share 不自动共享本地服务，必须手动添加端口映射且服务需监听 0.0.0.0：启动会话后，在 Live Share 视图中点击 + Add Server 输入端口号（如3000），协作者即可访问 http://localhost:3000；服务重启后映射失效，需重新添加。
Live Share 本身不自动共享你本地启动的 npm run dev、python -m http.server 或其他服务，必须手动添加端口映射，且主机服务需监听 0.0.0.0 而非仅 127.0.0.1 —— 这是协作失败最常卡住的两个点。
为什么 Go Live 按钮不能直接让同事访问你的本地服务
vscode-live-server 的 “Go Live” 只在你本机启动一个带热重载的 HTTP 服务器，它和 Live Share 是两套独立机制。即使你开了 Live Share 会话，vscode-live-server 默认也不会把它的端口注册进 Shared Servers 列表。
常见错误现象：
- 同事点击你分享的
http://localhost:5500，浏览器显示 “连接被拒绝” 或空白页 - 状态栏有 Live Share 图标，但 Shared Servers 区域为空
- 你在终端里确认
npm start已运行，端口 3000 确实监听中，但协作者仍打不开
根本原因：Live Share 不扫描进程或端口，它只转发你明确告诉它的端口号。你得自己填进去。
如何手动添加并验证端口映射
操作路径清晰，但每一步都有易忽略细节：
- 先确保 Live Share 会话已启动，且弹窗中勾选了 Share Servers（默认可能未勾选）
- 打开左侧 Live Share 视图 → 找到 Shared Servers 区域 → 点击
+ Add Server - 输入你服务实际监听的端口号（如
3000），名称可填react-dev方便识别 - 添加后，立刻检查协作者的 Live Share 视图里是否出现该条目；若没有，说明主机端未成功注册（常见于服务未运行或绑定地址不对）
验证技巧：主机可在终端执行 lsof -i :3000（macOS/Linux）或 netstat -ano | findstr :3000（Windows），确认输出中包含 0.0.0.0:3000，而非仅 127.0.0.1:3000。
不同框架下服务绑定 0.0.0.0 的写法差异
很多前端脚手架默认只监听 localhost，必须显式覆盖 host 参数，否则 Live Share 捕获不到流量：
- Create React App：
npm start -- --host 0.0.0.0或在package.json中改 scripts 为"start": "react-scripts start --host 0.0.0.0" - Vite：
vite --host 0.0.0.0或配置vite.config.ts中server.host: "0.0.0.0" - Next.js（dev 模式）：
next dev -H 0.0.0.0 - Python HTTP server：
python -m http.server 8000 --bind 0.0.0.0:8000
注意：某些旧版工具（如老版本 CRA）不支持 --host，需升级或换用 cross-env 注入环境变量。
端口共享后的安全与兼容性盲区
看似一键共享，实则几个关键约束常被跳过检查：
- 协作者访问的
http://localhost:3000实际走的是加密隧道连回你的机器，所以你的服务必须持续运行——服务重启后，映射不会自动恢复，需重新+ Add Server - 若协作者本机
3000已被占用，Live Share 会 fallback 到3001并在 UI 显示映射关系，别硬记原始端口号 - 绝对不要共享
22（SSH）、3306（MySQL）、6379（Redis）等敏感端口：Live Share 不做身份认证透传，暴露即等同开放未授权访问 - 公司防火墙若拦截
vscode.liveshare.com或 WebRTC 相关域名，端口共享会静默失败，无错误提示——此时需联系 IT 开放该域名出站策略
最常被忽略的一点：Live Share 共享的是“端口”，不是“路径”。如果你的服务依赖本地文件系统路径（如读取 ./config/dev.json），而协作者没同步相同目录结构，页面可能加载一半就报 500 错误——这不属于端口问题，得靠 Git 或共享存储解决。
