Live Share 是 VSCode 实时协作的核心，需单独安装并启动；vscode-microsoftteams 仅单向推送日志，不支持共编；Teams Toolkit 专用于开发 Teams 应用，与实时协作无关；Git 与 Live Share 分属不同协作维度，需配合使用。
Live Share 是实时协作的核心，不是 Teams 插件
VSCode 里所谓“Teams 协作”，其实不依赖 Microsoft Teams 官方客户端或聊天窗口——真正起作用的是 Live Share 扩展。它和 Teams 没有运行时耦合，只是同属微软生态、能互相打通通知。很多开发者误以为装了 vscode-microsoftteams 就能多人写代码，结果发现只能发消息，没法共编共调。
- 必须先装
Live Share（官方出品，Microsoft 发布），重启 VSCode 后按Ctrl+Shift+P输入Live Share: Start Collaboration Session启动 -
vscode-microsoftteams插件只负责单向推送：比如把调试崩溃信息、Git 提交记录、npm run build成功日志发到 Teams 频道，但它不参与编辑或终端共享 - 如果团队已在用 Teams，建议把
Live Share会话链接直接贴进频道，比用插件发消息更可靠——链接自带加密 token，默认 24 小时过期，权限可随时在右下角Live Share图标里调整
共享终端时，命令实际在谁的机器上跑？
这是最常被忽略的执行上下文问题：Live Share 共享的是“终端视图”和“输入流”，但每条命令真正在哪台机器执行，取决于谁按下了回车。
- 发起者（Owner）输入
npm start并回车 → 命令在发起者本地执行，所有协作者看到输出 - 协作者（Write 权限）输入
git status并回车 → 命令在协作者自己机器上执行，发起者只看到结果，无法干预其环境 - 调试时尤其危险：
launch.json中的program路径、env变量全部以被邀请方本地为准；若你写死"program": "C:\src\app.js"，队友 macOS 上必然报错Cannot find module - 正确做法是统一用相对路径：
"program": "${workspaceFolder}/src/index.js"，并确保node_modules在各自机器上已安装
Teams Toolkit 是用来开发 Teams 应用的，不是用来开会的
如果你的目标是在 Teams 里上架一个选项卡、机器人或消息扩展，那 Teams Toolkit 才是正解；但它和日常协作编程完全无关，装错方向会导致环境混乱。
-
Teams Toolkit本质是项目脚手架 + 本地调试代理：它帮你生成 React/Node.js 模板、自动注册 Azure AD 应用、一键部署到云环境，最后在 Teams 客户端里打开调试版选项卡 - 它不提供任何实时编辑、光标同步、语音通话能力；启动调试时开的是 Edge/Chrome 浏览器窗口，不是 Teams 窗口本身
- 常见错误：为“让队友看我改 Teams 选项卡”而装
Teams Toolkit，结果发现队友根本打不开你的调试地址——因为该地址绑定你本机 localhost + 自签名证书，且需登录你的 Microsoft 365 开发租户 - 正确路径：用
Live Share共享整个项目文件夹 + 终端，队友自己装Teams Toolkit后也能独立调试，无需共享你的登录态
Git 集成和 Live Share 不是替代关系，而是分层协作
很多人以为开了 Live Share 就不用 Git，或者反过来觉得每天 git push 就够了——两者解决的是不同时间尺度的问题。
-
Live Share解决“此刻 10 分钟内”的协同：结对调试、临时救火、教新人跑通环境 - Git 解决“今天下午三点前要合入 feature/login 的 PR”这类有明确交付节点的协作：分支保护、CI 检查、Code Review 留痕都依赖 Git 历史
- 风险点：多人通过
Live Share同时改同一文件，却不及时git add/git commit，等会话结束才发现冲突堆在 staging 区，且没留中间版本可回退 - 建议动作：每次
Live Share结束前，发起者主动提醒所有人执行一次git status，确认无未暂存修改；关键逻辑改动后立即提交，哪怕只是git commit -m "WIP: fix auth redirect"
