必须手动添加端口映射：启动Live Share会话后，在Live Share视图中点击“+ Add Server”，输入本地服务端口号（如3000），协作者即可通过http://localhost:3000访问；服务需已运行且监听中，不自动扫描端口。
Live Share 里怎么共享本地服务器端口？
能共享，但不是“自动转发所有端口”，必须手动指定。Live Share 不会扫描你机器上哪些服务在跑，只认你明确点选的 端口号 和对应服务名。
常见错误现象：你在本地 npm start 跑了 localhost:3000，但没在 Live Share 里主动添加这个端口，协作方打开 http://localhost:3000 就是连接拒绝——不是网络不通，是根本没被共享。
- 主持人必须在 VS Code 左下角 Live Share 状态栏点击小人图标 → 打开 “Live Share 资源管理器” → 点击 “+ 共享服务器”
- 输入你要共享的端口号（比如
3000），可选填名称（如React Dev Server） - 确认后，该端口会立刻出现在 “共享服务器” 列表中，来宾就能点击直接在自己浏览器打开
http://localhost:3000
为什么来宾访问的是 localhost:xxx，却连上了你的服务？
因为 Live Share 建立的是点对点加密隧道，不是传统端口映射或 NAT。它把你的 localhost:3000 流量通过安全通道“拉”到对方本地环回地址，所以对方浏览器请求 localhost:3000 实际走的是这条隧道，最终抵达你的进程。
这意味着：
- 来宾不需要改任何 URL，也不用记你的 IP 或公网地址
- 你的服务仍绑定在
127.0.0.1:3000（推荐），不建议绑定0.0.0.0:3000—— 后者可能暴露给局域网其他设备，而 Live Share 的隧道才是唯一入口 - 如果来宾本机
3000已被占用，Live Share 会自动 fallback 到下一个可用端口（比如3001），并在 UI 中显示实际映射结果
共享服务器时容易踩的坑
最常翻车的不是技术问题，而是权限和配置错位。
-
端口必须正在监听：共享前确保服务已启动且端口处于 LISTEN 状态（可用netstat -an | grep :3000或lsof -i :3000验证），否则共享成功但访问失败 - 别共享系统端口（
1–1023）：比如80、443，Live Share 可能因权限限制失败，也增加安全风险 - 来宾无法控制共享行为：只有主持人能增删端口，来宾看到的列表是只读的；如果发现不该共享的服务在列表里，得提醒主持人取消
- 防火墙通常不影响：Live Share 走的是 HTTPS/SSH 隧道，不依赖本地防火墙放行该端口，但杀毒软件有时会拦截隧道进程（少见，但遇到连接卡住可临时禁用排查）
共享后调试接口或 API 怎么办？
如果你共享的是后端服务（比如 Express、FastAPI），来宾不仅能访问网页，还能用 Postman 或 curl 直接调 localhost:3000/api/users —— 因为请求发到他们自己的 localhost，再经隧道抵达你的服务。
注意两点：
- API 返回的响应头（如
Access-Control-Allow-Origin）仍是你的服务设定的，Live Share 不修改内容 - 如果服务返回的是绝对 URL（比如重定向跳转到
http://localhost:3000/login），来宾浏览器会尝试访问自己本机的localhost:3000，这没问题；但如果返回的是你机器的 IP（如http://192.168.1.100:3000/login），就会失败——所以开发时尽量用相对路径或统一用/login
Live Share 共享服务器的本质，是让协作方“以为自己在本地跑着同一个服务”。真正复杂的地方在于：服务是否真在监听、端口是否干净、以及返回内容里有没有硬编码的本地地址——这些细节一旦漏掉，表面看共享成功，实际用不了。
