Live Share邀请链接（如https://vsls.link/abcd1234）仅含加密会话ID，用于连接中继服务并同步工作区状态，不携带脚本内容或自动执行逻辑；协作者需对齐环境、共享终端/端口并由主机启动调试或服务才能真正运行脚本。
VSCode 本身不生成可直接点击运行的“脚本链接”，所谓“通过链接共享脚本”，本质是共享一个 Live Share 协作会话，让对方加入后看到并操作你正在编辑/运行的脚本文件——链接本身不携带脚本内容，只触发会话接入。
Live Share 链接到底包含什么？
生成的邀请链接形如 https://vsls.link/abcd1234，它不打包你的脚本代码，也不执行任何命令。它只是一个带加密会话 ID 的跳转地址，作用是：让协作者的 VSCode 连接到微软的 Live Share 中继服务，并拉取当前主机的工作区上下文（已打开的文件、光标位置、终端状态等）。
常见误解：点击链接就自动跑脚本 —— 实际上，脚本是否运行、怎么运行，完全取决于你本地是否已启动调试或在终端里执行了它；协作者看到的是“静态快照+实时同步状态”，不是自动执行环境。
为什么脚本在共享后不自动运行？
- Live Share 不转发进程生命周期：你本地
node app.js启动的服务，协作者能看到终端输出，但无法控制该进程（比如 Ctrl+C 终止），除非你显式启用"liveshare.shareServerProcesses": true - 调试会话需手动触发：即使你设置了断点，协作者默认不能按 F5 启动调试——必须由主机开启调试，或主机授予
Can Debug权限 - 权限隔离严格：协作者在终端中输入命令，实际是在你机器上执行；但若你没提前配置好 PATH 或依赖，他们敲
python script.py可能报Command not found，而非脚本本身问题
怎样让协作者真正“用上”你的脚本？
关键不是发链接，而是对齐执行环境和操作预期：
- 确保脚本路径在工作区内：不要用绝对路径如
/home/user/scripts/hello.py，改用相对路径./scripts/hello.py，否则协作者打开时可能提示“文件不存在” - 提前运行依赖检查：比如 Node.js 脚本，先在终端执行
npm install并确认package.json已提交到工作区，避免协作者一进来就看到Cannot find module - 用
Share Terminal而非仅共享文件：点击 Live Share 面板里的Share Terminal按钮，协作者才能看到你正在运行的nodemon或pytest输出 - 调试前先共享端口：如果脚本监听
:3000，勾选Share Server并输入端口，协作者才能在浏览器访问http://localhost:3000（实际映射到你的机器）
Remote-SSH + Live Share 是唯一可靠组合
如果你的脚本依赖远程服务器环境（比如 Python 在 Ubuntu 上跑，本地是 macOS），单独用 Live Share 会失败——它只能共享你本地 VSCode 打开的文件，不会把远程解释器、库路径、环境变量一起搬过去。
必须按顺序操作：
- 先用
Remote-SSH: Connect to Host连上目标服务器，确认左下角显示绿色 SSH 标识 - 再在该远程工作区里打开脚本文件、启动终端、运行命令
- 最后点
Live Share: Start Collaboration Session—— 此时协作者加入看到的才是真实远程环境下的脚本和输出
漏掉第一步，协作者大概率面对一个空文件夹，或一堆红色波浪线报错：找不到 import numpy。
